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 Mon, Dec 12, 2022 at 04:05:20PM +0100, Laszlo Ersek wrote:
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?
A good question to ask, especially about (b) below. For (a) above, we have layered products which allow people to upload disk images to run in the cloud. A nice feature would be to examine those disk images and report potential problems ... - "Warning, this disk image does not have virtio drivers installed! It may run very slowly!" ... and/or to select the right mix of devices to present to the guest, for example selecting between IDE, virtio-blk or virtio-scsi as the disk bus. Another use I could see for this would be for additional diagnostics for guests which don't boot. We could ask people to run "virt-drivers" [insert final tool name here ...] on 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.
This is one where the usage is less clear-cut. In some private conversations we've talked about Windows images being uploaded which lack virtio drivers and so perform suboptimally. It's my belief that we should work with whatever tools create these images and get them to install the virtio drivers at creation time, rather than trying to modify them after the fact. Modifying guest images is far outside anything supported by Microsoft (we wrote our own tools to hack on the Windows registry), and for virt-v2v it only works because of our large QE team and the fact that virt-v2v keeps a backup in case things go wrong. I worry that if we provide this kind of tool downstream (in RHEL) we're providing a foot-gun. (Upstream you get to keep the pieces.) In most cases it would be better to use virt-v2v when the guest comes from VMware or Xen, and for everything else you should create the disk images with drivers.
When / where does (a) occur in current v2v usage?
I'm thinking of these modules: https://github.com/libguestfs/virt-v2v/blob/master/convert/linux_bootloaders... https://github.com/libguestfs/virt-v2v/blob/master/convert/linux_kernels.mli We don't currently have anything that does this for Windows guests, but the information can probably be read from the BCD and the DeviceDatabase in the registry. Hivex can read BCDs.
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).
It's unclear to me what these tools do, or even what the names of these tools are.
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".
Agreed.
Laszlo
Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
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 Tue, Jan 17, 2023 at 12:36:58PM +0000, Richard W.M. Jones wrote:
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.)
I should add here that caveats expressed in this thread about whether this is a good idea or not still stand. In almost every plausible circumstances you should either use virt-v2v (if importing from VMware) or work with the provider of virtioless images to add virtio at source. I've tried to make that clear in the manual. We may remove this feature downstream in RHEL. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
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
On Thu, Jan 19, 2023 at 06:49:32PM +0000, Richard W.M. Jones wrote:
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.
The virt-drivers tool supports listing Windows drivers starting with 1.49.10, so for example you can use this to tell if a Windows guest has virtio drivers (or VMware drivers) suitable for the target hypervisor. 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
participants (2)
-
Laszlo Ersek -
Richard W.M. Jones