[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Xen guest disk online resize, xenstore/blkback/blkfront questions


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Pasi Kärkkäinen <pasik@xxxxxx>
  • Date: Wed, 6 Jan 2010 22:26:31 +0200
  • Delivery-date: Wed, 06 Jan 2010 12:26:52 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.