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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/