[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [RFC] Life-cycle Management of the domain take2



On Fri, May 11, 2007 at 07:15:33PM +0100, Daniel P. Berrange wrote:
> On Fri, May 11, 2007 at 02:07:50PM -0400, Daniel Veillard wrote:
> > On Fri, May 11, 2007 at 10:59:37PM +0900, Saori Fukuta wrote:
> > > Hi,
> > > 
> > > Thank you for your comment !
> > > 
> > > On Fri, 11 May 2007 13:33:57 +0100 "Richard W.M. Jones" wrote:
> > > > It sounds to me like the real solution would be to either fix 
> > > > virDomainGetXMLDesc to return these missing fields, or add another call 
> > > > to get them, or (for the password) to store it elsewhere.
> > > > 
> > > > How about loading the original config XML and the XML from the running 
> > > > domain (virDomainGetXMLDesc), and then updating the config XML with only 
> > > > certain fields from the running domain?
> > > 
> > > Well, I'm not sure about the meaning of "original config XML" but I do
> > > not think it is possible because the original config file might be not XML
> > > like a Xen config file. Xen does not have XML file.
> > > Is this right ?
> > 
> >   Yes I'm not sure that in general you can always hope to reconstruct the
> > content of the configuration file just from a pointer to a running 
> > instance,
> 
> If the guest was created by libvirt, then I consider it a bug if the XML
> dump does not allow re-creation in exact same config. 
> 
> If the guest was created by non-libvirt app, then there may be some xen 
> specific bits we don't support in libvirt. So be it - there are some things
> we simply don't want to support. For any of the latter  case, we can at 
> least evaluate whether it makes sense to support them throughout libvirt,
> and/or accept patches.
> 
> The main flaw I see currently is that the vncpassword is missing from the
> XML. We left that out for security obviously. We definitely have to exclude
> it if using a read-only connection. For a read-write connection we should
> probably continue to exclude it by default, since apps often write the XML
> dump to logfiles. We do fortunately have a (currently unused) flags argument
> to virDomainGetXMLDesc
> 
>   char *                  virDomainGetXMLDesc     (virDomainPtr domain,
>                                                    int flags);
> 
> I propose we add a flag LIBVIRT_XML_INCLUDE_SENSITIVE  or something like
> that. If that flag were used, then we could include the password in the
> returned XML. Any apps using that flag would be aware that the XML should
> be treated as sensitive & thus not logged.

On this subject of XML dumps for live VMs, there is the option that the
live VM config will be different from the one on disk. Currently the
virDomainGetXMLDesc will always give you the live config if the guest
is running, and the disk config if the guest is not running. The option
missing here is obviously a way to get the disk config if the guest is
running. Now we have this convenient flags arg here still which we could
use:

  char *livexml = virDomainGetXMLDesc(dom, 0);
  char *diskxml = virDomainGetXMLDesc(dom, VIR_DOMAIN_XML_INACTIVE);

Once you have the real diskxml, then you can update it & use the 
 
  virDomainDefineXML(dom, diskxml)

to re-write it on disk,

  virDomainCreate(dom, diskxml)

if you want to create a VM with the new config, without actually updating
the config on disk

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]