Re: [Xen-devel] [RFC V6] Libxl Domain Snapshot API Design

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-09-09 at 02:43 -0600, Chun Yan Liu wrote:
> Generally
> it could be like creating domain, xl can list all domains created by xl or 
> virsh,
> xl snapshot-list could list domain snapshots created by xl or virsh too. To
> show complete snapshot information, I think it's better to include these
> at libxl level.

I think we have a fundamental disconnect in what we consider a snapshot
to be like here and at what level of the toolstacl hierarchy they exist,
so I'm going to focus on just this one bit for now since there isn't
much point in moving forward with the rest until we've come to an
agreement on this.

My view is that libxl is primarily concerned with domains which are
actually running and the operations which can be performed on them.
Therefore it provides mechanisms for listing all running domains which
xl and libvirt etc can use to list all running domains.

However libxl does not concern itself with domains which are not
currently running, it simply has no idea about them. This knowledge of
non-running domains exists only at the higher levels of the toolstack.
(this is why I said carefully libvirt in the previous paragraph and not
virsh, since virsh accesses the higher level toolstack and can therefore
list non-running domains too)

With xl this is exposed quite fundamentally since a non running domain
exists only in the cfg file and disk images, which the user managed by
hand. When you save a domain it is to a user provided file, and after
that point libxl has no further knowledge of it.

With libvirt this manifests as libvirt keeping track of every domain's
configuration even when the domain is not running as part of its own
state. I'm not 100% sure where a saved domain goes with libvirt but once
it is saved I believe libxl no longer knows about the domain and it only
exists as part of the libvirt state.

A second consequence of this is that libxl has no concept of storage
management, i.e. it doesn't know anything about disk images except when
it is asked to attach one particular disk image to a domain. With xl
users do storage management by hand (with lvcreate and qemu-img etc)
whereas libvirt has its own storage management which it uses.

In my view a snapshot is more like a saved domain than a running one. As
such once the snapshot has been created then libxl should not need to
know anything more about it. The snapshotted domain of course keeps
running and libxl knows about that, but the snapshot itself is no longer
libxl's concern.

What this means is that in order to implement "xl snapshot-list" then
*xl*, not libxl, would need to manage those shapshots itself. Perhaps by
growing a whole bunch of snapshot and storage management functionality,
but more likely by passing this responsibility on to the user (i.e. "xl
snapshot-list" becomes "run ls on the directory where you store these
things"").

I think virst snapshot-list is more interesting, but AIUI libvirt's
datamodel already includes all of the storage and snapshot management
which is required here. It already keeps the state for non-running
domains and it already has infrastructure for managing disks and it
already knows about snapshotting of domains at a high level etc.

So I don't think there is any need (or even desire) for libxl to
replicate any of that functionality. It should concern itself with
taking a snapshot when asked and then forget all about it.

I think things work the same with e.g. qemu and other libvirt backends.
A qemu process only exists to track an actual running domain, all of the
other state including the configuration when the domain is not running
etc is all handled at the libvirt layer. When you take a snapshot of a
qemu backed domain then after that snapshot has happened the qemu
process knows no more about it. So in this way of thinking qemu and
libxl are functionally equivalent bits i.e. things which are used to
instantiate actual running domains and perform operations on them.

Does that make sense?

Perhaps my understanding of the libvirt datamodel is incorrect or
incomplete, so please point out if this is the case.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel