Moving to virt-manager

Glad it’s working!

You can move the VM file (I assume qcow2 or raw) to whatever place you want, but you have to change the path in the VM configuration to inform QEMU of the disk location.
In virt-manager preferences, enable XML editing, then edit the XML of the disk and update the path to whatever new location you will use. Apply changes and boot the machine and it should work.

If SELinux is enabled, you might need to label the new directory containing your images to have the same context as /var/lib/libvirt/images

See 5.6. SELinux Contexts – Labeling Files Red Hat Enterprise Linux 6 | Red Hat Customer Portal for some commands that could be handy

It doesn’t appear to be necessary. I have the VMs in my home directory, labeled like any other file in the home and it works normally.

1 Like

You probably meant /var/lib/libvirt/images

A combination of autocorrect and not being able to check. Corrected, thanks

1 Like

So

  • I exported the XML of my Windows 11 installation.
  • I moved the disk image to another partition.
  • I deleted the VM
  • I imported the XML and corrected the path to the disk image

There was an issue with accessing the disk, and virt-manager fixed that (I think it changed the user and group for the image file from “root:root” to “qemu:qemu”

I started the Virtual Machine from the new position, and it worked.

Now, I’d like to understand WHY Windows got there was a modification in the configuration because the PIN I used to log in is not valid anymore. I need to log in with my credentials and set a new PIN.

Exporting and importing the XML wasn’t necessary as you could edit it on the spot (in virt-manager).

I have no idea.

Windows saw the underlying virt manager was changed and thus understood it may have been running on different hardware interface.

Remember that windows keeps track of the hardware it is installed on as well as the user account so microsoft can track licensing. The virtual interface change counts as new hardware.

Exported for backup purposes. And to test if everything works. I forgot to mention that.

Mmh. So then, because I’ll use a new license on the virtualized Windows, what can happen when I’ll move everything to a new laptop?
In my mind, a virtualized machine is a box that can be moved to a new PC and used.
It’s not like that, then.

Windows license is bound to the hardware, so changing the hardware configuration too much may make you lose the license. I don’t know if it is wise to use it on a VM.

Ok, I agree.
But … if I’m using QEMU on Fedora and virtualizing Windows, why is the hardware “changing”?
QEMU is unlike an “interface” between physical hardware and virtual machines, so I can change the hardware and move the VM. Or not?
Or am I missing something?

Of course, I’ll move the XML and the QCOW2 file together.
So, I’ll not change “hardware”.

You are right, even if I export the XML, delete the VM, import the XML, Windows asks me for a new PIN at startup.
Comparing the old and new XML gives same file.

VM config is generally not limited to XML, but also includes NVRAM:

  • ~/.config/libvirt/qemu/nvram
  • /var/lib/libvirt/qemu/nvram

Also, the default CPU type is host-passthrough, which is host-specific.

I thought the initial post was about moving from VMware to QEMU. That is a change of the virtual “hardware” the VM is using.

Relocating the qcow2 image to a different directory does not change that interface, but I have no clue what other things windows may look at. Possibly just the action of exporting then importing the xml file triggered the need for a new pin.

A new install on a new VM manager though is just that, a new install on new hardware.

Yes, I moved from Vmware to QEMU, I can save a lot of time and money.
Maybe it’s better to open a new thread?

I don’t think this is straying off-topic. The initial post was about moving from VMware to QEMU then the following was about configuring the VM on QEMU. Simply following on about using virt-manager as is in the title remains relevant.

If I try to change it to “qemu64”, can it be an attempt to fix the issue?
Or it’s a losing battle from the start?

Everything is mostly the same as long as one is still using QEMU and windows is in the VM.

But, since the CPU (and its hardware ID) is host hardware specific, there is a hardware difference seen by windows. How that would affect ones licensing I don’t know for sure.

Did you edit the virt manager xml to use the same mac address for the network that vmware was using?

There might be something else to copy from vmware config to xml, but do not recall of the top of my head.

Is the cpu model the same?