Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
On Mon, 2014-12-22 at 01:52 -0700, Chun Yan Liu wrote: > > >>> On 12/19/2014 at 06:27 PM, in message > >>> <1418984856.20028.17.ca...@citrix.com>, > Ian Campbell wrote: > > On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote: > > > > > '--name' meant to give a meaningful name (like: newinstall. Used as the > > > memory snapshot name and disk snapshot name). > > > > Where is this name stored and when and where would it be presented to > > the user? > e.g. For qcow2 internal disk snapshot, this name is stored within the disk. > When user wants to delete internal disk snapshot, it will be: > #qemu-img snapshot -d name disk Makes sense, thanks. Can you clarify in the doc with something like "name is used as an identifier in the underlying storage backend". Does it have to be unique? Sounds like it does. > > > That's good. Then we need to add some description to tell users about > > > the auto-generated domain snapshot name, disk snapshot name, > > > memory state file and external disk snapshot files, etc. > > > > We will need user docs and manpage updates, yes. > > > > > > > #e.g. to specify exernal disk snapshot, like this: > > > > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', > > > > > '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] > > > > > > > > > > #e.g. to specify internal disk snapshot, like this: > > > > > disks=[',,hda',',,hdb',] > > > > > > > > Ideally one or the other of these behaviours would be possible without > > > > needing to be quite so explicit. > > > > > > OK, I'll delete one. > > > > I don't object to having this more capable syntax as an option, so the > > user can override things if they wish, all I was suggesting is that the > > default ought to be something useful so the user doesn't need to say > > anything if they just want the toolstack to "do something sensible". > > I see. By default user doesn't need to specify 'disks' at all, then xl > will do internal disk snapshot to each domain disk. Right, or it could do an external snapshot to the directory it has been told the snapshot should live in. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
>>> On 12/19/2014 at 06:27 PM, in message >>> <1418984856.20028.17.ca...@citrix.com>, Ian Campbell wrote: > On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote: > > > '--name' meant to give a meaningful name (like: newinstall. Used as the > > memory snapshot name and disk snapshot name). > > Where is this name stored and when and where would it be presented to > the user? e.g. For qcow2 internal disk snapshot, this name is stored within the disk. When user wants to delete internal disk snapshot, it will be: #qemu-img snapshot -d name disk > > > That's good. Then we need to add some description to tell users about > > the auto-generated domain snapshot name, disk snapshot name, > > memory state file and external disk snapshot files, etc. > > We will need user docs and manpage updates, yes. > > > > > #e.g. to specify exernal disk snapshot, like this: > > > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', > > > > '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] > > > > > > > > #e.g. to specify internal disk snapshot, like this: > > > > disks=[',,hda',',,hdb',] > > > > > > Ideally one or the other of these behaviours would be possible without > > > needing to be quite so explicit. > > > > OK, I'll delete one. > > I don't object to having this more capable syntax as an option, so the > user can override things if they wish, all I was suggesting is that the > default ought to be something useful so the user doesn't need to say > anything if they just want the toolstack to "do something sensible". I see. By default user doesn't need to specify 'disks' at all, then xl will do internal disk snapshot to each domain disk. > > Ian. > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote: > '--name' meant to give a meaningful name (like: newinstall. Used as the > memory snapshot name and disk snapshot name). Where is this name stored and when and where would it be presented to the user? > That's good. Then we need to add some description to tell users about > the auto-generated domain snapshot name, disk snapshot name, > memory state file and external disk snapshot files, etc. We will need user docs and manpage updates, yes. > > > #e.g. to specify exernal disk snapshot, like this: > > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', > > > '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] > > > > > > #e.g. to specify internal disk snapshot, like this: > > > disks=[',,hda',',,hdb',] > > > > Ideally one or the other of these behaviours would be possible without > > needing to be quite so explicit. > > OK, I'll delete one. I don't object to having this more capable syntax as an option, so the user can override things if they wish, all I was suggesting is that the default ought to be something useful so the user doesn't need to say anything if they just want the toolstack to "do something sensible". Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
>>> On 12/18/2014 at 11:15 PM, in message >>> <1418915759.11882.91.ca...@citrix.com>, Ian Campbell wrote: > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: > > Changes to V8: > > * xl won't manage snapshots, that means it won't maintain json files, > > won't maintain snapshot chain relationship, and then as a result > > won't take care of deleting snapshot and listing snapshots. > > * remove snapshot-delete and snapshot-list interface > > * update snapshot-revert interface > > * update snapshot-create/revert implementaion > > > > === > > > > XL Design > > > > 1. User Interface > > > > xl snapshot-create: > > Create a snapshot (disk and RAM) of a domain. > > > > SYNOPSIS: > > snapshot-create [] [--name ] [--live] > > > > OPTIONS: > > --name snapshot name > > --live take a live snapshot > > > > If option includes --live, then the domain is not paused while creating > > the snapshot, like live migration. This increases size of the memory > > dump file, but reducess downtime of the guest. > > > > If option doens't include --name, a default name will be generated > > according to the creation time. > > > > If specify @cfgfile, use cfgfile. (e.g. if --name specifies a name, > > meanwhile there is name specified in cfgfile, name in cfgfile will > > be used.) > > If you do not specify cfgfile then where do things go? Is --name perhaps > also serving as a basename for a path to save things to? If user doesn't specify cfgfile, then by default, it will save memory to a default path and take internal disk snapshot to each disk with a default disk snapshot name. '--name' meant to give a meaningful name (like: newinstall. Used as the memory snapshot name and disk snapshot name). About saving path, we meant to have a default path, but now I think it's better to let user specify a path as you suggests here. > > I wonder if we can simplify this a bit and therefore avoid the need cfg > file in common case. e.g. > > 8<--- > xl snapshot-create [--live] [--internal|--external] > > is a path to a directory, which must not exist. This path will be > created and the memory snapshot stored in it using some well defined > name. > > If the snapshot is --external then the snapshot disks are created in > with some well defined name based on the virtual device and > backend format in use. > > If the snapshot is --internal then the snapshot disks are internal. That's good. Then we need to add some description to tell users about the auto-generated domain snapshot name, disk snapshot name, memory state file and external disk snapshot files, etc. > > The default is > > --live is as you've already got it. > 8<--- > > I'm not sure what name and description actually are here, so I've > omitted them. > > Any of that could be overridden with e.g. more specific disk > configuration stanzas etc via the cfg file, if necessary. > > This is just a suggestion, feel free to disagree. > > NB xl create can accept a series of cfg file lines on the command line > too, and treats them as appended to the cfgfile (if any was given). I > think xl snapshot-create should include this functionality too. > > xl snapshot-revert: > > Revert domain to status of a snapshot. > > > > SYNOPSIS: > > snapshot-revert [--running] [--force] > > > > OPTIONS: > > --runningafter reverting, change state to running > > --force try harder on risky reverts > > > > Normally, the domain will revert to the same state the domain was in > while > > the snapshot was taken (whether running, or paused). > > > > If option includes --running, then overrides the snapshot state to > > guarantee a running domain after the revert. > > > > > > > > 2. cfgfile syntax > > > > #snapshot name. If user doesn't provide a VM snapshot name, xl will > generate > > #a name automatically by the creation time. > > name="" > > What is name used for? (I guessed it might be output path above, but I'm > not sure). As above '--name': It suggests as a meaningful snapshot name. But as you suggest, if we let user to specify a path, then that can take a meaning path name, then everything in it can be auto-generated. > > > #snapshot description. Default is NULL. > > description="" > > What is this used for? Is it embedded into e.g. qcow images or is it > just for the admin's own use (in which cases the existing support for > #comments ought to suffice). Oh, I forgot to delete it. It's originally used for manage snapshots, a text description to the snapshot. > > > #memory location. This field should be filled when memory=1. Default is > NULL. > > The memory option isn't defined anywhere, and I think you've rules > disk-only snap
Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: > Changes to V8: > * xl won't manage snapshots, that means it won't maintain json files, > won't maintain snapshot chain relationship, and then as a result > won't take care of deleting snapshot and listing snapshots. > * remove snapshot-delete and snapshot-list interface > * update snapshot-revert interface > * update snapshot-create/revert implementaion > > === > > XL Design > > 1. User Interface > > xl snapshot-create: > Create a snapshot (disk and RAM) of a domain. > > SYNOPSIS: > snapshot-create [] [--name ] [--live] > > OPTIONS: > --name snapshot name > --live take a live snapshot > > If option includes --live, then the domain is not paused while creating > the snapshot, like live migration. This increases size of the memory > dump file, but reducess downtime of the guest. > > If option doens't include --name, a default name will be generated > according to the creation time. > > If specify @cfgfile, use cfgfile. (e.g. if --name specifies a name, > meanwhile there is name specified in cfgfile, name in cfgfile will > be used.) If you do not specify cfgfile then where do things go? Is --name perhaps also serving as a basename for a path to save things to? I wonder if we can simplify this a bit and therefore avoid the need cfg file in common case. e.g. 8<--- xl snapshot-create [--live] [--internal|--external] is a path to a directory, which must not exist. This path will be created and the memory snapshot stored in it using some well defined name. If the snapshot is --external then the snapshot disks are created in with some well defined name based on the virtual device and backend format in use. If the snapshot is --internal then the snapshot disks are internal. The default is --live is as you've already got it. 8<--- I'm not sure what name and description actually are here, so I've omitted them. Any of that could be overridden with e.g. more specific disk configuration stanzas etc via the cfg file, if necessary. This is just a suggestion, feel free to disagree. NB xl create can accept a series of cfg file lines on the command line too, and treats them as appended to the cfgfile (if any was given). I think xl snapshot-create should include this functionality too. > xl snapshot-revert: > Revert domain to status of a snapshot. > > SYNOPSIS: > snapshot-revert [--running] [--force] > > OPTIONS: > --runningafter reverting, change state to running > --force try harder on risky reverts > > Normally, the domain will revert to the same state the domain was in while > the snapshot was taken (whether running, or paused). > > If option includes --running, then overrides the snapshot state to > guarantee a running domain after the revert. > > > > 2. cfgfile syntax > > #snapshot name. If user doesn't provide a VM snapshot name, xl will generate > #a name automatically by the creation time. > name="" What is name used for? (I guessed it might be output path above, but I'm not sure). > #snapshot description. Default is NULL. > description="" What is this used for? Is it embedded into e.g. qcow images or is it just for the admin's own use (in which cases the existing support for #comments ought to suffice). > #memory location. This field should be filled when memory=1. Default is NULL. The memory option isn't defined anywhere, and I think you've rules disk-only snapshots out of scope for xl, so I think this is just a left over from a previous revision. > #e.g. to specify exernal disk snapshot, like this: > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', > '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] > > #e.g. to specify internal disk snapshot, like this: > disks=[',,hda',',,hdb',] Ideally one or the other of these behaviours would be possible without needing to be quite so explicit. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
On Wed, Dec 17, 2014 at 08:23:41PM -0700, Chun Yan Liu wrote: [...] > > > > > > > > > 2. cfgfile syntax > > > > > > #snapshot name. If user doesn't provide a VM snapshot name, xl will > > generate > > > #a name automatically by the creation time. > > > name="" > > > > > > #snapshot description. Default is NULL. > > > description="" > > > > > > #memory location. This field should be filled when memory=1. Default is > > NULL. > > > memory_path="" > > > > > > #disk snapshot information > > > #For easier parse config work, reuse disk configuration in xl.cfg, but > > > #with different meanings. > > > #disk syntax meaning: 'external path, external format, target device' > > > > > > #e.g. to specify exernal disk snapshot, like this: > > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', > > > '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] > > > > > > #e.g. to specify internal disk snapshot, like this: > > > disks=[',,hda',',,hdb',] > > > > > > > How is snapshot chain represented with this syntax? Does xl not need to > > know about the chain? (Note, this is different than managing the chain) > > If only supply creating snapshot and restoring domain from a snapshot, > xl doesn't need to know the chain. > > For creating snapshot, it's very easy to understand, no matter from base > or from a snapshot, saving memory and taking disk snapshot has no > difference. > > For restoring domain from snapshot, restoring memory has no difference; > applying disk snapshot, to those backend types we can expect: > qcow2 internal snapshot: no need to know chain > vhd, qcow2 external disk snapshot: both external disk snapshot, and > both using backing file chain to implement, so apply disk snapshot > is very simple, just use the external snapshot file. > lvm: doesn't support snapshot of snapshot, so no such problem. > So, overall, it doesn't need to know the chain either. > Thanks for the explanation. Makes sense. Wei. > > > > Wei. > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
>>> On 12/17/2014 at 08:28 PM, in message <20141217122817.gg1...@zion.uk.xensource.com>, Wei Liu wrote: > On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote: > > Changes to V8: > > * xl won't manage snapshots, that means it won't maintain json files, > > won't maintain snapshot chain relationship, and then as a result > > won't take care of deleting snapshot and listing snapshots. > > * remove snapshot-delete and snapshot-list interface > > * update snapshot-revert interface > > * update snapshot-create/revert implementaion > > > > === > > > > XL Design > > > > 1. User Interface > > > > xl snapshot-create: > > Create a snapshot (disk and RAM) of a domain. > > > > SYNOPSIS: > > snapshot-create [] [--name ] [--live] > > > > OPTIONS: > > --name snapshot name > > --live take a live snapshot > > > > If option includes --live, then the domain is not paused while creating > > the snapshot, like live migration. This increases size of the memory > > dump file, but reducess downtime of the guest. > > > > If option doens't include --name, a default name will be generated > > according to the creation time. > > > > If specify @cfgfile, use cfgfile. (e.g. if --name specifies a name, > > meanwhile there is name specified in cfgfile, name in cfgfile will > > be used.) > > > > > > xl snapshot-revert: > > Revert domain to status of a snapshot. > > > > SYNOPSIS: > > snapshot-revert [--running] [--force] > > > > OPTIONS: > > --runningafter reverting, change state to running > > --force try harder on risky reverts > > > > Normally, the domain will revert to the same state the domain was in > while > > the snapshot was taken (whether running, or paused). > > > > If option includes --running, then overrides the snapshot state to > > guarantee a running domain after the revert. > > > > > > > > 2. cfgfile syntax > > > > #snapshot name. If user doesn't provide a VM snapshot name, xl will > generate > > #a name automatically by the creation time. > > name="" > > > > #snapshot description. Default is NULL. > > description="" > > > > #memory location. This field should be filled when memory=1. Default is > NULL. > > memory_path="" > > > > #disk snapshot information > > #For easier parse config work, reuse disk configuration in xl.cfg, but > > #with different meanings. > > #disk syntax meaning: 'external path, external format, target device' > > > > #e.g. to specify exernal disk snapshot, like this: > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', > > '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] > > > > #e.g. to specify internal disk snapshot, like this: > > disks=[',,hda',',,hdb',] > > > > How is snapshot chain represented with this syntax? Does xl not need to > know about the chain? (Note, this is different than managing the chain) If only supply creating snapshot and restoring domain from a snapshot, xl doesn't need to know the chain. For creating snapshot, it's very easy to understand, no matter from base or from a snapshot, saving memory and taking disk snapshot has no difference. For restoring domain from snapshot, restoring memory has no difference; applying disk snapshot, to those backend types we can expect: qcow2 internal snapshot: no need to know chain vhd, qcow2 external disk snapshot: both external disk snapshot, and both using backing file chain to implement, so apply disk snapshot is very simple, just use the external snapshot file. lvm: doesn't support snapshot of snapshot, so no such problem. So, overall, it doesn't need to know the chain either. > > Wei. > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote: > Changes to V8: > * xl won't manage snapshots, that means it won't maintain json files, > won't maintain snapshot chain relationship, and then as a result > won't take care of deleting snapshot and listing snapshots. > * remove snapshot-delete and snapshot-list interface > * update snapshot-revert interface > * update snapshot-create/revert implementaion > > === > > XL Design > > 1. User Interface > > xl snapshot-create: > Create a snapshot (disk and RAM) of a domain. > > SYNOPSIS: > snapshot-create [] [--name ] [--live] > > OPTIONS: > --name snapshot name > --live take a live snapshot > > If option includes --live, then the domain is not paused while creating > the snapshot, like live migration. This increases size of the memory > dump file, but reducess downtime of the guest. > > If option doens't include --name, a default name will be generated > according to the creation time. > > If specify @cfgfile, use cfgfile. (e.g. if --name specifies a name, > meanwhile there is name specified in cfgfile, name in cfgfile will > be used.) > > > xl snapshot-revert: > Revert domain to status of a snapshot. > > SYNOPSIS: > snapshot-revert [--running] [--force] > > OPTIONS: > --runningafter reverting, change state to running > --force try harder on risky reverts > > Normally, the domain will revert to the same state the domain was in while > the snapshot was taken (whether running, or paused). > > If option includes --running, then overrides the snapshot state to > guarantee a running domain after the revert. > > > > 2. cfgfile syntax > > #snapshot name. If user doesn't provide a VM snapshot name, xl will generate > #a name automatically by the creation time. > name="" > > #snapshot description. Default is NULL. > description="" > > #memory location. This field should be filled when memory=1. Default is NULL. > memory_path="" > > #disk snapshot information > #For easier parse config work, reuse disk configuration in xl.cfg, but > #with different meanings. > #disk syntax meaning: 'external path, external format, target device' > > #e.g. to specify exernal disk snapshot, like this: > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', > '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] > > #e.g. to specify internal disk snapshot, like this: > disks=[',,hda',',,hdb',] > How is snapshot chain represented with this syntax? Does xl not need to know about the chain? (Note, this is different than managing the chain) Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RFC V9 3/4] domain snapshot design: xl
Changes to V8: * xl won't manage snapshots, that means it won't maintain json files, won't maintain snapshot chain relationship, and then as a result won't take care of deleting snapshot and listing snapshots. * remove snapshot-delete and snapshot-list interface * update snapshot-revert interface * update snapshot-create/revert implementaion === XL Design 1. User Interface xl snapshot-create: Create a snapshot (disk and RAM) of a domain. SYNOPSIS: snapshot-create [] [--name ] [--live] OPTIONS: --name snapshot name --live take a live snapshot If option includes --live, then the domain is not paused while creating the snapshot, like live migration. This increases size of the memory dump file, but reducess downtime of the guest. If option doens't include --name, a default name will be generated according to the creation time. If specify @cfgfile, use cfgfile. (e.g. if --name specifies a name, meanwhile there is name specified in cfgfile, name in cfgfile will be used.) xl snapshot-revert: Revert domain to status of a snapshot. SYNOPSIS: snapshot-revert [--running] [--force] OPTIONS: --runningafter reverting, change state to running --force try harder on risky reverts Normally, the domain will revert to the same state the domain was in while the snapshot was taken (whether running, or paused). If option includes --running, then overrides the snapshot state to guarantee a running domain after the revert. 2. cfgfile syntax #snapshot name. If user doesn't provide a VM snapshot name, xl will generate #a name automatically by the creation time. name="" #snapshot description. Default is NULL. description="" #memory location. This field should be filled when memory=1. Default is NULL. memory_path="" #disk snapshot information #For easier parse config work, reuse disk configuration in xl.cfg, but #with different meanings. #disk syntax meaning: 'external path, external format, target device' #e.g. to specify exernal disk snapshot, like this: #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] #e.g. to specify internal disk snapshot, like this: disks=[',,hda',',,hdb',] 3. xl snapshot-xxx implementation "xl snapshot-create" 1), parse args or user configuration file. 2), save domain (store saved memory to memory_path) 3), create disk snapshots according to disk snapshot configuration 4), unpause domain "xl snapshot-revert" 1), parse user configuration file 2), destroy current domain 3), revert disk snapshots according to disk snapshot configuration 4), restore domain from saved memory. 4. Notes * user should take care of those snapshots, like: saved memory file, disk snapshots info (internal, external, etc.), snapshot chain relationship * user should delete snapshots by themselves with CLI commands like: rm, qemu-img, etc. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
