[libvirt] Proposed functionality: API to extract host description from saved state, restore with modified XML
11:17 p.m.
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!
5:42 a.m.
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
6:09 a.m.
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 :|
5967
days inactive
5969
days old
2 comments
3 participants
participants (3)
-
Charles Duffy -
Daniel P. Berrange -
Richard W.M. Jones