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

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

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 */
>   /* 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.


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

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