Questions about migrating VMs (with virt-manager)
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? When migration finishes, the VM on the source host will still be accessible but will shut down. Is that true? Can I prevent the VM from shutting down during the migration? Thank you.
On Tue, Apr 07, 2026 at 12:55:06 +0200, fc26wuqa@studserv.uni-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.
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". I am a little afraid my qemu installation or the VM could break with an update. Is there a way to still migrate? On 4/7/26 14:54, Peter Krempa via Users wrote:
On Tue, Apr 07, 2026 at 12:55:06 +0200, fc26wuqa@studserv.uni-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.
On 4/8/26 12:37, fc26wuqa@studserv.uni-leipzig.de 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, fc26wuqa@studserv.uni- 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.
Hello, thank you for your answer. What do you mean with "Providing a virt type"? My Problem is that I am migrating from a physical Server to a VM, that does not support KVM. When I don't change the xml I get the error:"error: unsupported configuration: Emulator '/usr/bin/qemu-system-x86_64' does not support virt type 'kvm'" On 4/9/26 09:35, Michal Prívozník via Users wrote:
On 4/8/26 12:37,fc26wuqa@studserv.uni-leipzig.de 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,fc26wuqa@studserv.uni- 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.
On 4/9/26 12:51, fc26wuqa@studserv.uni-leipzig.de wrote:
Hello, thank you for your answer.
What do you mean with "Providing a virt type"?
My Problem is that I am migrating from a physical Server to a VM, that does not support KVM.
Then you can't migrate. The only solution here is to enable nested virtualization: https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-...
When I don't change the xml I get the error: "error: unsupported configuration: Emulator '/usr/bin/qemu-system-x86_64' does not support virt type 'kvm'"
Rightfully so. If nested virtualization is not enabled, then any VM ran inside the so called L0 hypervisor doesn't have access to hardware features required for KVM. The reason why you can't switch from <domain type='qemu'/> to <domain type='kvm'/> (or vice versa) is that it's part of guest ABI (i.e. guest can "see" if its running under KVM). And when migrating, this would change, all of a sudden and guest might not be happy about it. Michal
participants (3)
-
fc26wuqa＠studserv.uni-leipzig.de -
Michal Prívozník -
Peter Krempa