On Tue, Jan 26, 2016 at 12:59:00 +0300, Alexander Burluka wrote: > On 01/25/2016 04:16 PM, Daniel P. Berrange wrote: > > On Mon, Jan 25, 2016 at 02:55:30PM +0300, Alexander Burluka wrote: > >> For example, we want to store suspended state of VM. > >> I'm aware that some other careless application dealing with libvirt > >> may erase metadata section and info about additional snapshot data will be > >> lost. > > What do you mean by suspended state of the VM ? Are you referring to > > the VM memory & device state ? If so, I think that something that > > should be explicitly represented in the API, not a opaque blob. > We distinguish paused and suspended to disk domain states. For suspend > to disk we are using virDomainSaveFlags API call and stop domain. So you are saving the domain to a file which is out of libvirt's control and your management app (I guess) tracks the file for each domain. > This API call stores VM memory and device states to some file. If user > then calls virDomainSnapshotCreateXML, the resulted snapshot lacks > VM memory and device states because it looks like domain is stopped and > it is not aware about state file. Thus, switch to this snapshot does not > work as expected. It is the responsibility of your management app to associate the state files with snapshots and to properly restore them when switching between snapshots. I don't think libvirt should behave as a general purpose database for management apps. The situation would be quite different if you used virDomainManagedSave to save its state. In this case, it's libvirt's responsibility to be aware of a saved state when creating/reverting snapshots. And currently libvirt doesn't handle this correctly. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list