How to automatically install guest drivers inside a Windows VM

Tue May 17 23:19:36 UTC 2022

> After a v2v conversion Windows will install the new devices
automatically.  That happens after boot but doesn't involve any user
intervention.

I can get v2v to install them, but I think that Device Manager step is
teaching the OS about them? The devices v2v adds are there, just unknown
until I do it. But it's also one of the easiest things in the world to do.

> You probably need to supply virt-v2v with the virtio-win disk, otherwise
it cannot install virtio drivers and won't change the default devices.

It can find virtio-win, I was getting a nasty warning until I added it. I
tried the conversion again on a new VM, waiting until the second restart
after it installs the drivers. It still isn't changing the devices, but the
drivers are there. Is this expected? I can do a writeup of exactly what I'm
doing in Redhat's bugzilla if that helps.

> Nevertheless, virt-v2v is *not* the right tool to be using here. It's
only for converting guests from VMware.  I was just pointing out that the
problem of installing drivers into Windows is a solved one, so take a look
at how virt-v2v does it and do it that way.

Why wouldn't it be? Especially with the in-place option, this takes a VM,
and adds exactly the drivers I need. It seems like taking any (maybe
VMWare) vm, converting it into a generic libvirt one, then converting THAT
into a ready-to-go libvirt one with devices/drivers, is a natural workflow.
I'm just starting at the "generic libvirt" step. The man page states "It
can modify the guest to make it bootable on KVM and install virtio drivers
so it will run quickly". It'd be practically impossible to get spice
installed via this route, but I'm not sure it's a bad one for getting
virtio itself.

> We could definitely use a standalone tool for installing drivers into
guests -- and indeed another tool to discover what emulated a hardware an
existing guest needs.  I have often thought about writing such standalone
tools but never got around to it.

Long term, if this existed, this would most-definitely be the ideal path.
(maybe that's what you meant with virt-v2v not being the right tool lol).
I'm not sure I have the time to help develop something like this,
especially if it's not in python, but I'd love to help put a bounty on it
at least if that's possible. Is there a way to see what interests exist in
the community for this tool? Once released, v2v could switch to using it,
to install virtio drivers potentially too.

Thanks for all the advice! Much appreciated.
Cameron

On Mon, May 16, 2022 at 12:41 AM Richard W.M. Jones <rjones at redhat.com>
wrote:

> On Sun, May 15, 2022 at 03:29:48PM -0800, Cameron Showalter wrote:
> > Hi Rich!
> >
> > I haven't heard of virt-v2v before, so it took a bit to learn about it.
> It's
> > definitely the right direction! You still have to go into Window's Device
> > Manager, and update all the virtio devices after, but that's minor.
>
> After a v2v conversion Windows will install the new devices
> automatically.  That happens after boot but doesn't involve any user
> intervention.
>
> > I still don't get the qemu-guest-agent through this, so
> > virt-manager's "Auto-resize VM with window" is still disabled. I can
> > get it enabled by going to
> > https://www.spice-space.org/download.html#windows-binaries and
> > downloading "spice-guest-tools" to the VM. I'm guessing this isn't a
> > part of virtio-win then. Any idea how to best automate this step? I
> > guess I can have the exe pre downloaded on the host, then mount it
> > in and run it.
>
> Libguestfs can install any binary you like into the VM and run it on
> next boot.
>
> We don't happen to install the Spice tools (not least because they're
> no longer being developed by Red Hat - Spice was removed in RHEL 9),
> but you could easily install that tool, or write a similar standalone
> tool that does just the single operation needed for the "Auto-resize
> VM" function.
>
> We even ship a tool chain on RHEL to cross-compile such Windows
> binaries.  Look at the mingw* packages.
>
> > virt-v2v's not changing some of the xml to use virtio (Networking
> > from "e1000e", and Storage from the sata drive), but it is adding a
> > lot of aliases.  Is this expected?
> >
> > Here's the command:
> > virt-v2v-in-place -ic qemu:///system -i libvirt Windows10-test --root
> single
> >
> > I'm doing it in place since I don't want a new VM. I can take a
> > snapshot before (And probably need to save the xml too), and restore
> > back to them if that command fails.
>
> You probably need to supply virt-v2v with the virtio-win disk,
> otherwise it cannot install virtio drivers and won't change the
> default devices.
>
> Nevertheless, virt-v2v is *not* the right tool to be using here.  It's
> only for converting guests from VMware.  I was just pointing out that
> the problem of installing drivers into Windows is a solved one, so
> take a look at how virt-v2v does it and do it that way.
>
> We could definitely use a standalone tool for installing drivers into
> guests -- and indeed another tool to discover what emulated a hardware
> an existing guest needs.  I have often thought about writing such
> standalone tools but never got around to it.
>
> Rich.
>
> > Thanks!
> > Cameron
> >
> > On Thu, May 12, 2022 at 6:58 AM Richard W.M. Jones <rjones at redhat.com>
> wrote:
> >
> >     You probably want to have a look at virt-v2v which does this sort of
> >     thing for Windows & Linux VMs.
> >
> >     Rich.
> >
> >     --
> >     Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/
> >     ~rjones
> >     Read my programming and virtualization blog:
> http://rwmj.wordpress.com
> >     virt-builder quickly builds VMs from scratch
> >     http://libguestfs.org/virt-builder.1.html
> >
> >
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20220517/7558f031/attachment.htm>