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