Libguestfs - Jun 2022 - [v2v PATCH 1/4] output/create_libvirt_xml: wire up the QEMU guest agent

The intent (even before RHBZ#2028764) has been to install the QEMU guest
agent in the converted domain unconditionally. Therefore, in order for the
GA to be actually accessible from the host side, augment the libvirt
output module with a "guest agent connection" also unconditionally.

For starters, the domain needs a virtio-serial device. Then there must be
a port on the device that (in the guest) the GA identifies by name, and
that (on the host) is exposed as a listening socket (usually in the unix
address family). The adress of that port (usually a pathname, i.e., for a
unix domain socket) is then passed to whatever host-side application wants
to talk to the GA.

The minimal domain XML fragment for that ("minimal" for our purposes)
is

  <controller type='virtio-serial' model='virtio'>
  <channel type='unix'>
    <target type='virtio' name='org.qemu.guest_agent.0'/>
  </channel>

The "controller" element is needed because
"controller/@model" is where we
regulate "virtio" vs. "virtio-transitional".

Everything else is filled in by libvirt. Notably, libvirt (a) creates and
binds the unix domain socket itself (usually
"/var/lib/libvirt/qemu/channel/target/DOMAIN/org.qemu.guest_agent.0"),
(b)
passes the file descriptor to QEMU, and (c) figures out the socket
pathname for commands such as

  virsh domfsinfo DOMAIN
  virsh domhostname DOMAIN --source agent
  virsh domifaddr DOMAIN --source agent
  virsh guestinfo DOMAIN

For QEMU, the corresponding options would be

  -chardev socket,id=agent,server=on,wait=off,path=/tmp/DOMAIN-agent \
  -device virtio-serial-pci,id=vioserial \
  -device
virtserialport,bus=vioserial.0,nr=1,chardev=agent,name=org.qemu.guest_agent.0 \

Note the "path=/tmp/DOMAIN-agent" property of "-chardev";
virt-v2v would
have to generate that (in place of the "fd=nnnn" property that libvirt
passes to QEMU).

Omit extending the QEMU output module for now, as the QGA protocol is
based on JSON, and one needs "virsh" or "virt-manager" (or
another
management application interface) anyway, for efficiently exchanging
messages with QGA. I don't know of end-user tools that directly connect to
"/tmp/DOMAIN-agent".

Don't modify the RHV and OpenStack outputs either; both of these
management products likely configure the virtio-serial device
automatically, for the agent access.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2028764
Signed-off-by: Laszlo Ersek <lersek at redhat.com>
---
 output/create_libvirt_xml.ml | 11 +++++++++++
 tests/test-v2v-i-ova.xml     |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
index 68d0a90918f3..531a4f75bf3e 100644
--- a/output/create_libvirt_xml.ml
+++ b/output/create_libvirt_xml.ml
@@ -524,6 +524,17 @@ let create_libvirt_xml ?pool source inspect
     e "console" ["type", "pty"] [];
   ];
 
+  (* Given that we install the QEMU Guest Agent for both Linux and Windows
+   * guests unconditionally, create the virtio-serial device that's needed
for
+   * communication between the host and the agent.
+   *)
+  List.push_back_list devices [
+    e "controller" ["type", "virtio-serial";
"model", virtio_model] [];
+    e "channel" ["type", "unix"] [
+      e "target" ["type", "virtio";
"name", "org.qemu.guest_agent.0"] []
+    ]
+  ];
+
   List.push_back_list body [
     e "devices" [] !devices;
   ];
diff --git a/tests/test-v2v-i-ova.xml b/tests/test-v2v-i-ova.xml
index 6b8cda62f051..da1db473e53c 100644
--- a/tests/test-v2v-i-ova.xml
+++ b/tests/test-v2v-i-ova.xml
@@ -49,5 +49,9 @@
     <input type='tablet' bus='usb'/>
     <input type='mouse' bus='ps2'/>
     <console type='pty'/>
+    <controller type='virtio-serial' model='virtio'/>
+    <channel type='unix'>
+      <target type='virtio'
name='org.qemu.guest_agent.0'/>
+    </channel>
   </devices>
 </domain>
-- 
2.19.1.3.g30247aa5d201

The patch looks OK, but qemu-ga supports vsock (-m listen-vsock), so
wouldn't it be easier to use that?  I thought that virtio-serial was
unmaintained these days and so vsock would be preferred.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top