[Libguestfs] Proposal for tools to inspect drivers and inject Windows virtio drivers

[Laszlo Ersek]

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