On Mon, Jun 08, 2009 at 04:53:53PM +0200, Maximilian Wilhelm wrote: For this to work I assume you would have to issue the checkpointAt() command to all the virDomainptr objects you cared about, using a timestamp that is in the future, and hope that all the commands get dealt with in time. I'm not really convinced this is the best approach from the API pov. That said I agree that we need need a more advanced & clever API for save/restore/checkpoint. To start with I'd like an API that is following along these kind of lines: http://www.redhat.com/archives/libvir-list/2009-March/msg00205.html I think a first step would be producing a managed save/restore/checkpoint capability. Once that's working consider the issue of batched/synchronized operations. How accurate does a 'synchronized' checkpoint have to be ? millseconds, seconds or even more latitude ? Currently each save operation in libvirt blocks until completion. Clearly not good enough for a synchorized save of several VMs. If accuracy is on the order of 'seconds', then making a non-blocking option for the save method would allow an app to save/checkpoint multiple VMs in very close succession. If you need milli-seconds accuracy, then we'd need more explicit API support for a delayed operation, or the abiity to define an object representing a group of VMs, and then issue an operation on that group, letting libvirt then dispatch it to each VM internally. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|