Bug 596016
Summary: | Live Migration of KVMs uses wrong interface in cluster | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Masahiro Matsuya <mmatsuya> | ||||
Component: | rgmanager | Assignee: | Lon Hohberger <lhh> | ||||
Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | urgent | ||||||
Version: | 5.5 | CC: | clalance, cluster-maint, crobinso, djansa, edamato, liko, robin, stanislav.polasek, tao, tdunnon, virt-maint, xen-maint | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | rgmanager-2.0.52-6.13.el5 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 596918 (view as bug list) | Environment: | |||||
Last Closed: | 2011-01-13 23:26:42 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 595992 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Masahiro Matsuya
2010-05-26 06:37:04 UTC
Created attachment 416684 [details]
proposed patch
My understanding is the destination is taken from the URI, so either there is a DNS or /etc/hosts mixup causing sk010002-hb to be confused with sk010002, or there is a bug in libvirt requiring it to be specified twice for some reason: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization_Guide/sect-Virtualization-KVM_live_migration-Live_KVM_migration_with_virsh.html The hostname libvirt is trying to migrate to is the output of 'virsh hostname' on the destination host, which in this case is sk010002. As was recently discussed upstream, this is a deficiency of the libvirt migrations protocol. Possible solutions: - Have virsh always build a --migrateuri for qemu if the user doesn't specify one, using the hostname from the destination connection. Generating a port will suck though, and be much less safe than the destination host doing it. This is basically what virt-manager already does. - Put a qemu specific hack in virDomainMigratePrepare2 in libvirt.c, which takes the URI the destination threw back at us, and splice in the hostname from the dest URI. - Find some way to fix the remote libvirt driver so it sees the libvirt URI we are using on using on the source host. No idea if this is even possible. Yeah, all these solutions suck pretty bad. Ok, so it's something we need to work around in rgmanager. Cole, do you know if this is still a problem in F12 or RHEL6 beta? It's not really solved upstream yet, so it's a problem for all libvirt versions. Adding a way for the user to specify the --migrateuri option in rgmanager would be useful anyways: there may be times when the user explicitly does not want to use the same hostname/interface that the libvirt URI is using (which is why we have the option). Libvirt should still do the intuitive thing by default though. Ok. We'll work around it in rgmanager. To that end, Masahiro's patch looks correct, though it might be slightly more correct to use the original hostname in the migrate-uri instead of the target hostname. I.e. this would, I think, be the most correct: virsh migrate --live su21k003 \ qemu+ssh://sk010002/system tcp:sk010002-hb ^^^^^^^^ Masahiro's patch would provide the following, which is 100% acceptable I believe: virsh migrate --live su21k003 qemu+ssh://sk010002-hb/system tcp:sk010002-hb ^^^^^^^^^^^ Since the latter requires the least amount of code changes and the work is done, I vote for that we use Masahiro's patch ;) An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0134.html |