On Wed, Mar 04, 2009 at 11:03:17AM +0100, Chris Lalancette wrote: > > These are all just minor auth credentials/acl config tasks that the admin > > has to deal with for normal remote usage already, so I don't see that they > > present a particular problem for migration > > Yes, they are certainly all solvable from the admin's point-of-view, so they are > not show stoppers. The thing is that I think admins will have a difficult time > discovering what the problems are when migration doesn't work for them. There > are just so many combinations that it's very easy for the admin to get one of > them wrong, and then it may be difficult to figure out exactly what they need to > do to get it working. On the other hand, having a dedicated channel makes it > relatively easy; if the admin is having problems, then the answer is going to be > "open port XYZ on the destination", and that will usually solve the problem. From my POV, I think getting the auth fixed is a matter of installing proper files on a machine and of the responsability of the sysadmins basically and purely within their realm. On the other hand opening a new port is a decision involving network admins and security, it's not the same scope within a company with strict policies. I would really stay with the existing RPC model and avoid the requirement of adding a new open port, from a pure sysadmin "upgrade" perspective this can turn into a nightmare, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list