Re: [libvirt] Question about migration requirement
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