On 4/8/26 12:37, [email protected] wrote: > Hello, thank you, this cleared up my confusion. > > Do you have experience with migrating VMs? > > I am trying to migrate a very old qemu installation/VM, for which its > machine architecture is pc-q35-5.2. This Architecture is currently > deprecatred and I am getting the error: > "error: unsupported configuration: Target domain virt type qemu does not > match source kvm".
This tells you that the XML you supplied to 'virsh migrate' is different (in an incompatible way) to the current one. Currently, your machine uses 'kvm' but in your XML you provided 'qemu' or no virt type (<domain type=''/>). When providing altered migration XML what I tend to do is 'virsh dumpxml $dom' to obtain the current one and only change things I'm interested in (e.g. paths to sockets, etc.). Everything else I keep verbatim. > > I am a little afraid my qemu installation or the VM could break with an > update. It should not. That's the whole point of machine types. > Is there a way to still migrate? Sure. Provide virt type or do as I suggest. Michal > > On 4/7/26 14:54, Peter Krempa via Users wrote: >> On Tue, Apr 07, 2026 at 12:55:06 +0200, [email protected] >> leipzig.de wrote: >>> Hello, >>> >>> I want to migrate multiple VMs to a new host. In the process, several >>> questions came up, where I could not find an answer. I am using >>> virt-manager version 1:5.0.0-5+deb13u1. >>> >>> I reordered and renamed my storage pools: When migrating a VM, how can I >>> move the VM to a specific storage pool? Will the VM be moved to a >>> storage >>> pool with the same name by default? >> While virt-manager (likely) doesn't support this, with 'virsh migrate' >> you can provide a new XML with updated definition where you change the >> storage pool names. Look for 'virsh migrate --xml'. To get a XML >> suitable to be modified you can use 'virsh dumpxml --migratable' >> >> >>> When migration finishes, the VM on the source host will still be >>> accessible >>> but will shut down. Is that true? >> If the VM was running originally (thus it's not offline migration) the >> VM will be running on the source host up until the "switchover" point. >> After that the source VM process is terminated and continues running on >> the destination in the exact state it had right before switchover. >> >>> Can I prevent the VM from shutting down >>> during the migration? >> Do you mean 'pausing' of the VM during migration (the virtual CPUs being >> stopped while its being migrated?)? -> yes you can do that use '--live'. >> >> Note that it will increase the amount of data copied over as any memory >> page which was already migrated to destination but was written to by the >> guest OS while it was running on the source will need to be re-copied. >> >
