All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [RFC V8 2/3] libxl domain snapshot API design
Date: Mon, 8 Dec 2014 11:24:11 +0000	[thread overview]
Message-ID: <20141208112411.GD17128@zion.uk.xensource.com> (raw)
In-Reply-To: <20141208111214.GC17128@zion.uk.xensource.com>

On Mon, Dec 08, 2014 at 11:12:14AM +0000, Wei Liu wrote:
> On Mon, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote:
> > 
> > 
> > >>> On 12/6/2014 at 12:06 AM, in message
> > <20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
> > wrote: 
> > > I have to admit I'm confused by the back and forth discussion. It's hard 
> > > to justify the design of new API without knowing what the constraints 
> > > and requirements are from your PoV. 
> > >  
> > > Here are my two cents, not about details, but about general constraints. 
> > >  
> > > There are two layers, one is user of libxl (clients -- xl, libvirt etc) 
> > > and libxl (the library itself). 
> > >  
> > > 1. it's better to *not* have storage management in libxl. 
> > >  
> > > It's likely that clients can have their own management functionality 
> > > already.  I'm told that libvirt has that as well as XAPI. Having this 
> > > functionality in libxl is a bit redundant and requires lots of work 
> > > (enlighten libxl on what a disk looks like and call out to various 
> > > utilities). 
> > 
> > Thanks Wei and Ian for your reply. We did have much discussion around
> > can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot
> > (e.g. disk snapshot process should not in xl? domain_snapshot_delete
> > should not in libxl?), and confusing because have different ideas. So,
> > settling it down is helpful.
> > 
> > Talking about libvirt, it does provide storage management but through
> > storage pools and volumes. But usually, we don't use storage pool/vol
> > but directly use backend files, then libvirt storage driver can not
> > manage them. And for libvirt vol, functionality in storage driver is
> > limited, at least 'snapshot' cannot be done. So, libvirt side also
> > needs to add codes to handle disk snapshot, quite like xl does.
> > 
> 
> OK, so I take it that libvirt can be completely out the picture? I mean,
> it's not a requirement for you to integrate with libvirt?
> 
> I was thinking a stack like this when I replied:
> 
>   libvirt: manages snapshot (including storage snapshot)
>   libxl
>   [other lower level stuffs]
> 
> While I read from your reply, libvirt doesn't have that functionality
> (or very limited), so you would like to do things like:
> 
>   libvirt (or your homebrew toolstack)
>   xl      (xl or libxl manages domain snapshots)
>   libxl
>   [other lower level stuffs]
> 

Note, I'm in no way endorsing this approach. This is my understanding
(or misunderstanding) of what you intended to do. I started drawing
pictures so that we can understand each other better.

Wei.

  reply	other threads:[~2014-12-08 11:24 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-10  8:17 [RFC V8 0/3] domain snapshot document Chunyan Liu
2014-11-10  8:17 ` [RFC V8 1/3] libxl domain snapshot introduction Chunyan Liu
2014-11-10  8:17 ` [RFC V8 2/3] libxl domain snapshot API design Chunyan Liu
2014-11-10 17:04   ` George Dunlap
2014-11-11  8:07     ` Chun Yan Liu
2014-11-13  3:07       ` Chun Yan Liu
2014-11-13 11:41         ` Ian Campbell
2014-11-25  9:08           ` Chun Yan Liu
2014-11-28 15:43             ` Ian Campbell
2014-12-03  6:14               ` Chun Yan Liu
2014-12-05 14:02                 ` Ian Campbell
2014-12-05 16:06   ` Wei Liu
2014-12-05 16:11     ` Ian Campbell
2014-12-05 16:22       ` Wei Liu
2014-12-08  7:34     ` Chun Yan Liu
2014-12-08 11:12       ` Wei Liu
2014-12-08 11:24         ` Wei Liu [this message]
2014-12-09  5:04         ` Chun Yan Liu
2014-12-09 11:11           ` Ian Campbell
2014-12-10  3:46             ` Chun Yan Liu
2014-12-12 16:22               ` Ian Campbell
2014-12-15  3:13                 ` Chun Yan Liu
2014-11-10  8:17 ` [RFC V8 3/3] xl snapshot-xxx Design Chunyan Liu
     [not found] <547F479A0200006600041019@soto.provo.novell.com>
2014-12-03  6:26 ` [RFC V8 2/3] libxl domain snapshot API design Chun Yan Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141208112411.GD17128@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=JFEHLIG@suse.com \
    --cc=cyliu@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.