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.)

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.