Re: [libvirt-users] Snapshot system: really confusing.

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. 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. 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. 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. The point is that this XML doesn't track those involved files so I have no clue where to get them. And I still just need to analyze the memory state, no other uses. 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. 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.