[Libguestfs] 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