[libvirt] Question about migration requirement

Chris Lalancette clalance at redhat.com
Fri Jun 4 17:52:35 UTC 2010


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




More information about the libvir-list mailing list