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
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs

Reply via email to