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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list