Op Thursday 05 February 2009 16:36:04 schreef Pasi Kärkkäinen:
> On Thu, Feb 05, 2009 at 03:35:18PM +0100, Maarten Vanraes wrote:
> > Op Thursday 05 February 2009 15:27:55 schreef Pasi Kärkkäinen:
> > > On Thu, Feb 05, 2009 at 01:59:57PM +0100, Maarten Vanraes wrote:
> > > > Op Thursday 05 February 2009 13:05:01 schreef Pasi Kärkkäinen:
> > > > > On Thu, Feb 05, 2009 at 11:52:56AM +0100, Maarten Vanraes wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I have 2 questions:
> > > > > >
> > > > > > 1. I was not able to let the guest know that the partition size
> > > > > > was changed. 2. I was not able to use block-attach with the same
> > > > > > backendfile to different machines (eg: guest + dom0)
> > > > > >
> > > > > > I've read that block-reconfigure could've been used for this,
> > > > > > except that it wasn't designed to work for filebased vbd on PVs,
> > > > > > only for switching CDROMs in HVM
> > > > > >
> > > > > > When you use a local disk on a machine, you can use fdisk to
> > > > > > change partitions and sizes, it then rereads the partition table
> > > > > > to reflect those changes.
> > > > > >
> > > > > > Since i'm not using a disk, but directly partitions, isn't it
> > > > > > possible to just give a signal to the guest that it should
> > > > > > recheck the partition? can be from the guest itself.
> > > > > >
> > > > > > Some kind of workaround?
> > > > >
> > > > > Sorry, this is not possible.
> > > > >
> > > > > There's a a feature request about it for Xen 3.4.
> > > > >
> > > > > Dunno if it will be implemented.
> > > > >
> > > > > -- Pasi
> > > >
> > > > Yes, i read your thread, i was hoping for some kind of workaround,
> > > > some kind of "thing" i can execute on the guest, that would make the
> > > > kernel recheck it's partition size or something.
> > >
> > > The problem is not about rereading the partition table; this can be
> > > done using for example "blockdev --rereadpt".
> > >
> > > The problem is to get the disk device (/dev/xvd*) resized.. ie. getting
> > > the kernel to see the DISK has been resized.
> > >
> > > After the disk has been resized, partition table can be resized after
> > > that.
> > >
> > > Disk resizing on the fly is not supported today with Xen.
> >
> > Well I understand that it is inside the kernel, but, i'm not using disks,
> > i'm using partitions directly:
> >
> > e.g.:
> >
> > 'tap:aio:/opt/data/file.img, sda1, w'
> >
> > I can make the partition file larger on dom0 no problem, i could even
> > resize the partition live on dom0 no problem.
> >
> > But (i guess the kernel) doesn't see the partition as larger, even with
> > forced operations, i still get read errors at the end.
> >
> > I'm not even sure the blktap device detected this change in size on dom0.
> >
> > But if i'm using directly partitions, maybe there is some code that i can
> > execute that does kernel calls or something to refresh it's device. ie: a
> > workaround.
> >
> > I mean, hotplug seems to be able to do it just fine. ie: memory is
> > detected as larger, i imagine there is such code for block devices as
> > well, no? So i figured there should be something i can do in the guest
> > (maybe even on kernel level) that could force the re-detection of the
> > device or something.
> >
> > Of course if blktap can't even pass on the information to the guest, this
> > would not work at all...
>
> Like said, there's no way for Xen (or dom0) to tell domU that disk or
> partition has been resized. It is not yet implemented.
>
> Solution: Use LVM in domU and xm block-attach new disk/partition to domU,
> create PV to it and add that PV to existing VG.
>
> -- Pasi
I don't follow?
* make new disk file on dom0
* xm block-attach the disk file to domU
* the domU uses LVM based on the disk files
* make on both disks an LVM partition that has the same VolGroup? and
combining it linearly?
that would mean that adding a PV to the volgroup would make the / bigger?
enableing myself to use resize2fs on the domU directly?
so if i gather this, it would be the same if i added another device and used
raid linear mode as / ?
Sincerely,
Maarten
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home