[Libvir] Re: Next features and target for development

Daniel P. Berrange berrange at redhat.com
Wed Jul 11 17:06:32 UTC 2007


On Wed, Jul 11, 2007 at 11:57:28AM -0500, Anthony Liguori wrote:
> Dan Smith wrote:
> >DV> you really want a pointer to an existing connection, not an URI
> >DV> and hostname. Sure you could get the virConnectPtr based on the
> >DV> URI, but it's better to rely on the user to do that step
> >DV> independantly.
> >
> >So that implies that in order to perform a migration with libvirt, the
> >user will need the libvirt daemon running and accessible on the remote
> >machine, is that right?  If so, why should this be necessary?
> >  
> 
> 1) It's required for tcp:// migration in QEMU/KVM
> 
> 2) Xen is insane for allowing arbitrary incoming migrations from 
> anywhere.  When the Xen migration model is made more sane, you'll 
> probably be forced to tell a destination node that it should accept an 
> incoming migration for a particular domain.

Yep, that's one of the things on my hitlist for making Xen secure. Right
now if you enable migration in Xen you're basically opening up your Dom0
to anyone. One thing that has been discussed before is that you ask the
remote end for a 'one time token' of some form. When starting the migration
the source would send this token to the remote end which would check it
for validity before accepting the migration. So in this model you'd need
libvirt connections to both source & dest. So libvirt would get the token
from one connection, and use it when starting migration on the other.

So ultimately, if you want secure migration, you need to have a libvirt
connection to both ends.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 




More information about the libvir-list mailing list