Re: Request for additional entry points

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

 



On Tue, Apr 18, 2006 at 09:16:19PM -0400, Bret McMillan wrote:
> On Tue, 2006-04-18 at 17:40 -0400, Daniel Veillard wrote:
> > On Tue, Apr 18, 2006 at 04:40:13PM -0400, Daniel Veillard wrote:
> > /* define a domain, but does not start it */
> > virDomainPtr   virDomainDefineXML(virConnectPtr conn, const char *xml);
> > /* undefine a domain but does not stop it if running */
> > int            virDomainUndefine(virDomainPtr domain);
> > /* list the defined domains */
> > int virConnectListDefinedDomains(virConnectPtr conn, const char **names,
> >                                  int maxnames);
> > /* launch a defined domain */
> > int virDomainCreate(virDomainPtr domain);
> > 
> >   extensions to the current behaviour:
> > 
> > - new state for defined non-running domains showing in virNodeGetInfo
> > - virDomainLookupByName() could return a defined non-running domain
> > - virDomainCreateLinux() would fail if a domain with the same name is
> >   already defined
> > - a number of existing APIs would fail on defined but non-running domains.
> > 
> >   that's it.
> 
> Daniel,
> 
> Thanks for the summary, I think it makes it a good bit clearer about
> what folks are shooting for.  Just a couple of questions for the folks
> thinking about using this state:
> 
> 1)  What state, local to the physical hardware, will be altered by calls
> to virDomainDefineXML?  Just xenstore?  Or would this stuff bleed over
> into configfiles getting dropped onto disk?  Or is that simply up to the
> management app calling into libvirt?

  IMHO, this could mean absolutely no state change on the managed machine,
libvirt could very well talk only to the remote node though just xend, 
libvirt would have those informations in memory, and even the remote
xenstore could not be affected at all. Another situation could be a local
tool run by the user where the configuration is pulled by the application
from say $HOME/xen and configs are written to xenstore. For the CIM model
feedback from an expert would be welcome :-)

> 2)  Do we expect other local tools to adopt this notion of state?  Or
> will this only live in libvirt-based code?

  If you mean do we expect xm to be extended for this, this seems unlikely
as xm is really based on the /etc/xen/ directory and libvirt precisely
try to avoid dependancy on any such local database, I don't expect both set
of use to be joined in general, but I may be wrong. If you start creating
your domains with libvirt, well you won't have an entry in /etc/xen 
unless you really like to store your data in python scripts which I guess
is not very common.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]