marcus78
Goto Top

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.

virsh list --all
 Id   Name        State
---------------------------
 1    Server01    running
 2    Virtual01   running
 3    Virtual02   running
 4    Virtual03   running
 5    Virtual04   running
 6    Virtual05   running

Wenn ich jetzt Daten vom Agent abrufen will:

virsh guestinfo Sever01 --hostname
hostname            : VIRTUAL05

virsh guestinfo Virtual01 --hostname
hostname            : VIRTUAL04

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?

Content-Key: 31718155982

Url: https://administrator.de/contentid/31718155982

Printed on: July 14, 2024 at 16:07 o'clock

Member: commodity
commodity Jun 24, 2024 updated at 18:17:21 (UTC)
Goto Top
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            : VIRTUAL05

kann 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 
(ohne virsh guestinfo)
direkt auf der Konsole einer VM.

Viele Grüße, commodity
Member: Marcus78
Marcus78 Jun 25, 2024 at 06:34:05 (UTC)
Goto Top
ich konnte das Problem jetzt nachstellen. Es entsteht wenn man den libvirtd restartet wenn die VMs noch aktiv sind

systemctl restart libvirtd

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.
Member: commodity
commodity Jun 25, 2024 at 08:28:31 (UTC)
Goto Top
Es entsteht wenn man den libvirtd restartet wenn die VMs noch aktiv sind
https://libvirt.org/manpages/libvirtd.html
Beim Joggen die Beine abzuschrauben ist vielleicht nicht die beste Idee face-big-smile

Case Closed face-smile

Viele Grüße, commodity
Member: Marcus78
Marcus78 Jun 25, 2024 at 08:47:03 (UTC)
Goto Top
Zitat von @commodity:

Es entsteht wenn man den libvirtd restartet wenn die VMs noch aktiv sind
https://libvirt.org/manpages/libvirtd.html
Beim Joggen die Beine abzuschrauben ist vielleicht nicht die beste Idee face-big-smile

Case Closed face-smile

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.
Member: commodity
commodity Jun 25, 2024 at 12:02:02 (UTC)
Goto Top
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
Member: viragomann
viragomann Jun 25, 2024 at 13:46:59 (UTC)
Goto Top
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
Member: Marcus78
Marcus78 Jun 25, 2024 at 16:01:11 (UTC)
Goto Top
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.

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.
Member: commodity
commodity Jun 25, 2024 at 21:34:58 (UTC)
Goto Top
im XML gibt es dafür nichts
Mal geschaut: Ich habe nicht mal den Haken face-big-smile (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
Member: Marcus78
Marcus78 Jun 26, 2024 at 05:16:20 (UTC)
Goto Top
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.

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.
Member: Marcus78
Marcus78 Jun 26, 2024 at 07:58:20 (UTC)
Goto Top
Wenn man dumpxml aufruft, steht ein Individueller Path in der config

    <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.
Member: Marcus78
Solution Marcus78 Jun 26, 2024 at 11:57:08 (UTC)
Goto Top
so die Lösung ist wirklich, den source Eintrag wegzulassen ( oder halt je VM unterschiedlich zu setzen)

    <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.
Member: commodity
commodity Jun 26, 2024 updated at 14:00:23 (UTC)
Goto Top
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