[Libvir] RFC: Behaviour of virConnectSave, Restore and CoreDump in the remote case

[Daniel Veillard]

On Mon, Apr 30, 2007 at 03:35:54PM +0100, Richard W.M. Jones wrote:
> virDomainSave (for example) is currently defined like this:
> 
> /**
>  * virDomainSave:
>  * @domain: a domain object
>  * @to: path for the output file
>  *
>  * This method will suspend a domain and save its memory contents to
>  * a file on disk. After the call, if successful, the domain is not
>  * listed as running anymore (this may be a problem).
>  * Use virDomainRestore() to restore a domain after saving.
>  *
>  * Returns 0 in case of success and -1 in case of failure.
>  */
> 
> In the remote case there are, I think, three possible things that this 
> call could do:
> 
> (A) Copy the image over the network connection to save it locally
> 
> This is possibly the most "authentic" option.  Callers using remote can 
> specify a local path and the image file will appear at that path, 
> locally, making the remote case reasonably transparent.
> 
> However image files are usually pretty large, and copying them over a 
> network connection could be slow.  In particular the network connection 
> may be over loopback -- eg. in the case where we are allowing ordinary 
> users to connect to a locally running libvirtd with elevated 
> priviledges.  (It's quite hard in general to determine if remote is 
> really connected to a different machine, eg. think about the case where 
> we are using ssh tunnels).
> 
> In some ways this is the most secure option.  The image or core dump is 
> written by the user process, so there is no way to get a daemon with 
> elevated privs to write over a file in /etc for example.

  I think the current code and comments we made on the list make relatively
clear that virDomainSave saves to a domain on the system where it is running.
I agree that the security aspect is annoying, but that's how remote xend 
access currently work. I'm a bit vary of changing that semantic in a way.

> (B) Save it remotely
> 
> Remote isn't transparent.  We save it remotely.

  IMHO that's the status quo.

> We could consider adding a virDomainSaveLocal API call for the case when 
> we really want to save it locally.

  I guess it's two distinct APIs, and both could be useful. Adding a new API
when actively adding remoting support in libvirt doesn't sound weird to me,
but maybe being a bit more flexible on the from and to arguments for:
    - virDomainSave
    - virDomainRestore
    - virDomainCoreDump
would be good. Maybe allowing URI constructs like
   file:///tmp/domain.sav
   file://localhost/tmp/domain.sav
to indicate saving locally instead of using a path relative to the machine
where the domain is running and
   file://admin@somehost/home/admin/domain.sav
to contact libvirtd and save to a remote host, assuming there is no 
shared storage making it easier.

  The first scenario is similar to what you are proposing, just integrating
in the existing framework and keeping the same API, the second is a bit more
futuristic :-) but if doable would be great IMHO !

What do you think ?

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/