On Fri, Apr 14, 2006 at 10:38:23AM -0400, Bret McMillan wrote: > I think we're confusing the notion of what a passive domain is with what > config files happen to be sitting on / exposed to the dom0 machine. I > could very easily look at having an rdbms store the info about the > passive domain, hand that down to the dom0 via rpc, and directly call > the createLinux call. To me, that's still a passive domain, even though > it's configs haven't touched disk yet. Yup, to me they are different level. > I guess I'm also struggling to understand why you'd toss this into > xenstore... it just seems this is a higher level concept that needs to > be tracked in too specific a way by management systems. The reason it would be useful to save this in xenstore is to garantee the same vision between different application managing that node (for example a remote supervision tool and a local launcher used by the user). Otherwise

just keeping this information in libvirt own memory would be just fine, I'm still unsure the need to synchronize is really there.

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.

I think there is a much harder question concerning the interplay of libvirt and the xm tools that this API discussion is somewhat sidestepping. Currently, the xm tools set a defacto standard for how you define inactive domains; libvirt will add a second mechanism with the proposed API. And since the libvirt XML descriptions are a much nicer way to describe a domain than the python scripts in /etc/xen, there's a big temptation to write libvirt based tools that use the XML description and replicate (some) of the xm functionality. That would give us three separate ways to define an inactive domain on a local system - madness ensues. I would be very curious to hear how people see how the libvirt XML descriptions and xm or libvirt-based xm-like tools would interact.

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); 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.

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);

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.

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.