Re: [Qemu-block] [Qemu-devel] [PATCH] rbd: Detect rbd image resizes and propagate them

[Adam Wolfe Gordon]

On Wed, Sep 13, 2017 at 6:47 PM, John Snow <address@hidden> wrote:
> On 09/13/2017 05:36 PM, Adam Wolfe Gordon via Qemu-devel wrote:
>> On Wed, Sep 13, 2017 at 2:53 PM, John Snow <address@hidden> wrote:
>> We have a storage orchestration service that manages our ceph block
>> storage clusters and doesn't interact directly with qemu. Volumes get
>> resized through the orchestration service, which (after doing some
>
> resized bigger, one hopes ...

Indeed! That's actually one of the reasons for this change: it's much
easier to guarantee that we're always resizing bigger if all resizes
are issued in the same place.

>> Previously, we would notify the VM of the resize by issuing a
>> blockresize via qmp after doing the resize itself externally. That
>> meant we were actually resizing the rbd image twice (though the second
>> was, hopefully, a no-op). We occasionally had trouble with the resize
>> issued by qemu getting stuck and blocking the qemu main thread.
>> Detecting the out-of-band resize lets us avoid the extra rbd_resize
>> call and means that we never modify an rbd image's metadata from qemu.
>>
>
> Hm, I see... It sounds like you want an operation here that lets us
> detect medium changes without actually attempting to orchestrate one.
>
> It smells like you want the second half of bdrv_truncate without
> actually issuing the call. Perhaps you could split this function into
> its two halves, and in the event of an external resize being detected,
> you could call the latter-half portion of bdrv_truncate.

Yes, I think that agrees with what Jason Dillaman suggested yesterday,
and makes sense to me. Will do that for a v2 of this patch.

> ...if the drive is configured to automatically detect those events, that
> is. Conceivably not all resize events that QEMU *could* detect *should*
> automatically result in guest-visible changes as soon as they occur.

Good point. I can add an option for this to the rbd driver. My gut
feeling is that the default should be off (i.e., the existing
behavior) to avoid any surprises for users who upgrade.

Thanks for the review. I'll get a v2 out as time allows.

-- awg