[Libvir] Re: Request for additional entry points

[Anthony Liguori]

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