[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Re: Next features and target for development

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.


Anthony Liguori


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]