On Tue, Jul 20, 2010 at 12:49:47PM -0700, Jeremy Fitzhardinge wrote:
> On 07/20/2010 11:29 AM, Pasi Kärkkäinen wrote:
> > On Tue, Jul 20, 2010 at 10:37:51AM -0700, Jeremy Fitzhardinge wrote:
> >
> >> On 07/20/2010 10:28 AM, Pasi Kärkkäinen wrote:
> >>
> >>> On Thu, Mar 18, 2010 at 02:01:20PM -0700, Jeremy Fitzhardinge wrote:
> >>>
> >>>
> >>>> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
> >>>>
> >>>>
> >>>>> The attached patch supports dynamic resizing of vbds. This patch fixes
> >>>>> a bug in the previous version of this patch that was sent out. With
> >>>>> this patch you can perform "online" resizing of file systems that
> >>>>> support online resizing.
> >>>>>
> >>>>>
> >>>>>
> >>>> Please send a delta against the previous patch, since it has already
> >>>> been applied.
> >>>>
> >>>>
> >>>>
> >>> Btw dynamic vbd resize is something we should get into mainline Linux..
> >>>
> >>>
> >> Good point. I created a branch called "upstream/blkfront" with a
> >> candidate set of blkfront changes to send. Could you test it out?
> >>
> >>
> > Sure. I can test it tomorrow.
> >
>
> Thanks.
>
> > it seems xen/stable-2.6.32.x branch already has these patches
> > so dom0 side is easy for the test..
> >
> > should I try the blkfront patches against the latest Linus git tree, or
> > 2.6.34, or ?
> >
>
> That branch, upstream/blkfront, is rebased onto v2.6.34, so you can test
> it as-is, or merge it into the current linux-2.6 branch (which is a
> clean merge).
>
Ok, I finally got to it.
It seems to work OK for me. I installed Fedora 13 PV guest and
updated the kernel to xen.git 'upstream/blkfront' branch (2.6.35-rc4).
Then I added 'xvdb' disk to the guest, which was 4 GB initially.
I started the guest and verified disk is 4GB in size from /proc/partitions.
And then in dom0:
# lvextend -L+1G /dev/vg_f13/resizetest2
Extending logical volume resizetest2 to 5.00 GiB
Logical volume resizetest2 successfully resized
Nothing in dom0 logs at this point. Nothing in domU logs either.
Then I did in the domU:
[root@resizetest1 ~]# fdisk -l /dev/xvdb
Accessing the device caused in domU dmesg:
Setting capacity to 10485760
xvdb: detected capacity change from 4294967296 to 5368709120
xvdb: unknown partition table
[root@resizetest1 ~]# cat /proc/partitions | grep xvdb
202 16 5242880 xvdb
So resizing seemed to work OK.
That also triggered the following in dom0 dmesg:
device vif5.0 entered promiscuous mode
virbr0: topology change detected, propagating
virbr0: port 1(vif5.0) entering forwarding state
blkback: ring-ref 8, event-channel 23, protocol 1 (x86_64-abi)
blkback: ring-ref 9, event-channel 24, protocol 1 (x86_64-abi)
vif5.0: no IPv6 routers present
VBD Resize: new size 10485760
-- Pasi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home