On Monday 23 August 2010 17:27:46 Jean-Baptiste Rouault wrote: > 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list Hi, Sorry to dig up this old thread but I'd like to have some feedback about adding the possibility to set a custom save path. Regards, Jean-Baptiste -- Jean-Baptiste ROUAULT Ingénieur R&D - Diateam : Architectes de l'information Phone : +33 (0)9 53 16 02 70 Fax : +33 (0)2 98 050 051 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list