Port-xen archive

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

Re: extending LVM logical volumes for Xen root partitions is NOT so simple!

woods%planix.ca@localhost ("Greg A. Woods") writes:

>Basically I had doubled the size, and now it seems none of superblocks
>fsck wants to read can be read (from the domU).

Just changing the size of the LVM doesn't change the partitioning or
the filesystem layout.

>The disklabel (on disk, as seen from the dom0) is as follows:
>	16 partitions:
>	#        size    offset     fstype [fsize bsize cpg/sgs]
>	 a:  20971520         0     4.2BSD   2048 16384     0  # (Cyl.      0 -  10239)
>	 c:  20971520         0     unused      0     0        # (Cyl.      0 -  10239)
>	 d:  20971520         0     unused      0     0        # (Cyl.      0 -  10239)

>As you can see it is at 10GB, while the new logical volume is at 21GB:

The total size of the disk doesn't matter, that's always ignored by the kernel.
But the partition 'a' size (and also 'c' for x86) of course stays. But that's
correct as nothing else has changed.

>Given the current and normally low rate of change on my system's root
>filesystem (it has a separate /var, etc.), and the fact it fscks fine
>from the dom0,

That's a dangerous thing, even when not counting the fake geometry used
by the Xen driver.

Ideally you'd need to access the LVM volume as a paritioned disk,
but vnd doesn't support block devices yet. Just assuming things work
because everything is aligned at offset 0 causes such problems.

On a regular disk you wouldn't fsck the raw partition even when
the filesystem partition starts at offset 0.

>My instinct is to just replace the label with a block of zeros (after
>making a backup of it in the dom0 of course).  However I'm unsure if
>any tools might be assuming a root disklabel exists (e.g. does sysinst
>make use of it for an upgrade?).

You can use disklabel -D to destroy the label. The system will then
use a fictious label again.

>Ideally I would like to see the OS handle all these issues automatically
>somehow, though it wouldn't be the end of the world if there were
>another step required to resize a root filesystem.

It's no more different than changing a real disk.

>However if another step is going to always be needed then it should not
>require the admin to calculate or even copy any value to facilitate it.
>I.e. one should not have to copy the value for the new size into the
>disklabel manually

Changing a disk size doesn't resize a partition or even resize a filesystem.
After all, you could want to use that space for another partition.

Now if you think there could be a tool for Xen servers that makes such
things easy, I all agree.

                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."

Home | Main Index | Thread Index | Old Index