[Libvir] Request for additional entry points

[Jim Fehlig]

Daniel P. Berrange wrote:

>On Tue, Apr 18, 2006 at 05:40:07PM -0400, Daniel Veillard wrote:
>  
>
>>On Tue, Apr 18, 2006 at 04:40:13PM -0400, Daniel Veillard wrote:
>>    
>>
>>>  So we have 2 more APIs which allows to define the XML for a domain
>>>and name it. That then allow to reserve that name, and the domain may be started
>>>later with a simpler API.
>>>      
>>>
>>Since I have troubles understanding why you have such an issue with this,
>>let's try to be as clear as possible. What I would expect is the following
>>APIs to be added:
>>
>>/* 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);
>>    
>>
>
>What would you anticipate the scope of the domains defined with these 
>APIs to be.  Would they be visible to only to the app defining them (ie
>just kept in process memory), shared between any locally running app 
>using libvirt on the host, or shared between arbitrary apps connecting
>to the HV, even if connecting remotely ?  
>
>  
>
>>  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. Now what is fundamentally wrong with that ? You don't have to
>>use it if you don't need it I assume the problem is harder than this.
>>    
>>
>
>There is nothing fundamentally wrong - *if* you are only aiming to support
>the needs of a simple local management tool.  In the broader case though it
>does not look to be effective because it:
>
> - Pre-supposes that there is a relation between a passive VM
>   and a particular host. This may be true in the simple local case, of 
>   VMWare Workstation type tool, but in a distributed environment it is
>   just doesn't make any sense - you have a group of passives VMs and
>   a group of potential hosts to run them on - there is no 1-to-1 mapping
>   between passive domains & hosts. 
>
> - Pre-supposes that the application creating/editing the passive VM
>   configurations wants to store them in the libvirt XML format. Again
>   while this may be true in the basic case it doesn't bear up to more
>   interesting scenarios, such as the idea of VM templates. In such a
>   case a generic template would define # of CPUs, # disk adapters, and
>   other general VM capabilities. A passive VM would only maintain perhaps
>   its name, path to disk image & a template name.
>
> - Assumes that passive domains are concept which neccessarily even exist
>   a head of time. A web server farm may merely comprise a stateless OS
>   image, and a set of potential hosts - domains for new OS images are 
>   defined on the fly as demand requires.
>
>Now I know there is nothing that requires an application to make use of these
>APIs - one could simply call virDomainCreate(const char *xml) at the time the
>new domain is needed, but in doing so there are now a broad set of scenarios
>where 'virConnectListDefinedDomains' will return an empty list.
>
>So I think my core question is - what are the client application uses cases
>& scenarios which these APIs are intended to serve.  If the app use cases /
>scenario were clearly described, then it could well be the case that the
>points I raise above are completely irrelevant. But without this info on
>uses cases I can't say whether the APIs described are sufficiently flexible
>or not.
>  
>

The DMTF System Virtualization Profile describes  the idea of a 
"defined" computer system, which is a computer system residing at the 
hosting node in the disabled, stopped, or off state but which can be 
immediately activatable.  The computer system's image, disks, etc are 
available and ready to be consumed at the hosting node.  The requested 
APIs were an attempt to represent the defined state (a computer system 
that is ready to go, just needs to be activated) further down the stack 
as I would think this state would be useful for other management apps 
and models.

Certainly in more interesting management scenarios, templates, config, 
images, etc. could be stored in other places and "deployed" to a 
selected host.  However, it seems valid that the management app may also 
want to query hosts about previously deployed but inactive domains.  
E.g. a possible use case:

- Management app user selects a VM for deployment and an appropriate 
target host.
- Management app queries target host to see if it knows anything about 
the VM
  - finds a "defined" VM already at the host
    - ensure the config at host matches the centrally maintained config 
description
    - activate the VM
  - find no knowledge of VM at the host
    - deploy config to host
    - activate VM

 From a data center perspective, I don't see the defined state at a 
particular host as a long-term state but more transitional.  A domain 
will be in the defined state from the time a user reserves the domain on 
the target host, while the host is being configured to run the domain, 
and until it is finally activated.  Perhaps a similar scenario when the 
domain is "retired" from a host, i.e. the domain is stopped (transitions 
to defined state), config torn down, and finally the config deleted from 
the host.

As has been pointed out in this thread, simple on-host management apps 
could use this as well to manage both defined and active domains.  I 
don't see how the proposed APIs restrict the evolution of more 
interesting management solutions discussed in this thread.

Regards,
Jim