| Summary: | virsh migrate fails with "Undefined Error" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ian Allison <iana> |
| Component: | libvirt | Assignee: | Dave Allan <dallan> |
| Status: | CLOSED WORKSFORME | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1 | CC: | acathrow, dallan, jyang, mzhan, rwu, weizhan |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-03-28 17:40:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Ian Allison
2011-09-21 18:31:34 UTC
There are a variety of reasons that you might see this error, and qemu unfortunately doesn't provide detail on which one might be causing your problem. Generally the most common two causes are: 1) a firewall is blocking the migration. I'm guessing you know that since you mentioned that you've already flushed the iptables rules except for the ones added by libvirt, but unless you need the ones added by libvirt, flush all of them and stop iptables. I wonder if there's a default rule in there that's rejecting the traffic. 2) DNS resolution is broken. Migration is sensitive to DNS errors. Confirm that both forward and reverse DNS is configured correctly throughout your network. In particular, confirm that both source and destination can resolve and reverse resolve each other. If you have a support contract with Red Hat, I recommend that you open a support ticket. Hi Dave, (In reply to comment #2) > 1) a firewall is blocking the migration. I'm guessing you know that since you > mentioned that you've already flushed the iptables rules except for the ones > added by libvirt, but unless you need the ones added by libvirt, flush all of > them and stop iptables. I wonder if there's a default rule in there that's > rejecting the traffic. > > 2) DNS resolution is broken. Migration is sensitive to DNS errors. Confirm > that both forward and reverse DNS is configured correctly throughout your > network. In particular, confirm that both source and destination can resolve > and reverse resolve each other. I've removed all firewall rules and checked forward and reverse DNS entries are resolving correctly on both hosts, but I still get the same problem. > If you have a support contract with Red Hat, I recommend that you open a > support ticket. I'm further down the foodchain than that. I need to convince one of the higher-ups to do it but I'm not holding my breath. Thanks, Ian. Can you provide the details of the NFS mount used on both hosts? Also, (I realize a longshot here) can you try with a test host on iSCSI? This should be duplicated with https://bugzilla.redhat.com/show_bug.cgi?id=615941, and the problem is fixed after we changed to use qemu fd: protocol, see https://bugzilla.redhat.com/show_bug.cgi?id=720269. So, both these 2 bugs might be able to closed now. Osier, the fix you're referring to would give him a better error and probably tell him what the problem is, but it's not going to make his problem go away. IIUC, he's filing this bug against the fact that his migration is failing, not about the error message. Hi Dave, The NFS mount is a version 3 mount coming from a NetApp rim:/vol/kvm/kvm_ug_a /nfs/kvm_ug_a nfs vers=3,defaults,_netdev 0 0 We haven't had much luck with our iSCSI setup so I can't get any debugging information from there at the moment. It sounds like name resolution is the most likely culprit so I'll keep looking there for any problems. (In reply to comment #7) > We haven't had much luck with our iSCSI setup so I can't get any debugging > information from there at the moment. It sounds like name resolution is the > most likely culprit so I'll keep looking there for any problems. Ian, did you ever find root cause? (In reply to comment #10) > (In reply to comment #7) > > We haven't had much luck with our iSCSI setup so I can't get any debugging > > information from there at the moment. It sounds like name resolution is the > > most likely culprit so I'll keep looking there for any problems. > > Ian, did you ever find root cause? Nope, in our current setup migration is rare enough that it hasn't been a major issue, whenever there has been an kernel, kvm or libvirt update I try again but I haven't looked at in a while. If I get time this weekend I might give it a go. Before you do that, confirm the forward and reverse DNS information on both the source and destination hosts. It might be a little less work that actually trying a migration. Personally I like the 'host' command for that, but choose your poison! :) Ian, any word? (In reply to comment #13) > Ian, any word? Sorry for the delay, just back from a holiday. The machines in question are still running 6.1 we are in the process of updating the guests but there are a lot of them and we dont expect to be updating the hosts till next week. As soon as we are done I will try again, I noticed that 6.2 brings a bunch of VM updates. I should have mentioned that I've checked the forward and reverse entries for the source and destination machines from both the source and destination (all combinations). Everything looks fine. The forward mapping is just an A record and the reverse mapping picks out the correct hostname.domainname in all cases. Any new information? BTW, are you able to migrate on any hosts? I'd really like to see the output from a 6.2 host as the error reporting has been greatly improved. We updated everything to 6.2 and the problem is gone! thanks so much. Please let me know if you need any more information - otherwise feel free to close the bug. -Thanks Good to know; I'll do that. Thanks. |