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 -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list