On 06/04/10 - 11:43:37AM, Bruce Rogers wrote: > I've noticed that there seems to be some additional requirements placed on a migration, as compared to just remote management via libvirt. > > For example, when I try to do the following: > > virsh migrate running_vm_name qemu+ssh://1.2.3.4/system > > there seems to be a requirment that both the source and target hosts must resolve 1.2.3.4 the same way as far as naming services is concerned. Without being able to resolve to the same name on both the source and target, the migration will fail. > > Note that I can ssh to the other machine just fine using the ip address, or even do the following without problem: > > virsh -c qemu+ssh://1.2.3.4/system <some-command> > > Is this additional <requirement> for migration intentional (some security issue, etc), or is it just an artifact of implementation, which could be fixed to not be needlessly restrictive. It's mostly an artifact of the design, which unfortunately can't really be fixed because it would break the on-the-wire protocol. That being said, there are a couple of ways to get around this problem: 1) virsh migrate takes another optional parameter, which is "migrateuri". If you specify this, then it takes the URI from you as gospel and doesn't try to auto-detect it. This is probably what you want to do short-term. 2) virsh migrate also supports a "tunnelled" migration option. In this mode all of the migration data is captured by the source libvirtd, dumped over the normal libvirt RPC mechanism, picked up by the remote libvirtd, and then sent to the destination machine. This is a *much* preferable implementation; you don't have to open up random ports on your firewalls (just the libvirt communication port), you can optionally encrypt the data, and it doesn't suffer from the problems you point out above. I hope to someday make this the default migration mechanism, but the code is a bit immature both in libvirt and in qemu, so it need some work first. -- Chris Lalancette -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list