[Libvir] Re: Next features and target for development
Anthony Liguori
anthony at codemonkey.ws
Wed Jul 11 16:52:56 UTC 2007
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
>
>
More information about the libvir-list
mailing list