Re: [libvirt] Proposed functionality: API to extract host description from saved state, restore with modified XML

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]