[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Xen guest disk online resize, xenstore/blkback/blkfront questions
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |