Re: Snapshot system: really confusing.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 27/04/12 17:56, Eric Blake wrote:
That's it! Really simple. From a known state I want to run a scenario (whatever piece of code) and track down the differences on disk and memory state. I need a way to track down those states and to access in a comfortable way to the deltas.On 04/25/2012 03:25 AM, NoxDaFox wrote:Hello, thank you for your fast reply! To help in comprehension I'll explain you a bit what am I trying to realize so the picture will be more clear. Basically it's a platform for debug, what I need is to access to the memory dump image and to the FS ones; I don't need any reverting support. The common lifecycle of a domain is: a) Given a backing store disk (qcow2) I create a new disk image: my_image.qcow2 b) I start this image and play around based on a persistent domain. c) I take several pictures (snapshots, dumps) of the VE state: I need at least readable pictures of the FileSystem and the RAM. d) I shutdown the guest. e) I extract valuable information from the pictures. This is the critical phase where all my doubts on libvirt platform come from. f) I store those information. g) I wipe out everything else. h) Ready for a new test, return to point a).Thanks; that helps in knowing what you are trying to accomplish - it sounds like you are intentionally forking machine state from a known point in time (the offline backing store disk), and then want to compare the running state of those forks by snooping both the RAM and disk state at the time of the snapshot series you took along each branch of the fork.
I think that a valuable feature that virtualization technology could bring, is the capability to study code behavior for debug or reverse engineering purpose. The problem is that there aren't yet interfaces capable of doing so. All the available solutions just provide snapshots to revert system to a certain state; not to use snapshots for analysis purpose.
This could be something that can differentiate libvirt from other products. To be more clear imagine this situation:I have a software (MySoft) and, as it works on Windows registers, I need to control that it won't break the OS. MySoft once run does windows registry cleanup, write a logs and stops. The scenario I want to represent is the installation of MySoft and one execution of itself. The information I need are: which files are created/modified once MySoft is installed, the memory movements once MySoft is running, which files are modified/removed once MySoft has run and the final log file.
Here's the test's lifecycle: - I set up a disk: Windows Vista Home Edition SP1 fully updated. - I put MySoft installer in the disk's FS. - I start the guest. - Once windows is up and running I take a disk state snapshot (DISK#1).- I run the installer; once MySoft is installed I take a second disk snapshots (DISK#2).
- Windows is idle, I take a memory state snapshot (MEM#1). - I start MySoft, I take 3 other memory snapshots (MEM#2, MEM#3, MEM#4).- MySoft closed gracefully, I take both memory and disk snapshots (DISK#3, MEM#5).
- I shut down the guest. - I release the resources. At this point I have several pictures of MySoft behavior:I can see which files are created/modified after installation mounting DISK#2 snapshot and comparing it with DISK#1. I can see which files are modified/removed after MySoft execution comparing DISK#3 and DISK#2. I can check if all the memory resources are given back to the OS comparing MEM#5 and MEM#1.
I can look at the memory evolution through MEM#2, MEM#3, MEM#4. I can extract the log file from DISK#3. I hope this example may be useful to understand what I want to realize.I think that using virtualization in such a way may be a really useful for developers!
The easiest way to track down state differences at the moment is, given a snapshot and the image from which has been generated, create a disk image, mount it and compare it with the original backing one. Consistency problems may be solved flushing all the buffers on the disk and pausing the guest before snapshotting.libvirt is a great platform! And documentation is not bad at all. The only nebulous part is the snapshot part (I guessed was on hard development anyway).Always nice to hear from happy customers, and yes, we are trying to improve things. And as always with open source projects, patches are welcome, even for things as mundane as documentation.Now I'll answer to your points.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).I knew the situation, I saw a RFC of yours that is really interesting as it introduces snapshots of single storage volumes: virStorageVolSnapshotPtr. Really interesting under my point of view.Yep, but unfortunately still several months down the road. I basically envision a way to map between virDomainPtr and virStorageVolPtr (given a domain, return a list of the storage volumes it is using; and given a storage volume, return a list of any domains referring to that volume). Once that mapping is in place, then we can expose more power to the various virStorageVol APIs, such as inspecting backing chains or internal snapshots.
What I miss now is a libvirt interface that allows me to pass from a snapshot to a volume. Would be fantastic to map in such a way that, from a disk snapshot pointer, through the volumes pool I generate a new volume that I can track with the pool itself. This will allow a system to be really easy to maintain: I have a snapshot list, I choose the desired ones, I generate new volumes, I compare those volumes using libguestfs (or whatever else tool), I collect the desired information, I clean up the pool and I destroy the snapshots list.
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.This would be enough, as long as I'm able to read those information.The 'system checkpoint' created by virDomainSnapshotCreateXML saves VM state and disk state, but saves the VM state into an internal section of a qcow2 file; it is done by the 'savevm' monitor command of qemu. I'm not sure if that is directly accessible (that is, I have no idea if qemu-img exposes any way to read the VM state, which may mean that the only way to read that state is to load the VM back into a fresh qemu instance).
This is really bad as I need to inspect this memory.As I said: taking disk and memory states separately or together is not relevant at the moment; I just need a way to elegantly implement it. Something easy to use programmatically (I won't be the final user of the platform).
So I guess the virDomainSave doesn't use the qemu savevm command. But anyway this function is useless under my point of view because it stops the guest.On the other hand, the VM-only save done by 'virsh save' uses the migration to file, which is the same format used by 'virsh dump', and that external file can be loaded up in crash analysis tools in order to inspect RAM state at the time of the save, without having to worry about extracting the VM state from an internal segment of a qcow2 disk file.
The point is that this XML doesn't track those involved files so I have no clue where to get them.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.That's good to know, I just got yesterday, reading your mails in the dev mailing list, where snapshots were stored; I always tried to look for a new file, unsuccessfully.There's multiple files involved in a snapshot: libvirt maintains an XML file (this currently happens to live in /etc/libvirt/, but you shouldn't directly be probing for this file, so much as using the libvirt API to get at the XML); the disk state is done with an internal snapshot of each of the qcow2 disks, and the VM state is done with an internal section of the first qcow2 disk. 'qemu-img info $first_disk' will show you the size of the internal state, although like I said, I don't know how to probe for the contents of that state short of starting a new qemu instance.
And I still just need to analyze the memory state, no other uses.
... <cut> ...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).I think this is bad, why not merging these functions? Under an API point of view (I'm aware of architectural difficulties on the background) this is useless and confusing. Better a virDomainSaveFlags() with several configuration than two different functions.There is a proposal on list to make virDomainCoreDump() dump _just_ memory, in ELF format; whereas virDomainSaveFlags() will always dump all VM state (RAM but also device state) needed to restart a VM from the same state. Just because the current implementation of the two functions uses migrate-to-file as the underlying glue does not mean that this will always be the case, as the two functions really are for different purposes (saving a VM in order to resume it, vs. dumping just the memory state of a VM for analysis).
With devices you mean disks or other devices (network cards, usb sticks)?For the moment my first priority are the disk (my guests run on a single virtual disk, I don't need to represent multiple disks or partitions in my scenario) and the memory state. Then we can also think about buffers, devices and so on; but this is more complex and less important.
The important think is having something clear to use for analysis, with function A I get a disk readable state, with B I get a memory one. For what I understood now the virDomainCoreDump() is what I need, as it gives an ELF image whit the memory state, right?
Fully understandable, you cannot brutally remove a deprecated function, but in the documentation underlining it as "deprecate, use XXX instead" would be more clear.This is a complex system-management API, so anyone who'll use it will be conscious of that; I don't think that many flags and XML files will be confusing as long as they're clearly documented. But having multiple interfaces (alias functions/methods) that basically do the same in a different way with slightly different results is really confusing.Unfortunately true, but we're stuck with historical naming - libvirt will not ever remove a function that has been previously exported in the API. It is made worse by the fact that some of the older functions are not easily extensible (such as lacking a flags argument), so we have to add new API to fill in the gaps. But when I do add new API, I do try to cross-reference the similar functions; any documentation that points in both directions between the older and simpler name and the newer and more powerful name is worthwhile.
Basically my idea is to use libvirt as an analysis tool but for the moment the project is focusing only on the migration and reverting point of view. This is fully understandable as all the virtualization tools are basing their business on those features, but I think that introducing also analysis support may be really valuable for this product (my 2 cents of course).
NoxDaFox. _______________________________________________ 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]