[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 09/10] libxl: introduce libxl_retrieve_domain_configuration
On Thu, 2014-07-17 at 13:11 +0100, Wei Liu wrote: > On Thu, Jul 17, 2014 at 11:59:01AM +0100, Ian Campbell wrote: > > On Thu, 2014-07-10 at 15:32 +0100, Wei Liu wrote: > > > Introduce a new public API to return domain configuration. This returned > > > configuration can be used to rebuild a domain. > > > > > > Note that this configuration doesn't equal to the current state of the > > > domain. What it does is to use JSON version configuration as template > > > and pull in relevant information from xenstore. > > > > I think this configuration does equal the current state, doesn't it? > > Isn't that the whole point? > > > > Hrm... by "current state" I mean the current running state. But to > rebuild a domain we might leave some configurations for the remote host > toolstack to decide. The configuration this API returns is (template > configuration + current state that we care about). Hrm, I can't think of a good name for this. Describing it as the state needed to reproduce the guest visible state might make sense? > > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > > > index 49d7ef6..cd5914c 100644 > > > --- a/tools/libxl/libxl.c > > > +++ b/tools/libxl/libxl.c > > > @@ -6034,6 +6034,206 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac > > > *dst, libxl_mac *src) > > > for (i = 0; i < 6; i++) > > > (*dst)[i] = (*src)[i]; > > > } > > > + > > > +int libxl_retrieve_domain_configuration(libxl_ctx *ctx, uint32_t domid, > > > + libxl_domain_config *d_config) > > > > It occurs to me to wonder if any function which takes a lock ought to be > > async capable? > > > > Good point. > > > Also is there is any possibility that any of the operations needed to > > gather the updated configuration might take a long time. > > > > I think reading from xenstore and filesystem can be slow, in the sense > that if there's much contention on these two resources it could take > seconds to finish operations. I'm pretty sure we don't consider those to be "slow". See in libxl_internal.h: * "Slow" functions includes any that might block on a guest or an * external script. More broadly, it includes any operations which * are sufficiently slow that an application might reasonably want to * initiate them, and then carry on doing something else, while the * operation completes. That is, a "fast" function must be fast * enough that we do not mind blocking all other management operations * on the same host while it completes. * * There are certain primitive functions which make a libxl operation * necessarily "slow" for API reasons. These are: * - awaiting xenstore watches (although read-modify-write xenstore * transactions are OK for fast functions) * - spawning subprocesses * - anything with a timeout > > > + /* Memory limits: > > > + * > > > + * Currently there're three memory limits: > > > + * 1. "target" in xenstore (originally memory= in config file) > > > + * 2. "static-max" in xenstore (originally maxmem= in config file) > > > > Nit: strictly speaking those "originally..." are xl specific and this is > > libxl. </pendant> > > > > You mean I should write "originally memory= in xl config file"? That would satisfy my pedantry, yes ;-) But maybe you want to reference the libxl_domain_config fields instead? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |