+++ This bug was initially created as a clone of Bug #1638882 +++ Description of problem: In KubeVirt we have a somewhat unique use case where we need to migration between two libvirt environments that have the same hostname. There's a check in libvirt that prevents this from being possible. "Attempt to migrate guest to the same host" Normally that makes complete sense. However for our use case, we are migrating a VM between two containerized environments scheduled by kubernetes that exist on different hosts. We need both the source and target containerized environments (pods) to look identical in order to operate within kubernetes in a predictable way. This makes libvirt think we're attempting a live migration to the same node when in fact we are not. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. attempt to perform a live migration between two nodes with the same hostname. Additional info:
Is this requirement still relevant from POV of CNV?
Martin, We have a workaround in place, however, it's not very straight forward and I think we'd prefer not to have it.
Vladik, what does the hostname on both sides look like? Is it plain "localhost" or something that's not FQDN?
Let me just take a step back and describe the problem. As you know, KubeVirt runs libvirt in a container that, in most cases, has no external network. In order to support live migration, we proxy the connection between the source and the destination libvirt. The proxy opens the relevant ports inside the container and let's libvirt connect to it to initiate the migration. However, from Libvirt's perspective, it connects to a node that has the same hostname.
(In reply to Vladik Romanovsky from comment #4) > That's a valid use case and indeed libvirt should not try to match host names when it already checks host UUID. Hopefully, you don't set the same host UUID for containers. The host UUID can be seen here: virsh capabilities | xpath -e "/capabilities/host/uuid/text()" Libvirt gets the UUID from /sys/devices/virtual/dmi/id/product_uuid.
Patch proposed upstream: https://www.redhat.com/archives/libvir-list/2020-March/msg00004.html
I've just pushed the fix upstream: 6799b72d92 qemu: Don't compare local and remote hostnames on migration v6.1.0-32-g6799b72d92
After checking Bug 1638889 - RFE: allow live migration over unix socket, I think the logic that blocks migration in cnv may be here instead of src/qemu/qemu_migration_cookie.c: src/libvirt-domain.c: 3273 static int 3274 virDomainMigrateCheckNotLocal(const char *dconnuri) 3275 { 3276 g_autoptr(virURI) tempuri = NULL; 3277 3278 if (!(tempuri = virURIParse(dconnuri))) 3279 return -1; 3280 if (!tempuri->server || STRPREFIX(tempuri->server, "localhost")) { 3281 virReportInvalidArg(dconnuri, "%s", 3282 _("Attempt to migrate guest to the same host")); 3283 return -1; 3284 } 3285 3286 return 0; 3287 } 3288 So I'm not sure whether the fix in comment 6 would meet the requirement of cnv, or maybe this bug can be covered in Bug 1638889.
(In reply to Fangge Jin from comment #11) > After checking Bug 1638889 - RFE: allow live migration over unix socket, I > think the logic that blocks migration in cnv may be here instead of > src/qemu/qemu_migration_cookie.c: > > src/libvirt-domain.c: > 3273 static int > 3274 virDomainMigrateCheckNotLocal(const char *dconnuri) > 3275 { > 3276 g_autoptr(virURI) tempuri = NULL; > 3277 > 3278 if (!(tempuri = virURIParse(dconnuri))) > 3279 return -1; > 3280 if (!tempuri->server || STRPREFIX(tempuri->server, "localhost")) { > 3281 virReportInvalidArg(dconnuri, "%s", > 3282 _("Attempt to migrate guest to the same > host")); > 3283 return -1; > 3284 } > 3285 > 3286 return 0; > 3287 } > 3288 > > So I'm not sure whether the fix in comment 6 would meet the requirement of > cnv, or maybe this bug can be covered in Bug 1638889. Oh yeah, definitely. My patches address the issue where hostname on both sides of migration are the same. They don't event attempt to address migration to the same host - which "localhost" is. But very good catch!
It is also more complicated when you throw peer2peer into the mix. I'm trying to cover all of that in Bug 1638889.
Verify with: libvirt-client-6.5.0-1.module+el8.3.0+7323+d54bb644.x86_64 Results: Migration succeeds Steps: 1. Prepare two hosts with same hostname 1-1) set src host's hostname same as dst host's, then restart src libvirtd 2. Start a vm, do live migration: 2-1) # virsh start rhel7-min 2-2) # virsh migrate rhel7-min qemu+ssh://10.0.151.169/system --live --verbose --migrateuri tcp://10.0.151.169 Migration: [100 %]
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (virt:8.3 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:5137