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

[Saori Fukuta]

Hi,

I would like to talk more about this.
Can I hear your comments ?

Thanks,
Saori Fukuta

On Wed, 16 May 2007 10:07:06 +0900 Saori Fukuta wrote:
> 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
> 
> --
> Libvir-list mailing list
> Libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list