WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Xen guest disk online resize, xenstore/blkback/blkfront questions
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
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