Re: [Libvir] Request for additional entry points
On Fri, Mar 31, 2006 at 10:56:06AM -0700, Jim Fehlig wrote:
As discussed on the xen-cim call on 3/31, the Xen CIM provider needs
some additional entry points in libvirt. I would like to open a
discussion about adding the following entry points to libvirt.
virDomainSetConfig(virConnectPtr conn, const char *xmlDesc)
Stores the domU config data in xenstore. The domU is not running yet
but enumerating domains would return the config for the domain as well
as any running domains. This would support the notion of a defined but
inactive virtual machine. Daniel noted that the config could be cached
in libvirt, preventing (to some degree) modifying the config out-of-band
prior to activating the domain. Note that the current
virConnectListDomains() implies enumerating only running domains since a
list of domain IDs is returned. Perhaps virConnectListDomains() will
have to be expanded to include defined domains or another entry point to
enumerate defined domains.
Well libvirt doesn't have the notion of 'passive' domain yet, i.e. domain
we know exists but are not running or activated at a given point in time.
If we define virDomainSetConfig() then we have to be able to extract at least
the name (and uuid) from the xmlDesc. And that routine could then returm
a virDomainPtr associated to this unactive domain (or the associated
active domain if it exists). Those unactive domains could then be listed
in virConnectListDomains(). In general libvirt doesn't yet create a unique
proxy object per running domain, the unicity need to be garanteed, it's a TODO
and add other constraints like reference counting and mutex when modifying
a domain.
Related would be activating a defined domain. Would clients get the
domain config (via virDomainGetXMLDesc()) and subsequently pass it to
virDomainCreateLinux() or another entry point to create a defined domain?
I would rather add an xmlDomainCreate(domain) taking as the argument
the returned domain from virDomainSetConfig().
virDomainDeleteConfig(virConnectPtr conn, const char *name)
Removed domU config from xenstore (or cache). DomU no longer "exists".
What if domain is active upon invocation?
Semantic would have to be defined. I would think of a destroy if the
reference count for the domain goes down to 0 then.
virDomainSetCurrentMemory(virDomainPtr domain, unsigned long memory)
Adjust the current memory usage for a domain.
We have SetMaxMemory already, I understand there is a difference in Xen
between the max defined memory and the current target, but we need to nail
down precisely the meaning of the 2 apis if introducing a new one.
virDomainReboot(virDomainPtr domain)
Reboot the domain.
Trivial kind of cut and paste from the Shutdown routines.
virDomainMigrate(virDomainPtr domain, const char *host)
?? Not sure what can of worms might be opened by this one :-).
That one is premature IMHO, and the second parameter would be
a virConnectPtr itselt open with a target specifying the host.
But it's too deep in the future to really say yes.
All other APIs looks fine and should be doable relatively easilly and
quickly.
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/