> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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
