[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [RFC] Life-cycle Management of the domain take2



On Fri, 11 May 2007 14:06:07 -0400 Daniel Veillard wrote:
> > Can I ask something ? That means adding xmlDomainPtr to virDomainPtr,
> > like this ?
> > 
> > struct _virDomain {
> >     unsigned int magic;                  /* specific value to check */
> >     int uses;                            /* reference count */
> >     virConnectPtr conn;                  /* pointer back to the connection */
> >     xmlDomainPtr conf; <----this one
> >     char *name;                          /* the domain external name */
> >     int id;                              /* the domain ID */
> >     unsigned char uuid[VIR_UUID_BUFLEN]; /* the domain unique identifier */
> > };
> 
>   I am not sure we can bind the two like this in general. That's something
> which would be possible if you use a configuration and then ask to start
> the domain (in a way similar to virDomainCreate() but from a configuration).
> But we can't expect to have a configuration everytime we get a Domain.
> If you start virsh and list the domains you will get the virDomainPtr
> of running domains, but you won't be able to guess in general where the
> config file for them would be. Does that make sense ?

Hmm, sorry but I do not really understand why the xmlDomainPtr is needed
because I do not want to use "config file".

To give an example, I would like to achieve in a manner similar to the way 
the virt-manager remove the device.
---
virtManager/domain.py:remove_device
    1. dumpXML
    2. modify the defined XML
    3. define

But, there are the necessary information that is Xen-specific or should not be
shown to all-user in sxp-format, and we should not have such information in XML.
So I selected using sxp-format instead of XML, i.e. modifying the config at
lower layer (xend_internal.c) that I proposed before.
---
xend_internal.c
    1. root = sexpr_get(domain->conn, "/xend/domain/%s?detail=1",domain->name);
    2. snprintf(buf, sizeof(buf), "%lu", memory >> 10);
    3. sexpr_chg_node(root, "domain/memory", buf, sizeof(buf)); /* new API */
    4. ret = xend_op(domain->conn, "", "op", "new", "config", buf, NULL);

> > Now, the result of command seems not to be consistent when the domain is
> > not running. So I think if we can separate the API between running
> > domain and not running domain, we get the consistent result.
> 
>   I'm not sure I understand. Say you use virDomainSetMemory() with a 
> very large value. I agree that if you target a running domain you may 
> get an error due to lack of memory on the host, while running the 
> same call on a virDomainPtr addressing a configuration file you are
> not likely to see such error raised. Are you concerned by this kind of
> difference in behaviour or something else ?

And my concern is that there are 2 kinds of return (some command returns
success but some command returns failure) when executing the virsh command 
while the domain is not running, because of depending on Xen.

For example, there are following result for current Xen:
    success : setmem, setmaxmem
    failure : setvcpus, vcpupin, device attach/detach(*)

"device attach/detach" is a command being proposed by Sunou-san now,
but that will return failure because "xm block-attach/detach" is failed
while the domain is not running.

This might be Bug of Xen, so we should approach this to Xen. But also I think 
we can choose the way that has least impact of Xen Bug.
What do you think about this ?

Thanks,
Saori Fukuta


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]