|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Xen guest disk online resize, xenstore/blkback/blkfront ques
Hello,
I started implementing support for on-the-fly/online resizing of Xen PV
guest disks.
I added 'block-resize' command to xm, and added device_resize() function
to xend.
I'm able to do 'xm block-resize <guest> <guest_disk>" and my new
device_resize() function in xend gets called. All fine so far.
Now I'm trying to understand the internals of how kernel
blkback/blkfront and xenstore interact with each other, so I can
implement the actual resizing.
This is how I've understood the flow of adding/creating a block device
in Xen:
- blkback driver in dom0 kernel runs xenbus_register_backend(), which
makes xenstore to notify blkback about new block devices via xenbus.
- When xend DevController.createDevice() for new block device gets called,
it writes the initial block device configuration to xenstore.
- Xenstore then notifies blkback via xenbus, and the blkback_probe() function
of blkback gets called.
- blkback_probe() creates the backend device in dom0 kernel, and
sets up a xenbus_watch to get notified about 'physical-device' changes
in xenstore block device backend information.
- udev hotplug scripts get executed when the new backend device is
created in the dom0 kernel, and when the udev hotplug scripts are done
they update the xenstore block device backend 'physical-device' information
to trigger blkback notification.
(what do the udev hotplug scripts actually do here?)
- Xenstore block device backend 'physical-device' updates cause xenbus_watch to
call
blkback backend_changed(). Physical device major/minor, mode and type
are then fetched from xenstore. Then vbd is created in the kernel,
and update_blkif_status() is called.
- update_blkif_status() calls connect() which tries to connect the
backend with the blkfront frontend.
- connect() writes block device size in sectors and sector-size
to xenstore, and changes the state to 'connected' so frontend can
fetch the information from xenstore and bring itself online.
Is this more or less correct? Please correct if I've missed something or
understood something wrong.
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?
- 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?
How does that sound like? All comments and help appreciated!
-- Pasi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] Xen guest disk online resize, xenstore/blkback/blkfront questions,
Pasi Kärkkäinen <=
|
|
|
|
|