|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V7 3/3] xl snapshot-xxx Design
>>> On 10/22/2014 at 12:10 PM, in message <54472E36.F08 : 102 : 21807>, Chun Yan Liu wrote: > >>>> On 10/21/2014 at 12:39 AM, in message >>>> <1413823182.29506.16.camel@xxxxxxxxxx>, > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > > On Fri, 2014-10-10 at 16:48 +0800, Chunyan Liu wrote: >> > 1. xl commandline interface design >> > >> > xl snapshot-create: >> > Create a snapshot (disk and RAM) of a domain. >> > >> > SYNOPSIS: >> > snapshot-create <domain> [<cfgfile>] [--disk-only] [--reuse-external] >> > [--live] >> > >> > OPTIONS: >> > [--domain] <string> domain name, id or uuid >> > [--cfgfile] <string> domain snapshot configuration >> >> Is this separate to or the same as the <cfgfile> argument? Is this a >> xl.cfg(5) config file or something specific to snapshot cfg? >> >> > --disk-only capture disk state but not vm state >> > --reuse-external reuse any existing external files >> > --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. Only support this flag >> > during external checkpoints. >> > >> > If option includes --disk-only, then the snapshot will be limited to >> > the disks, and no VM state will be saved. For an active guest, this is >> > >> > not supported. >> > >> > If specify @cfgfile, cfgfile is prioritized. >> >> What does "prioritized" mean in this context? >> >> > xl snapshot-delete: >> > Delete a snapshot of a domain. >> >> So what's not clear yet (but I see it is discussed below) is the manner >> in which xl is going to manage snapshots. >> >> Typically in the past users have been expected to manage disk and save >> images with rm(1) and/or various format specific tools (qemu-img, >> vhd-image, lvcreate etc). >> >> I think you are proposing that there should be some path full of >> snapshots, is that right? That is adding a lot of complexity to xl which >> could potentially be avoided by sticking to the "user takes care of it" >> path. >> >> > 3. xl structure to maintain VM snapshot info >> >> These are repeating the libxl ones? The look subtly different. If they >> are xl specific then they should be in the xl_foo namespace, and of >> course the should incorporate public libxl API structs where necessary. >> >> Having the structs be named libxl_* makes it hard for me to see if you >> have gotten the layering right in much of the below. I'll try and point >> out the ones I think should be xl_* below, if you really meant libxl_* >> then that probably means I disagree with the layering. >> >> > According to libxl_domain_snapshot_info, a json file will be saved on >> > disk. >> >> You mean that libxl_domain_snapshot_info (really >> xl_domain_snapshot_info) can be serialised to disk as json, right? >> >> > >> > 4. xl snapshot-xxx implementation details >> >> How do these interact with xl create/destroy/shutdown/save/restore? >> >> e.g. does destroying a domain remove any snapshots? >> Typically in the past users have been expected to manage disk and save >> images with rm(1) and/or various format specific tools (qemu-img, >> vhd-image, lvcreate etc). >> >> I think you are proposing that there should be some path full of >> snapshots, is that right? That is adding a lot of complexity to xl which >> could potentially be avoided by sticking to the "user takes care of it" >> path. >> >> > 3. xl structure to maintain VM snapshot info >> >> These are repeating the libxl ones? The look subtly different. If they >> are xl specific then they should be in the xl_foo namespace, and of >> course the should incorporate public libxl API structs where necessary. >> >> Having the structs be named libxl_* makes it hard for me to see if you >> have gotten the layering right in much of the below. I'll try and point >> out the ones I think should be xl_* below, if you really meant libxl_* >> then that probably means I disagree with the layering. >> >> > According to libxl_domain_snapshot_info, a json file will be saved on >> > disk. >> >> You mean that libxl_domain_snapshot_info (really >> xl_domain_snapshot_info) can be serialised to disk as json, right? >> >> > >> > 4. xl snapshot-xxx implementation details >> >> How do these interact with xl create/destroy/shutdown/save/restore? >> >> e.g. does destroying a domain remove any snapshots? > > Since in xl domain is deleted when destroyed/shutdown/save, no state > like previously in xend, created but not started, deleted only when issue > 'delete' command. > > I don't think clearly now about: > how to handle snapshots when destroy/shutdown/save/migrate a domain. > In theory, if a domain is deleted, the snapshots should all be deleted. > But this way, I don't know how much value this operation can bring to users. > Those snapshot are still usable. One can start a new domain from a snapshot. > There is memory state (can restore memory, restore config) and disk > snapshot (can restore disk status). > > Do you have any suggestions? As described above, is there any suggestions? > >> >> A bunch of these are gong to require some care wrt the possibility of >> multiple xl invocations and the possibility of an xl crash. >> >> >> A bunch of these are gong to require some care wrt the possibility of >> multiple xl invocations and the possibility of an xl crash. >> >> > "xl snapshot-create" >> > >> > 1), parse args or domain snapshot configuration file. >> > 2), fill info in libxl_domain_snapshot_args struct according to >> > options or config file. >> > 3), call libxl_domain_snapshot_create() >> > 4), fill info in libxl_domain_snapshot_info. >> >> xl_domain_snapshot_info? >> >> > 5), save snapshot info in json file under >> > "/var/lib/xen/snapshots/domain_uuid" >> >> Do the disk images go here too? >> >> > "xl snapshot-list" >> > >> > 2), display information from those libxl_domain_snapshot_info(s) >> > >> > "xl snapshot-delete" >> > >> > 1), read snapshot json file from >> > "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\ >> > .libxl-json", parse the file and fill in >> > libxl_domain_snapshot_info >> >> .xl-json and xl_domain_snapshot_info, I think? >> >> > 2), according to parent/children info in libxl_domain_snapshot_info >> >> xl_domain_snapshot_info. >> >> > and commandline options, decide which domain snapshot to be >> deleted. >> > To delete each domain snapshot, fill in >> > libxl_domain_snapshot_args and call >> > libxl_domain_snapshot_delete(). >> >> Depending on the state of the domain, much of this can be done with >> unlink and/or calling out to external tools. >> >> > 3), refresh parent/children relationship, delete json file for those >> > already deleted snapshot. >> > >> > "xl snapshot-revert" >> > >> > 1), read snapshot json file from >> > "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\ >> > .libxl-json", parse the file and fill in >> libxl_domain_snapshot_info. >> >> .xl-json and xl_domain_snapshot_info >> >> > 2), fill in libxl_domain_snapshot_args >> > 3). call libxl_domain_snapshot_revert(). >> >> >> >> >> > 1), read all domain snapshot related json file under >> > "/var/lib/xen/snapshots/domain_uuid". Parse each file and fill in >> > libxl_domain_snapshot_info struct. >> >> xl_domain_snapshot_info? >> > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |