[libvirt] New save/restore api proposal
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 ? Regards, Jean-Baptiste
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 :|
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
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@redhat.com 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
participants (2)
-
Daniel P. Berrange -
Jean-Baptiste Rouault