On Tue, Sep 27, 2011 at 03:52:38PM +0800, Daniel Veillard wrote: > On Fri, Sep 23, 2011 at 10:23:15AM -0600, Eric Blake wrote: > [...] > > Independent of your patch, I also just realized that > > virDomainSave[Flags], virDomainRestore[Flags], > > virDomainSaveImageGetXMLDesc, virDomainSaveImageDefineXML, and > > virDomainCoreDump all have the same design issue: they are not very > > nice for remote management. Each of these functions convert a > > relative path name into absolute name on the client side, before > > passing the string to the remote side, even though the actual file > > to be used is on the remote side. This is not always guaranteed to > > work, and also leaves things stuck with the file being on the remote > > side (no way to dump the core across the network back to the client, > > like there is with virDomainScreenshot). > > yes, known annoying issue with those entry point nearly since day 1 of > libvirt. > > > At some point, we may want to introduce new API that performs these > > types of operations on a stream, where the client can then manage > > the stream. And/or we may want to introduce a way to specify the > > "file" to manipulate as a virStorageVolPtr, or even a string > > relative to a virStoragePoolPtr, for more precise control of where > > the file ends up without having to first "absolutize" the file > > argument in the client. > > Right we now have enough support to provide better APIs > with streams, the 'only' problem is that basically the operation > should only succeed if the whole stream was fetched correctly, > because the last thing we want is a virDomainSaveStream suceeeding > but where the data were not completely and reliably transmitted to the > user, the data loss would be too huge, we can't stop the domain > in such a failure. That's a bit tricky ... > The alternate way which would have my preference is > virDomainManagedSave... entry points where libvirt has the authority > on the storage and can make sure everything is available, and then > a specific function to stream back a managed save through a stream. > Then we also have the existing entry point to delete a managed save > so we have only 1 remote streaming function to really implement and > get right, Arguably, even with the regular virDomainSave method, you actually *do* want the file to be saved on the remote server. eg consider virt-manager running on your laptop, managing a bunch of virt servers. You don't want the VM save images to be on your laptop, you want them on the remote server. Core dump is the one where it is likely that you do want to get the core file onto the client machine. An impl using the streams API would suit this perfectly. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list