Re: [Xen-devel] [PATCH V5 31/32] libxl: update domain configuration when updating memory targets

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, May 20, 2014 at 05:03:06PM +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH V5 31/32] libxl: update domain configuration 
> when updating memory targets"):
> > On Tue, 2014-05-20 at 16:44 +0100, Ian Jackson wrote:
> > > Merging the lists from libxl_device_disk_list and the JSON
> > > configuration shouldn't be too hard and will eliminate a lot of worry
> > > about races.
> > 
> > I think the presence of defaults in the libxl API makes it hard.
> 
> What I'm suggesting for the implementation of "get list of disks for
> retreived configuration" is something like this:
> 
>   * Read JSON with list of stored disk configs
> 
>   * Iterate over actual devices a la libxl_device_disk_list
>     * For each device, look for corresponding configuration in
>       disk config.
>       * If no such configuration, print a warning and make one up
>         along the lines of libxl_device_disk_getinfo
>       * If there was such a configuration, update the dynamically
>         adjustable fields by copying them from xenstore:
>          * currently, I think this is only the backing device
>            info (which can be modified dynamically for cds at least)
>     * Add resulting disk config to new list of disk configs
> 
>   * Replace stored list of disk configs with new one
> 

This comes back to our discussion on half-baked state. I would say that
if a device doesn't exist in JSON but in xenstore, it shouldn't be
considered a valid device, so that we don't need to store it in config.

As I see it the most possible way for one device that exists in xenstore
but not JSON is that we've successfully added that device but failed to
store JSON configuration. Saving file seems to be the least possible
point of failure, compared to other operations.  If we fail at any point
before saving config, which results in half-baked xenstore state, the
device is not valid.

This is still an open question though, as my code seems to be the first
instance to try to deal with it.

Wei.

> The effect is that the pre-defaulted configuration takes precedence
> but that it is safe to write a JSON configuration containing devices
> which are about to be added.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel