Re: Xen guest disk online resize, xenstore/blkback/blkfront questions

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2010-01-06 at 20:26 +0000, Pasi Kärkkäinen wrote:
[...] 
> Is this more or less correct? Please correct if I've missed something or
> understood something wrong.

All sounds vaguely familiar, although it's been a while since I last had
to follow those twisty paths around...

> So, what I need to do next:
> 
> - LVM online-resize the guest disk LV in dom0.
> 
> - write something to xenstore block device backend structures, 
>   to get the blkback driver notified about the 'block-resize'.
> 
>   Should I add a new xenbus_watch for some, say, 'resize' field, so I could get
>   callback to blkback device_resize() easily when xenstore is updated? 
> 
> - blkback driver then needs to update/fetch the new size of the vbd, 
>   and update the xenstore /local/domain/0/backend/vbd/X/sectors field.
> 
>   Any problems getting the new size/sectors on-the-fly in the kernel? 

You might need to close and reopen the block device? 

Idle speculation: perhaps instead of an explicit "resize" field in
xenstore you could just have the backend continue watching the
'physical-device' node even after everything is connected the first time
and if it is rewritten (including to the same value) reopening the
physical device and setting things up again (picking up a size change as
a side effect).

There's no particular reason why the physical device couldn't change
over this operation either, you could maybe imagine changing to a
different device mapper node (e.g. perhaps some sort of wierd snapshot
mechanism?) or perhaps implementing some sort of PV-CDROM media change
in the same way.

> - blkback then needs to write something to xenstore block device frontend
>   /local/domain/X/device/vbd/Y/ to notify the blkfront driver in the guest.
> 
>   Same thing here, should blkfront have a watch for some 'resize' field
>   or so?

blkfront can probably just watch /local/domain/0/backend/vbd/X/sectors

Ian.