Extending a local Xenserver storage repository can be a bit daunting, especially when dealing with GPT Partition tables, which for example Xenserver 6.0 uses by default.
 

Preflight Check

  • First of all, you will need to provide Xenserver with actual, additional storage space. If you are using lets say a HP Proliant Server with a RAID configuration, add some more disks, and use the ACU (Array controller Utility) to extend the array with the new disks. Or use any other tool your Storage provides to extend the space.
     

  • Only perform the steps in this article, if you have a good backup of your host, your vms and your pool metadata. While these commands should be perfectly safe to use, in rare cases, data loss could occur.

    >>> hint: xe host-backup; xe pool-dump-database

  • Shutdown all Virtual machines that reside on the local storage. While I’m not sure it matters, I would advice it. 

  • To find out whether you are having an installation with a GPT Partition table, run this command in the Xenservers local console:

    fdisk -l /dev/sda

    If you see an error like this in the output, skip this section and check the GPT section:

    WARNING: GPT (GUID Partition Table) detected on ‘/dev/sda’! The util fdisk doesn’t support GPT. Use GNU Parted.

    This command will also show you, whether the Dom0 can actually see the extended space as the command should also give out the total size of the device, like this:

    Disk /dev/sda: 899.8 GB, 899898718208 bytes

    If you do not see the full extended size here, check that the storage extend has actually worked and completed, reboot your Xenserver and check again.

 

Enough talk, lets get to the interesting part.

Here is how you can extend when using ext filesystem:

Head over to the console of your xenserver (if in a pool, preferably use the masters console)

type the following commands:

xe sr-list

the output looks something like this:

uuid ( RO) : e42bd27e-53f2-c2d1-bd2a-f0bb9c391a0e
name-label ( RW): Removable storage
name-description ( RW):
host ( RO): XEN1
type ( RO): udev
content-type ( RO): disk

 

uuid ( RO) : 8b17697e-0329-be9d-404d-3f739350826b
name-label ( RW): Local storage
name-description ( RW):
host ( RO): XEN1
type ( RO): lvm
content-type ( RO): user

 

copy the uuid of the storage with the name-label of “Local storage” (in this example, it would be 8b17697e-0329-be9d-404d-3f739350826b)

type the command:

pvscan | grep “<the uuid you noted in the previous step>“

(e.g. pvscan | grep 8b17697e-0329-be9d-404d-3f739350826b)

The output looks like this:

PV /dev/sda3 VG VG_XenStorage-8b17697e-0329-be9d-404d-3f739350826b lvm2 [ 550.7 GB / 3.0 MiB free]

copy the device name (eg: /dev/sd3 )

run this command:

echo 1 > /sys/block/<the device name you copied from the previous step>/device/rescan

(e.g. echo 1 > /sys/block/sda3/device/rescan)

run this command:

pvresize <the device name from the previous step again>

(e.g. pvresize /dev/sda3)

run:

xe sr-scan uuid=<storage uuid you copied in the first step>

(e.g. xe sr-scan uuid=8b17697e-0329-be9d-404d-3f739350826b)

Now go back to the Xencenter and check whether the storage is indeed seeing the free space. You might have to also hit “rescan” in the storage tab on the local storage in Xencenter for it to reflect the changes.

If it does not work, give your Xenserver a reboot just for good measure, and check again.

Also, the steps outlined in this article might be working for you:

http://support.citrix.com/article/CTX120865

 

If all that fails, chances are, you are using a GPT Partition table on your storage. This makes things a bit more complicated and can lead to possible data loss.

Note that under normal conditions, running these commands will indeed PRESERVER your data.
Make sure you actually followed the pre-flight check to see if you are using a GPT partition or not.

Lets dig in:

use this to check for the partition details of you device:

sgdisk -p /dev/sda

The output would look something like this:
 

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1757614684 sectors, 838.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 030E4CA7-CFCF-42BD-96C1-446C242450C4
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1171743802
Partitions will be aligned on 2048-sector boundaries
Total free space is 6042 sectors (3.0 MiB)
 

Number Start (sector) End (sector) Size Code Name
1 2048 8388641 4.0 GiB 0700
2 8390656 16777249 4.0 GiB 0700
3 16779264 1171743802 550.7 GiB 8E00

 

Here you can see that currently, the last usable sector is: 1171743802
While here, also note the Start sector of the partition to extend, in this example: 16779264

Also, you will see that the free space is not reflecting the extended space.

To rectify this, we have to force the GPT Partition to extend to the last sector of the disk.

We use gdisk to do that.

Type this:

gdisk /dev/sda

type the letter x and hit enter, then type the letter e and hit enter again. type the letter w and confirm using the letter y, again hit enter

This will now expand the Partition up to the end of the disk device.

we now run the command from the previous step again

sgdisk -p /dev/sda

The output should now have changed:

Disk /dev/sda: 1757614684 sectors, 838.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 030E4CA7-CFCF-42BD-96C1-446C242450C4
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is
1757614650
Partitions will be aligned on 2048-sector boundaries
Total free space is 6042 sectors (3.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 8388641 4.0 GiB 0700
2 8390656 16777249 4.0 GiB 0700
3 16779264 1757614650 830.1 GiB 0700 Linux/Windows data

 

Note that before, the last usable sector was 1171743802, and now is 1757614650

This confirms, the partition table was indeed expanded.
 

That was only half the rent though, we now need to delete the actual partition and recreate it using its startsector and the last usable sector as the end sector.

Note that under normal conditions, running these commands will indeed PRESERVER your data.
Make sure you actually followed the pre-flight check to see if you are using a GPT partition or not.

remember that device name we wrote down earlier? In this example, it was /dev/sda3 (and usually is the default on the Xenserver)

We now use the command:

gdisk /dev/sda

Then enter the letter d and hit enter, enter the number 3 (corresponds to the device id (/dev/sda3) and hit enter.

type the letter n and hit enter, type the number 3 and hit enter, paste the Start sector number (from the previous step, in this example: 16779264), hit enter, paste the End Sector number (from previous step, in this example: 1757614650)

If the proposed default value of the start sector is off by only very little, you can simply confirm all the defaults, as the utility will automatically realign the partition and reflect the correct value)

Confirm the default for the next step about the HEX code by hitting enter. and finish the wizard. After that, type the letter w to actually apply the changes.

After this done, a reboot of the Xenserver will usually be enough to make Xenserver realize it has more space. If after the reboot, you can still not see the storage in Xencenter, simply rescan the storage using Xencenter, and you should be golden.

If you can not reboot the host, try running the command

xe-toolstack-restart and see if that worked. Haven’t tried this myself, but think this could also work instead of a restart.

Good Luck everyone!