[libvirt] [libvirt-users] cannot perform tunnelled migration without using peer2peer flag

Daniel P. Berrange berrange at redhat.com
Tue Jul 19 12:23:18 UTC 2011


On Tue, Jul 19, 2011 at 06:19:13AM -0600, Eric Blake wrote:
> On 07/19/2011 03:23 AM, Daniel P. Berrange wrote:
> >On Mon, Jul 18, 2011 at 01:11:42PM -0600, Eric Blake wrote:
> >>On 07/18/2011 04:11 AM, Osier Yang wrote:
> >>>于 2011年07月18日 10:07, zhang xintao 写道:
> >>>>Dear All
> >>>>I try to migration a kvm guest os to another host failed
> >>>>server: ubuntu 11.04 server
> >>>>virsh:migrate --live --tunnelled vm1 qemu+ssh://192.168.10.3/system
> >>>>error:Requested operation is not valid:cannot perform
> >>>>tunnelled migration without using peer2peer flag
> >>>
> >>>The error tells you all, you need to use "--p2p".
> >>
> >>That said, why can't virsh be smarter, and automatically request the
> >>right underlying flags without making the user also type --p2p?  Any
> >>problems with this patch?
> >
> >It was done to leave open the possibility of supporting a
> >TUNNELLED mode, which was independant of P2P mode in the
> >future. It isn't entirely likely, but I didn't want to lock
> >ourselves out of it with this kind of patch
> 
> But if we ever reach that point, could we then revert this patch at
> that time, to where the user once again has to tell virsh both --p2p
> and --tunnelled?  Or would such a change be considered a regression
> in behavior at that time for existing scripts that were foolishly
> relying on the UI shortcut, and hence virsh should never learn the
> UI shortcut in the first place?  If the latter, then we should
> revert the patch that just went in so that 0.9.4 doesn't lock us
> into causing a future regression.

It would be a regression, but also it would mean old virsh releases
would not be able to operate against new libvirtd releases.

Basically, virsh shouldn't make any assumptions based on the current
way things are implemented in libvirtd, since it cannot expect to be
running against a matching version. Old virsh should work against new
libvirtd, and vica-verca. This is the same case as the checking of
flags in src/libvirt.c vs the individual drivers.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list