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