[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
>>> On 12/18/2014 at 11:10 PM, in message >>> <1418915443.11882.86.camel@xxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: > > Changes to V8: > > * add an overview document, so that one can has a overall look > > about the whole domain snapshot work, limits, requirements, > > how to do, etc. > > > > ===================================================================== > > Domain snapshot overview > > I don't see a similar section for disk snapshots, are you not > considering those here except as a part of a domain snapshot or is this > an oversight? > > There are three main use cases (that I know of at least) for > snapshotting like behaviour. > > One is as you've mentioned below for "backup", i.e. to preserve the VM > at a certain point in time in order to be able to roll back to it. Is > this the only usecase you are considering? Yes. I didn't take disk snapshot thing into the scope. > > A second use case is to support "gold image" type deployments, i.e. > where you create one baseline single disk image and then clone it > multiple times to deploy lots of guests. I think this is usually a "disk > snapshot" type thing, but maybe it can be implemented as restoring a > gold domain snapshot multiple times (e.g. for start of day performance > reasons). As we initially discussed about the thing, disk snapshot thing can be done be existing tools directly like qemu-img, vhd-util. > > The third case, (which is similar to the first), is taking a disk > snapshot in order to be able to run you usual backup software on the > snapshot (which is now unchanging, which is handy) and then deleting the > disk snapshot (this differs from the first case in which disk is active > after the snapshot, and due to the lack of the memory part). Sorry, I'm still not quite clear about what this user case wants to do. > > Are you considering all three use cases here or are you explicitly > ruling out anything but the first? I think there might be some subtle > differences in the requirements, wrt which operations need to consider > the possibility of an active domain etc, depending on which cases are > considered. It would be good to be explicit about the use cases you are > not trying to address here so we are all on the same page. > > If you are ruling these other usecases out then I think it would be > useful to briefly describe them and then note that they are out of scope > for this design, so that we have an agreed understanding of what is in > or out of scope and/or can debate to what extent such use cases ought to > be considered in the design if not the implementation. OK. I'll add this. > > > 1. Purpose > > > > Domain snapshot is a system checkpoint of a domain. Later, one can > > roll back the domain to that checkpoint. It's a very useful backup > > function. A domain snapshot contains the memory status at the > > checkpoint and the disk status (which we called disk snapshot). > > > > Domain snapshot functionality usually includes: > > a) create a domain snapshot > > b) roll back (or called "revert") to a domain snapshot > > c) delete a domain snapshot > > d) list all domain snapshots > > > > But following the existing xl idioms of managing storage and saved > > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, > > cp etc), xl snapshot functionality would be kept as simple as > > possible: > > * xl will do a) and b), creating a snapshot and reverting a > > domain to a snapshot. > > * xl will NOT do c) and d), xl won't manage snapshots, as xl > > doesn't maintain saved images created by 'xl save'. So xl > > will have no idea of the existence of domain snapshots and > > the chain relationship between snapshots. It will depends on > > user to take care of the snapshots, know the snapshot chain > > info, and delete snapshots. > > This is a case where the usecases being considered might apply. If the > third case I outlined above is in scope then xl may need to somehow > support deleting a snapshot from under the feet of an active domain etc > (which need not necessarily imply knowledge of snapshot chains or > snapshot management, but might involve a notification to the backend for > example). > > > Domain Snapshot Support and Not Support: > > * support live snapshot > > * support internal disk snapshot and external disk snapshot > > * support different disk backend types. > > (Basic goal is to support 'raw' and 'qcow2' only). > > > > * not support snapshot when domain is shutdowning or dying. > > * not support disk-only snapshot [1]. > > > > [1] To xl, it only concerns active domains, and even when domain > > is paused, there is no data flush to disk operation. So, take > > a disk-only snapshot and then resume, it is as if the guest > > had crashed. For this reason, disk-only snapshot is meaningless > > to xl. Should not support. > > > > > > 2. Requirements > > > > General Requirements: > > * ability to save/restore domain memory > > * ability to create/delete/apply disk snapshot [2] > > Is "apply" the same as "revert to"? Worth adding to the terminology > section and using consistently. Yes. In qemu-img terms, it's 'apply'. In libvirt qemu driver domain snapshot terms, it's 'revert'. I'll add to the terminology section. > > > * ability to parse user config file > > > > [2] Disk snapshot requirements: > > - external tools: qemu-img, lvcreate, vhd-util, etc. > > - for basic goal, we support 'raw' and 'qcow2' backend types > > only. Then it requires: > > libxl qmp command or "qemu-img" (when qemu process does not > > exist) > > > > > > 3. Interaction with other operations: > > > > No. > > What about shutdown/dying as you noted above? What about migration or > regular save/restore? Since xl now has no idea of the existence of snapshot, so when writing this document I turned to depends on users to delete snapshots before or after deleting a domain (like shutdown, destroy, save, migrate away). User should know where memory is saved, and disk snapshot related info. Chunyan > > > > > 4. General workflow > > > > Create a snapshot: > > * parse user cfg file if passed in > > * check snapshot operation is allowed or not > > * save domain, saving memory status to file (refer to: save_domain) > > * take disk snapshot (e.g. call qmp command) > > * unpause domain > > > > Revert to snapshot: > > * parse use cfg file (xl doesn't manage snapshots, so it has no > > idea of snapshot existence. User MUST supply configuration file) > > * destroy this domain > > * create a new domain from snapshot info > > - apply disk snapshot (e.g. call qemu-img) > > - a process like restore domain > > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |