[Libvir] [RFC] Life-cycle Management of the domain

[Daniel Veillard]

On Thu, Apr 19, 2007 at 07:07:08PM +0900, Saori Fukuta wrote:
> Hi Daniel,

  Hi Saori,

> Thank you for your comments and sorry about my unclear explanation.

  I don't think it's a misunderstanding, maybe it is, but I rather think
that you want to put something in libvirt, and I don't think it belongs
there but into the application using libvirt instead.

> Let me say what are the original data. The original data are 
> "/var/lib/xend/domains/<domain UUID>/config.sxp" that made by Xen when defining 
> a domain.

  With some version of Xen, not all of them. You cannot rely on that.
And what you suggest should be doable with that version of Xen must be doable
with any virtualization. How would you do this with Xen 3.0.3, with KVM or
with QEmu ? In KVM or QEmu there is no config files, just a running process.

> I expect the following Life-cycle:
>   1. "Define a domain"
>      -> a config.sxp file is made at "/var/lib/xend/domains/<domainUUID>".
>   2. "Start a domain"
>      -> libvirt copies a file from "/var/lib/xend/domains/.../config.sxp"

  No libvirt does not do that. And libvirt should not dig there. It makes
it way too dependant on how Xen work, and this 'feature' would not be 
portable to other virtualization engines.

> >   We can't know what are the original data which were used to create the domain
> > was that /etc/xen/... ? was that an XML file coming from a client application ?
> > was that another source by calling the Xen API ? 
> 
> So, we have the original data if the domain was defined by whether using 
> "/etc/xen..." or XML file.

  We cannot assume we have the original data. The data maybe be XML built
on the fly by a program using libvirt based on database records, and there
is no way libvirt will ever be able to modify those. This must be handled
by the upper layer.

> >   That I not too fond of adding ome more place where data for domain
> > definition can be stored.
> 
> I think that we need to store the domain definition to change a allocation
> dynamically or statically.

  And I strongly disagree with that suggestion because I don't think it's
a reasonnable expectation that we will always be able to do that.

> > but what we must make sure is that the API allow to make the required
> > change dynamically.
> 
> I'm not sure what you mean by "the API". Do you mean make sure that Xen API
> allow to change dynamically, or libvirt API ?

  Libvirt API provides entry points to manipulate objects. It should not
provide a storage for some of those objects. The more state you add at the
library level the more real problem you will get on the long term. It is a
library, not an application.
  Manage that state in your application. Don't expect to have the library
the state for you. But the library should provide the entry points needed
to change what it currently running.

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/