[Libvir] Re: Next features and target for development

[Anthony Liguori]

Daniel Veillard wrote:
> On Wed, Jul 11, 2007 at 08:07:48AM -0700, Dan Smith wrote:
>   
>> AL> The goal is to eliminate the distinction between savevm/migrate since
>> AL> they are really the same thing (savevm just pauses the VM first).
>>
>> But from a high level, there are (at least) two distinct management
>> operations in my mind: relocation and checkpointing.  Relocation
>> implies that a guest leaves the source machine and appears on the
>> destination.  Checkpointing implies that the domain doesn't move.  If
>> we take these two actions, can we not still provide for all the cases?
>> For example:
>>
>>   /* Migrate explicitly undefines the host */
>>   virDomainMigrate(dom, "host"); /* Xen case */
>>   virDomainMigrate(dom, "tcp://host"); /* qemu case */
>>   virDomainMigrate(dom, "lvm://foo"); /* qemu error case */
>>  
>>     

This is not sufficient for KVM.  The Xen notion of migration is 
fundamentally broken.  The architecture is such that on any arbitrary 
machine you can just issue a command and with no other information and 
it can migrate to any other Xen machine.  It completely ignores issues 
like authentication and authorization.

For a saner migration implementation, at least the following is needed:

1) a way to tell a destination machine that it can receive a particular 
migration
2) a way to tell the source machine to migrate to that destination
3) a way to pass credential requests through to the caller of libvirt

#1 is not needed for Xen b/c Xen's migration is broken.  For KVM, this 
may be needed to actually make sure a QEMU instance is listening for an 
incoming migration.  This step is not strictly needed for the ssh:// 
protocol but is strictly needed for the tcp:// protocol.

#3 is needed by the ssh:// migration protocol.  One can imagine libvirt 
making wrappers to tunnel Xen migration traffic too in which case both 
#1 and #3 would also be needed.

>>   /* Checkpoint does not undefine the host */
>>   virDomainCheckpoint(dom, "foo"); /* Xen unimplemented case */
>>   virDomainCheckpoint(dom, "lvm://foo"); /* qemu case */
>>
>> Is that not sane?
>>     
>
>   I really would not mix the two at the API level. W.r.t. the virDomainMigrate
> please recheck what I suggested initially, you really want a pointer to 
> an existing connection, not an URI and hostname. Sure you could get the
> virConnectPtr based on the URI, but it's better to rely on the user to
> do that step independantly.
>   

You need a URI.  It's not always just a hostname and a port.  Consider 
the two current ways of KVM migration ssh://[user@]host/ and 
tcp://host:port.

The best interface for QEMU/KVM would be a:

virDomainSend(dom, "url://....");

and a:

virDomainReceive(conn, "url://...");

For tcp://, recv would launch a qemu instance listening on the right 
port.  For ssh://, recv would be a nop.

Such an interface could easily support checkpointing, save, resume, etc.

If you wanted to introduce a higher level interface for Migrate and 
Checkpoint, that would be fine too provided it just used these lower 
level functions and constructed appropriate URIs.

Regards,

Anthony Liguori

> Daniel
>
>