[libvirt] qemu_driver migrateuri handling broken?

[Gregor Schaffrath]

On Wed, Sep 23, 2009 at 10:05:36AM +0200, Chris Lalancette wrote:
> >> We are working on a new tunnelled migration scheme that will be
> >> uniform across drivers.
> > ic - To be honest, I was confused by the migrateuri anyhow, since I
> > considered the situation where libvirt traffic is tunneled via SSH, but
> > Xen-/KVM-/foo communication may be direct a rather rare exception (or am
> > I mistaken?) (I understood that this was the rationale behind the
> > hostname-Query in the first place)
> 
> Well, the rationale is that you may have two paths to get to a machine, and you
> may only want to allow migration traffic on one of them (say, a direct
> cross-over) since the data goes across unencrypted.  So you might have a machine
> with eth0 and eth1, where eth0 is exposed to the world, and you have libvirtd
> listening on eth0.  But then when you actually do the migration, you want it to
> send the data across on eth1.
> 
> Note also that libvirt traffic tunnelled via ssh isn't the only method, you can
> also attach to libvirtd via TLS and TCP (with SASL encryption).
Hm - I acknowledge that there might be such situation, so you want to
have this feature. 
And as long as there's a way around the assumption that the remote hostname - 
especially without a domain part - is resolvable at the sending side, my only
concern would be a unified migrateuri syntax, which seems to be on the
way :) .

I guess my actual confusion is rather about the choice of the default
behaviour, than the feature's existence (since I never had the
split-path-situation in this context, but definitely had an environment where 
`hostname` output would not be resolvable, and I deemed the latter more probable
than the prior) - but that's certainly debatable.

> > the part doesn't do much besides setting the port - the hostname is even
> > ignored ;) ... and the error comes from the receiving side - not the
> > sending one.
> > 
> > Therefore as far as I see, the only thing broken is that now the sending
> > side can't choose the listening port number on the receiving side (is
> > this a debugging feature?)
> 
> Not exactly a debugging feature, more a "give more control to the admin".  If
> you do not supply a migrateuri, then libvirtd will choose a port between 49152
> and 49216.  However, if you don't want to open up all of those ports on your
> firewall, you can specify a migrateuri to say "use *this* port", and then you
> only have to open up one port in the firewall.  So we do need to allow the
> migrateuri, and removing it isn't really feasible.
Again acknowledged, but then I would request a possibility to
specify the IP, while leaving the port choice up to the receiving side
(basically making the port specification optional rather than
mandatory).

My rationale for the request would be that when you consider scripted
(i.e. automated) management of virtual nodes along with the possibility
of several concurrent migrations, the port choice on the sending side
is likely to turn out awkward, even though you may have an environment
without DNS, or with dual-homing (and therefore need to specify the 
migrateuri).

> 
> The tunnelled migration stuff should make this a bit easier, although we'll
> still have to allow the migrateuri type stuff for the dual-homed situation.
Hm - I don't know what exactly you have in mind (not familiar with the
plans). But I'd like to bring forward the point that as a user I was quite
confused, because I intuitively expected a different default behaviour
than the one libvirt currently exhibits (i.e., I was not prepared to get
a 'hostname could not be resolved' type of error, when I specified an IP
as migration destination ;) ).

Cheers,
	Gregor.

> 
> -- 
> Chris Lalancette