12
QEMU KVM Guest Agent
Ich habe eine Server (Debian) mit libvirt / QEMU KVM aufgesetzt. Dort laufen 6 VMs ( Windows 11 ).
Das läuft sehr gut, jetzt wollte ich aber noch den Quest-Agent einrichten und dann fingen die Probleme an.
Der Server vermischt die VMs wenn sie Gleichzeitig starten.
Wenn ich jetzt Daten vom Agent abrufen will:
Und ja ich bin sicher, das die VMs den richtigen Namen haben, sie wurden auch nicht geclont.
Wenn ich die VMs mit größerem Abstand starte ( 1Minute) dann ist auch alles ok. Wenn sie aber beim reboot mehr oder weniger gleichzeitig starten entsteht das Problem.
Kennt jemand den Effekt?
Das läuft sehr gut, jetzt wollte ich aber noch den Quest-Agent einrichten und dann fingen die Probleme an.
Der Server vermischt die VMs wenn sie Gleichzeitig starten.
virsh list --all
Id Name State
---------------------------
1 Server01 running
2 Virtual01 running
3 Virtual02 running
4 Virtual03 running
5 Virtual04 running
6 Virtual05 runningWenn ich jetzt Daten vom Agent abrufen will:
virsh guestinfo Sever01 --hostname
hostname : VIRTUAL05
virsh guestinfo Virtual01 --hostname
hostname : VIRTUAL04Und ja ich bin sicher, das die VMs den richtigen Namen haben, sie wurden auch nicht geclont.
Wenn ich die VMs mit größerem Abstand starte ( 1Minute) dann ist auch alles ok. Wenn sie aber beim reboot mehr oder weniger gleichzeitig starten entsteht das Problem.
Kennt jemand den Effekt?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 31718155982
Url: https://administrator.de/forum/qemu-kvm-guest-agent-31718155982.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
12 Kommentare
Neuester Kommentar
Kennt jemand den Effekt?
Nein. Habe aber auch keine Win11-VMs. Hast Du die VMs nach Installation der guest-agents neu gestartet?
Das hier:
virsh guestinfo Sever01 --hostname
hostname : VIRTUAL05kann ja schon mal nicht sein, denn Sever01 gibt es ja gar nicht. Da müsste eine Fehlermeldung kommen.
Wenn Du das gecopy/pasted hast und keine Fehlermeldung kam, funktioniert Dein guestinfo auf dem Host nicht korrekt.
Evtl. funktionieren die Guest-Agents mit Windows11 auch nicht korrekt.
Sind denn die Hostnames und Virtual Domains bei Dir identisch? Bitte prüfe mal die Ausgabe von
hostname direkt auf der Konsole einer VM.
Viele Grüße, commodity
ich konnte das Problem jetzt nachstellen. Es entsteht wenn man den libvirtd restartet wenn die VMs noch aktiv sind
Danach ist die Zuordnung falsch und bei einigen VMs lässt sich der Agent gar nicht ansprechen. Ein neustart vom Agent im Windows behebt das Problem aber nicht.
systemctl restart libvirtdDanach ist die Zuordnung falsch und bei einigen VMs lässt sich der Agent gar nicht ansprechen. Ein neustart vom Agent im Windows behebt das Problem aber nicht.
Es entsteht wenn man den libvirtd restartet wenn die VMs noch aktiv sind
https://libvirt.org/manpages/libvirtd.htmlBeim Joggen die Beine abzuschrauben ist vielleicht nicht die beste Idee
Case Closed
Viele Grüße, commodity
Zitat von @commodity:
Beim Joggen die Beine abzuschrauben ist vielleicht nicht die beste Idee
Case Closed
Es entsteht wenn man den libvirtd restartet wenn die VMs noch aktiv sind
https://libvirt.org/manpages/libvirtd.htmlBeim Joggen die Beine abzuschrauben ist vielleicht nicht die beste Idee
Case Closed
nicht ganz, wenn man viele VMs gleichzeitig startet, passiert es ja auch. Aber das spielt halt der Zufall eine große Rolle. Ich konnte das auch jetzt schon mehrfach nachstellen.
Ich konnte das auch jetzt schon mehrfach nachstellen.
Da auch Proxmox das unmittelbar verwendet und Dein Fehlerbild dort im Forum unbekannt zu sein scheint, wird wohl Deine Einrichtung einen Fehler haben.
Vielleicht ist es der Haken bei Auto socket. Wenn bei Display Auto(Port) angeklickt ist, wählt er den Socket willkürlich. Vielleicht ist das Verhalten beim Agent ähnlich.
https://sysguides.com/install-a-windows-11-virtual-machine-on-kvm#9-19-a ...
Viele Grüße, commodity
Proxmox verwendet nach meinem Wissen aber nicht libvirt, und startet die VMs auch nicht gleichzeitig.
Hast du den libvirt-guests Dienst aktiviert? Ggf. sorgt der für einen reibungslosen Start aller VMs.
Grüße
Hast du den libvirt-guests Dienst aktiviert? Ggf. sorgt der für einen reibungslosen Start aller VMs.
Grüße
Vielleicht ist es der Haken bei Auto socket. Wenn bei Display Auto(Port) angeklickt ist, wählt er den Socket willkürlich.
Vielleicht ist das Verhalten beim Agent ähnlich.
Vielleicht ist das Verhalten beim Agent ähnlich.
keine Ahnung was der Haken bewirkt, im XML gibt es dafür nichts
<channel type='unix'>
<source mode='bind' path='/var/lib/libvirt/qemu/f16x86_64.agent'/>
<target type='virtio' name='org.qemu.guest_agent.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>Hast du den libvirt-guests Dienst aktiviert? Ggf. sorgt der für einen reibungslosen Start aller VMs.
noch nicht, ich hatte sie alle mit virtsh start xxx gestartet, wenn ich 20sekunden pause mache geht es. Ohne Pause gibt es Probleme.
Vermutlich kann ich mit dem Problem leben, bei libvirt-guests habe ich 30sekunden Verzögerung eingestellt. Da muss ich beim starten von Hand halt eine Pause machen und auf keine Fall libvirshd neu starten.
im XML gibt es dafür nichts
Mal geschaut: Ich habe nicht mal den Haken (System: Buster on Buster)Bei mir enthält path aber eine Nummer (hier: domain-3) und den Namen des Servers (hier: FS01). Bei Dir sieht der Teil standardisiert aus. Gibt es für jede VM einen individuellen Pfad?
<channel type="unix">
<source mode="bind" path="/var/lib/libvirt/qemu/channel/target/domain-3-FS01/org.qemu.guest_agent.0"/>
<target type="virtio" name="org.qemu.guest_agent.0" state="connected"/>
<alias name="channel0"/>
<address type="virtio-serial" controller="0" bus="0" port="1"/>
</channel>Viele Grüße, commodity
Gibt es für jede VM einen individuellen Pfad?
nein, sind alle gleich. Ich konnte nirgends einen Hinweis finden, das man das je VM anpassen sollte. Es scheint ja auch grundsätzlich zu funktionieren.
Ich konnte dazu folgendes finden:
since 1.0.6 it is possible to have source path auto generated for virtio unix channels. This is very useful in case of a
qemu guest agent, where users don't usually care about the source path since it's libvirt who talks to the guest agent.
qemu guest agent, where users don't usually care about the source path since it's libvirt who talks to the guest agent.
ich habe jetzt mal source weggelassen, zumindest geht es dann noch. Muss jetzt mal testen, was passiert wenn ich das bei allen machen und dann alle gleichzeitig starte.
Wenn man dumpxml aufruft, steht ein Individueller Path in der config
aber wenn man virsh edit aufruft, ist source nicht gesetzt.
<channel type='unix'>
<source mode='bind' path='/run/libvirt/qemu/channel/20-Virtual05/org.qemu.guest_agent.0'/>
<target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
<alias name='channel0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>aber wenn man virsh edit aufruft, ist source nicht gesetzt.
so die Lösung ist wirklich, den source Eintrag wegzulassen ( oder halt je VM unterschiedlich zu setzen)
Damit konnte ich auch nach mehrfachen Starten der VMs keine Probleme mit dem Agent feststellen.
<channel type='unix'>
<target type='virtio' name='org.qemu.guest_agent.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>Damit konnte ich auch nach mehrfachen Starten der VMs keine Probleme mit dem Agent feststellen.
it is possible to have source path auto generated for virtio unix channels.
Das sollte ja dennoch individuelle Pfade generieren. Wenn das derselbe für alle Geräte ist, wird es sicher durcheinander.Danke für's Feedback.
Viele Grüße, commodity
