Cole Robinson wrote: > The attached patch implements storage volume allocation progress > reporting for file volumes. > > Currently, the volume creation process looks like: > > - Grab the pool lock > - Fully allocated the volume > - 'define' the volume (so it shows up in 'virsh vol-list', etc) > - Lookup the volume object to return > - Drop the pool lock > > The new sequence is: > > - Grab the pool lock > - 'define' the volume (even though nothing is on disk yet) > - Drop the pool lock > - Allocate the volume as needed > - Regrab the pool lock > - Lookup the volume object to return > - Drop the pool lock (again) > > Since the volume is 'defined', the user can fetch an object reference in > a separate thread, and continually poll the 'info' command for up to > date numbers. This also has the benefit of dropping the pool lock during > the potentially lengthy allocation, as currently 'virsh pool-list' etc. > will block while any volume is being allocated. > > Non file volumes maintain existing behavior. > > I tried to make the implementation resistant to user error: say if the > pool is deactivated or deleted while the volume is being allocated. The > creation process may bail out, but I couldn't produce any bad errors > (crashing). > > There are a few other small fixes in this patch: > > - Refresh volume info when doing volume dumpxml > - Update volume capacity when doing a refresh I'm realizing now that this piece isn't correct, since the capacity updating for volumes in this case is only relevant for raw files. There seem to be some other problems in this area independent of my patch, which I'll be posting fixes for soon. Thanks, Cole -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list