Re: New save/restore api proposal

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

 



On Thu, Aug 19, 2010 at 05:12:36PM +0200, Jean-Baptiste Rouault wrote:
> Hello all,
> 
> I'd like to add support for save and restore to the OpenVZ and VirtualBox 
> drivers because I have to support these operations in the application I'm 
> working on.
> 
> However, the save/restore API in its current state doesn't fit well to our 
> needs. The main problem is that the domain definition is included inside the 
> save file. This is problematic because between the save and the restore 
> operations, the names of the network interfaces on the host side are likely to 
> have changed and we can't modify them before restoring the domain.

IMHO a more general approach is to set stable naming for the host
devices. 

> To summarize, what we would like to be able to do is:
> - save a domain and undefine it
> - update the domain definition to use the new names of host side interfaces
> - restore the domain
> 
> This is why I would like to add two new functions with the following 
> signatures (better names are probably needed):
> int virDomainSaveState(virDomainPtr domain, const char *to);
> int virDomainRestoreState(virDomainPtr domain, const char *from);
> 
> The first one would do the same as virDomainSave but without prepending the 
> domain's definition to the save file.
> The other function would be able to restore a domain saved by the first one.
> 
> What do you think ?

I really don't think we want to add yet more save/restore functions
to the API. I'm not sure its even possible to implement those 
proposals with VirtualBox, since it can't save state to an arbitrary
file. 

The API in the VirtualBox SDK is  IProgress IConsole::saveState().
This does a managed save internally to  vbox. The next time the
guest is started, it will restore from this image. This maps
directly to libvirt's virDomainManagedSave() API. The OpenVZ docs
appear to explicitly forbid any change to the VM configugration
between time of save & restore. If it didn't forbid config changes,
then in theory you could call virDomainDefine() after calling
virDomainManagedSave() but before virDomainCreate() in order ot
change the config.

As for OpenVZ, the vzctl chkpnt & vzctl restore commands look like
they can map directly to both of the libvirt save/restore APis. The
original one taking a filename, and the new managed save ones.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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]