[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libvir-list
Subject:    [Libvir] RFC: Behaviour of virConnectSave, Restore and CoreDump in the remote case
From:       "Richard W.M. Jones" <rjones () redhat ! com>
Date:       2007-04-30 14:35:54
Message-ID: 4635FECA.6040908 () redhat ! com
[Download RAW message or body]


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.

(B) Save it remotely

Remote isn't transparent.  We save it remotely.

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

(C) Do nothing / present an error

Recognise that remote cannot deal with this at the moment, and don't 
implement this call.  Perhaps come back to it later in the context of 
remote storage management.

Opinions?

Rich.

-- 
Emerging Technologies, Red Hat  http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF     Mobile: +44 7866 314 421

Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)

["smime.p7s" (application/x-pkcs7-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]