On Sun, Aug 24, 2008 at 11:17:50PM -0500, Charles Duffy wrote: > I'm looking for the ability to restore a snapshot saved with > domain.save(), with disk images pointing at a different location (in my > particular use case, pointing at a an empty copy-and-write image > backending into a snapshot of the old disk state). Further, as I may run > multiple copies of the same host at once (from the same initial state, > against different copy-on-write disk images backending into the same > read-only store, into different disconnected networks), the UUID as well > as the name may need to be changed. > > I could just rewrite the header of the saved-state file, but this has a > few disadvantages: > - To mimic the copy-on-write behavior of the disk images, I would need > to copy the entire saved-domain file. I'm trying to minimize the time > and disk penalty of snapshot/restore, so this is suboptimal. That will need to be done anyway for Xen save images. > - My code is dependent on the file format used by the particular > backend, and may break when that backend is revved. Yep, that's clearly a problem - you shouldn't rely on the save image format at all - that's hypervisor version dependant and has no guarentees whatsoever about it remaining the same. > Would a patch adding API calls to > - return the XML description of a saved host, given the name > - restore a saved host with a different description > be considered welcome? I'm guessing you mean 'guest' instead of 'host' throughout here. My overall concern with this idea, is that its basically introducing a psuedo-snapshot capability onto the restore API, and is really a nasty hack which I don't believe we can implement on all hypervisors. Hypervisors may well have formal snapshot APIs we can call into, but the hack of extracting XML & restoring a saved image using new XML may prove impossible to map onto the hypervisors snapshot API. Thus I'm inclined to say we don't want this capability. Instead I'd like us to have a real snapshot API, which we can directly map onto the underlying hypervisor's snapshot capability, or do an internal hack impl based on save images as you suggest - but not expose this detail in the API. > I presume that to maintain backwards compatibility, the latter would be > expected to be exposed to clients via a new call, rather than adding a > parameter to virDomainRestore(); in communicating with the drivers, on > the other hand, my first instinct would be to add an extra parameter to > virDrvDomainRestore. Yes, anything in libvirt/libvirt.h is append-only. No changes are allowed to this file because we have to maintain ABI. For anything in the src/ directory, changes are allowed within reason - we merely have to be careful with things that map onto the remote protocol which is another ABI. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list