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.

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 ?

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