Re: Snapshot system: really confusing.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 04/23/2012 01:20 AM, NoxDaFox wrote: > Greetings, Hello, > > I am developing a platform for test and debug use. > > The typical scenario I want to realize is the following: > > I run a .qcow2 image via QEMU-KVM, the running OS is not relevant. > I want to take several snapshots of both Disk and RAM status; same file, > separate files doesn't matter. > I just need a way to have consistent information about them (better with > XML description) and the data as well. > I want to store these snapshots on my storage devices to use them whenever > and wherever I want. Hopefully libvirt can supply what you are interested in; and be aware that it is a work in progress (that is, unreleased qemu 1.1 and libvirt 0.9.12 will be adding yet more features to the picture, in the form of live block copy). > > Is it possible to store a single snapshot providing both the memory and > disks state in a file (maybe a .qcow2 file)? Single file: no. Single snapshot: yes. The virDomainSnapshotCreateXML API (exposed by virsh snapshot-create[-as]) is able to create a single XML representation that libvirt uses to track the multiple files that make up a snapshot including both memory and disk state. > Is there any way to get a unique interface which handles my snapshots? > > I was used to use the virDomainSnapshotCreateXML() defining the destination > file in the XML with <disk> fields. Right now, you have a choice: 1. Don't use the DISK_ONLY flag. That means that you can't use <disk> in the snapshot XML. The snapshot then requires qcow2 files, the VM state is saved (it happens to be in the first qcow2 disk), and the disk state is saved via qcow2 internal snapshots. 2. Use the DISK_ONLY flag. Then you can set up external snapshot file names (basically, another layer of qcow2 files, where your original file name is now the snapshot backing the new layer), and you get no VM state directly. Here is where the <disk> element of the snapshot comes into play. If you _also_ want to save VM state, you can use 'virsh save' (virDomainSaveFlags) to save just VM state; but then you have to coordinate things so that the disk snapshot and the VM state correspond to the same point in guest time by pausing the guest before taking the disk snapshot. > After updating libvirt it was not working anymore, I thought was a bug but > then I realized it was intentional. > The function complains about the fact that the <disk> parameter is not > accepted anymore. What versions of libvirt are you playing with? <disk> was unrecognized (and ignored) prior to 0.9.5; after that point, it can only be used with the DISK_ONLY flag, but then you have to take the VM state separately. Someday, I'd like to submit more patches to allow <disk> to be mixed with live VM state, but I'm not there yet. > So I started guessing how to solve reading the API documentation and I fall > in a completely nebulous world. > > For what I got: > - virDomainSnapshotCreateXML(): > According to flags can take system checkpoints (really useful) and disks > snapshots. > System checkpoints: What I need but I didn't find any way to retrieve the > storage file; I'm only able to get the snapshot pointer, quite useless as > from its pointer I can only print the XML description. The storage is in internal snapshots of your qcow2 file. Try 'qemu-img info /path/to/file' to see those internal snapshots. You can also use qemu-img convert -s snapname /path/to/image /path/to/output as a way to extract that snapshot into a file that you can use independently (but only while your guest is not running); alas, qemu doesn't yet provide a way to extract this information from a running domain, nor have I yet had time to map this functionality into libvirt API. But I have requested qemu enhancements to allow it (perhaps by qemu 1.2), as well as have a vision of where I plan to take the libvirt API in the next year or so to make this more useful. > Disk snapshot: here through the XML description I can specify a target file > where to write the information. But I still need the memory status. > - virDomainSaveFlags(): > No matter how I set the flags, it halts the guest; I need it still running > afterward and I think that reverting the domain and restarting for my > scenarios is unaffordable. Yeah, that's another thing on my list, to add a flag to virDomainSaveFlags that will keep the domain running after the save is complete, and/or enhance virDomainSnapshotCreateXML to incorporate a domain save to an external file alongside disk snapshots at the same point in guest time. I'd also like to play with background migration (right now, virDomainSaveFlags does a foreground migrate-to-file, which pauses the guest up front; but a minimal downtime solution would use the live migration path which results in a larger output file but much less downtime). > - virDomainCoreDump(): > Does what I need for the memory, but doesn't give any XML description and > doesn't supply any useful interface to handle it, I just get back an int > that represent the exit status of the routine. virDomainCoreDump() and virDomainSaveFlags() both do a migration to file, it's just that the core dump version isn't designed for reverting like domain save. And there have been proposals on list for making core dump management better (such as allowing you to get at a core dump file from a remote machine; right now, the core dump can only be stored on the same machine as the guest being dumped). > (other functions really similar) > > The question is: why all this confusion? Different qemu capabilities ('savevm', 'migrate', 'blockdev-snapshot-sync'), different needs at the time each feature was first added, etc. Ultimately, virDomainSnapshotCreateXML is the most powerful interface, and I have plans to make it be a superset of virDomainSaveFlags(), but I'm not there yet. > I absolutely understand the problematic that realizing a multiplatform > snapshots management raises; but I think that for an API purpose what is > implemented here is completely confusing the developer. Is there anything I can do to help improve the documentation? I know that's an area where a picture can speak a thousand words; and as more features get added into the snapshot picture, it probably becomes more important to accurately display the various APIs and the advantages for using each. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
[Virt Tools] [Lib OS Info] [Fedora Users] [Fedora Maintainers] [Fedora Desktop] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools]