On Fri, 31 Mar 2006 16:47:38 -0500, Daniel Veillard wrote: > 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. MaxMemory is the cap allocation for a domain. It can never allocate more than MaxMemory. Note, that a domain can "balloon" up to or down from MaxMemory. SetCurrentMemory "requests" that a domain "balloon" itself to a particular target. Note that setting MaxMemory at runtime has been broken since the 2.0.x series. I don't know why we bother even exposing it anymore in Xend as I don't think there are any plans to fix it. Regards, Anthony Liguori >> 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