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