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

Re: [libvirt] New save/restore api proposal

On Monday 23 August 2010 14:51:51 you wrote:
> 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.

This is not possible for us because our application is distributed on multiple 
servers. We have a huge nfs exported folder where we store all our guests' 
disks and private folders. A saved guest which was running on one server can 
be restored on another one so we can't set stable naming for the host side.

> 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.

The problem of the managed save API for us is that it doesn't allow to set a 
custom save path. We keep save states in each VM's folder so that any of our 
servers is able to access them. Maybe a custom managed save path could be 
specified in a domain's xml and then used instead of the default one ? This 
isn't a problem for VirtualBox because there is the adoptSavedState API.
For other libvirt drivers I think this shouldn't be too difficult to implement.

> 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

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