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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list