Libguestfs - Dec 2022 - Proposal for tools to inspect drivers and inject Windows virtio drivers

We've had requests from products that use libguestfs & virt-v2v to
provide additional tooling for:

(a) Inspecting a virtual machine disk image to find out what virtual
    devices it needs (ie. what drivers are installed in the guest).

(b) Taking a Windows disk image and injecting virtio drivers from the
    virtio-win suite.

Virt-v2v does both operations as a part of importing guests from
VMware to KVM, but it doesn't expose these as separate operations.

- - -

For (a), you might run the tool against a disk image and it would
display various facts (similar to virt-inspector
https://libguestfs.org/virt-inspector.1.html):

$ virt-drivers -a linux.img
<operatingsystems>
   <operatingsystem>
     <root>/dev/sda2</root>
     <boot_drivers>
       [list of drivers from the initramfs in a format TBD]
     </boot_drivers>
     <drivers>
       [list of kernel modules]
     </drivers>
     <boot_loader>
       [extra stuff about the bootloader configuration,
        list of kernels, default kernel, grub1 or grub2,
	config file, ...]
     </boot_loader>

I propose a completely new tool added to guestfs-tools to do this,
which will basically pull the current kernel module and grub analysis
code from virt-v2v into a new library in libguestfs-common.

For Windows we actually don't do this in virt-v2v at the moment, so
that would need to be completely new code, likely parsing the
DriverDatabase from the Windows registry.

- - -

For (b), you could specify the location of the Window disk image and
the virtio-win path/ISO to have it attempt to install the drivers in
the disk image:

$ virt-customize -a windows.img \
                 --inject-virtio-win /usr/share/virtio-win/virtio-win-1.2.3.iso

This would largely involve taking the current virtio-win code from
virt-v2v, turning it into a library, and then adding a new module into
libguestfs-common/mlcustomize.  (It would be a good time to refactor
this code.)

- - -

Good?  Bad?  Let me know what you think ...

I think one large danger is that injecting virtio-win drivers into
existing Windows images is a very invasive operation with a large
potential to go wrong.  It would be better to work with the tools that
create these images so that they're able to inject virtio-win drivers
at initial creation.  (Or "Inbox" the drivers with Microsoft, but
there may be issues there).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

On 12/10/22 22:45, Richard W.M. Jones wrote:
> We've had requests from products that use libguestfs & virt-v2v to
> provide additional tooling for:
> 
> (a) Inspecting a virtual machine disk image to find out what virtual
>     devices it needs (ie. what drivers are installed in the guest).
What is this good for? In what scenario would it be used?
> 
> (b) Taking a Windows disk image and injecting virtio drivers from the
>     virtio-win suite.
> 
> Virt-v2v does both operations as a part of importing guests from
> VMware to KVM, but it doesn't expose these as separate operations.
When / where does (a) occur in current v2v usage?

Hm... I think I'm being misled / confused by your wording "needs"
in
point (a). If you say "supports" there, then I understand it more or
less.

E.g., I remember we determine virtio-1.0 support, virtio-socket support
level etc for Linux guests, in the gcaps structure, and then produce the
matching devices in the output domain XML or on the qemu command line
(similarly in the other output modules, if they can accommodate those
gcaps). It's just that "needs" implies that the guest really
requires
those devices, which I think may not be the case. (The guest already
boots OK on vmware, and vmware does not provide any virtio devices, so
the guest doesn't really "need" those devices.)
> 
> - - -
> 
> For (a), you might run the tool against a disk image and it would
> display various facts (similar to virt-inspector
> https://libguestfs.org/virt-inspector.1.html):
> 
> $ virt-drivers -a linux.img
> <operatingsystems>
>    <operatingsystem>
>      <root>/dev/sda2</root>
>      <boot_drivers>
>        [list of drivers from the initramfs in a format TBD]
>      </boot_drivers>
>      <drivers>
>        [list of kernel modules]
>      </drivers>
>      <boot_loader>
>        [extra stuff about the bootloader configuration,
>         list of kernels, default kernel, grub1 or grub2,
> 	config file, ...]
>      </boot_loader>
> 
> I propose a completely new tool added to guestfs-tools to do this,
> which will basically pull the current kernel module and grub analysis
> code from virt-v2v into a new library in libguestfs-common.
> 
> For Windows we actually don't do this in virt-v2v at the moment, so
> that would need to be completely new code, likely parsing the
> DriverDatabase from the Windows registry.
Right, so for Windows guests, the utility is even less clear to me.
> 
> - - -
> 
> For (b), you could specify the location of the Window disk image and
> the virtio-win path/ISO to have it attempt to install the drivers in
> the disk image:
> 
> $ virt-customize -a windows.img \
>                  --inject-virtio-win
/usr/share/virtio-win/virtio-win-1.2.3.iso
> 
> This would largely involve taking the current virtio-win code from
> virt-v2v, turning it into a library, and then adding a new module into
> libguestfs-common/mlcustomize.  (It would be a good time to refactor
> this code.)
> 
> - - -
> 
> Good?  Bad?  Let me know what you think ...
> 
> I think one large danger is that injecting virtio-win drivers into
> existing Windows images is a very invasive operation with a large
> potential to go wrong.  It would be better to work with the tools that
> create these images so that they're able to inject virtio-win drivers
> at initial creation.  (Or "Inbox" the drivers with Microsoft, but
> there may be issues there).
I forget why the virtio drivers are still not shipped by Microsoft (the
idea has been recurring for years now; I don't know what's been blocking
the implementation).

Anyway, I agree that it would be better to inject the drivers as a part
of initial image creation (your description leads me to believe that the
initial Windows disk images are not produced by the Windows installer,
but by some external tools, from zero). The original image creator
operates in a known context without having to parse anything, simply
because it starts from zero, and whatever exists in the Windows image at
any point (until creation finishes), it's there because the image
creator put it there. For virt-customize, the starting context is more
complicated; virt-customize must first "orient itself".

Laszlo

On Sat, Dec 10, 2022 at 09:45:11PM +0000, Richard W.M. Jones
wrote:
> For (b), you could specify the location of the Window disk image and
> the virtio-win path/ISO to have it attempt to install the drivers in
> the disk image:
> 
> $ virt-customize -a windows.img \
>                  --inject-virtio-win
/usr/share/virtio-win/virtio-win-1.2.3.iso
> 
> This would largely involve taking the current virtio-win code from
> virt-v2v, turning it into a library, and then adding a new module into
> libguestfs-common/mlcustomize.  (It would be a good time to refactor
> this code.)
This part is upstream in guestfs-tools 1.49.8.

(There are numerous commits across libguestfs, guestfs-tools, virt-v2v
and libguestfs-common to make this happen.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

On Sat, Dec 10, 2022 at 09:45:11PM +0000, Richard W.M. Jones
wrote:
> (a) Inspecting a virtual machine disk image to find out what virtual
>     devices it needs (ie. what drivers are installed in the guest).
guestfs-tools 1.49.9 contains a new tool called 'virt-drivers' which
has this functionality extracted from virt-v2v.  It's Linux only at
the moment (like virt-v2v).  Implementing this for Windows is TBD.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit