[libvirt] Proposed functionality: API to extract host description from saved state, restore with modified XML
Per subject. Obviously only for use by folks who *really* know what they're doing. :) 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. - My code is dependent on the file format used by the particular backend, and may break when that backend is revved. 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 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. Thanks!
On Sun, Aug 24, 2008 at 11:17:50PM -0500, Charles Duffy wrote:
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?
As I understand it, yes & yes.
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, you cannot change the public API in a non-compatible way. So adding a new API call is the only option as I understand it. You can change internal interfaces as much as you want. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
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 :|
participants (3)
-
Charles Duffy -
Daniel P. Berrange -
Richard W.M. Jones