Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/11/2010 02:34 AM, Kevin Wolf wrote:
>
> Well, if you're aware of the semantics of this value, it might be. It's
> not exactly intuitive, but this is currently hidden inside qemu.
>
> What the high watermark says (in this implementation) is the highest
> offset into the image file of an cluster that was allocated during this
> qemu run. If you restart qemu, it starts at 0 again.
>
> I think there once was a version that tried to calculate the absolute
> highest value when the image was opened, but it was reverted because it
> just took too long. For the same reason I think a low watermark is
> unrealistic, even if we get shrinking images some time. It's just not
> doable efficiently, at least not in an easy way.
>
> I'm not sure if this semantics makes it a good public interface. Other
> than that, I'm not overly concerned with doing it like you suggest.
>    

Making it an event certainly exposes it as part of the public interface 
though, no?
Correct. A management tool could poll every 5 minutes to make the same

>> determination.
>>      
> Yes. At the cost of doing it too little during installation and too
> often during regular operation. Of course, you could add heuristics to
> make the interval dynamic...
>    

Depends on how much room you leave in your watermark.

> But honestly, while I do understand your point, this feels like a hack
> to work around shortcomings of an interface. So what we need to decide
> is which criterion outweighs the other in practice.
>    

If I understand the use case correctly, what this really boils down to 
is that you want to create a growable image on top of a non-growable 
device.  The management tool then deals with growth using this interface.

I'm somewhat inclined to suggest that the proper way to support this is 
to teach qemu how to grow the LVM volume like it would grow any normal file.

>> This approach seems superior to me because it's considerably more
>> flexible.  In this particular model, you have one disk on an LVM volume
>> and you need to grow that single disk image when you hit a high water mark.
>>
>> However, an alternative and equally valid model would be an LVM volume
>> containing a file system with multiple disk images for a single guest.
>> In this case, there is no high water mark for an individual disk, but
>> rather, there's a high water mark for the combination of all the disks.
>>      
> If your file system supports sparse files, it's the wrong number. You
> need the allocated space then, not the highest offset. I really can't
> see much use of this watermark outside the original model.
>    

Good point.

Regards,

Anthony Liguori

> Kevin
>