Benutzer-Werkzeuge

Webseiten-Werkzeuge


it:virtual:xenserver:luns_erweitern

XenServer LUNs erweitern

Notes: The following configuration was employed on XenServer 5.6, but should be relevant to XenServer 5.6 Sp2 as well.
The solution has not been rigorously tested and is not supported by Citrix.
This article does not go into detail on how to use the Linux command line. Please refer to Linux documentation for further information if necessary.

Before increasing the LUN size, it’s a good idea to gather some information to determine how the system currently sees the LUN.

First, we’ll get the status of the multipath driver.
Note that the last element of the colon separated numbers is the LUN number as identified by the storage array.
When there are multiple LUNs, using the ID is a good way to narrow down the devices you care about.

[root@scaley ~|RootScaley]# mpathutil status
36001f9300177800002cb000200000000 dm-0  XIOTECH,ISE1400
[size=100G][features=0       ][hwhandler=0        ][rw        ]
\_ round-robin 0 [prio=4][enabled]
 \_ 4:0:1:1 sde 8:64  [active][ready]
 \_ 5:0:0:1 sdd 8:48  [active][ready]
 \_ 4:0:0:1 sdc 8:32  [active][ready]
 \_ 5:0:1:1 sdb 8:16  [active][ready]

The important information from this output that we’ll need later is the SCSI ID of the LUN, in this case, 36001f9300177800002cb000200000000.
Next, we’ll take a look at how the SCSI layer views the multiple devices that make up the separate paths to the LUN.
Note that you’ll use the devices found in the previous output, in this case “bcde”.
Also note that the “3>&1 2>&3″ is just some CLI magic to eliminate stderr from the output that we pass to grep.
You can omit it if you’d like.

[root@scaley ~|RootScaley]# fdisk -l /dev/sd[bcde] 3>&1 2>&3 | grep GB
Disk /dev/sdb: 107.3 GB, 107374182400 bytes
Disk /dev/sdc: 107.3 GB, 107374182400 bytes
Disk /dev/sdd: 107.3 GB, 107374182400 bytes
Disk /dev/sde: 107.3 GB, 107374182400 bytes

Next we’ll find the UUID of the storage repository (SR) that we’re expanding:

[root@scaley ~|RootScaley]# xe sr-list name-label=ResizeMe
uuid ( RO)                : 172b7166-5fb7-fc63-75d9-cd3275129751
          name-label ( RW): ResizeMe
    name-description ( RW): Hardware HBA SR [XIOTECH - /dev/sdd [sde] [sdb] [sdc]]
                host ( RO): scaley
                type ( RO): lvmohba
        content-type ( RO):

Using the UUID of the SR (172b7166-5fb7-fc63-75d9-cd3275129751),
now we’ll take a look at how the logical volume manager (LVM) is seeing the LUN:

[root@scaley ~|RootScaley]# pvs | grep 172b7166-5fb7-fc63-75d9-cd3275129751
  /dev/mapper/36001f9300177800002cb000200000000 VG_XenStorage-172b7166-5fb7-fc63-75d9-cd3275129751 lvm2 a-   99.99G 99.98G

Note that LVM is using a physical volume (PV) size of 99.99G from this output.
Now, increase the LUN size at the storage array. In the example here I’ve resized a 100GB LUN to 150GB.
Note that the process below APPEARS to work with VMs running on the SR.
To be completely safe it’s recommended that you shutdown the VMs that are using the SR prior to executing the commands.
Increasing the size of the LUN on the array does not change how XenServer sees/uses the LUN automatically.
Now we’ll need to have the HBAs scan the array to find the resized LUN.
Note that this process is done differently for each HBA manufacturer.
The command below is used with Emulex HBAs.

[root@scaley ~|RootScaley]# /usr/sbin/lpfc/lun_scan -r
Searching for :
  1. Target LUNs to resize on scsi host number : 4
Searching for :
  1. Target LUNs to resize on scsi host number : 5

If using QLogic HBAs I believe you can use

/usr/bin/rescan-scsi-bus.sh 

to accomplish the same thing, but have not been able to validate, or

echo 1 > /sys/block/sdb/device/rescan
echo 1 > /sys/block/sdc/device/rescan
echo 1 > /sys/block/sdd/device/rescan
echo 1 > /sys/block/sde/device/rescan

After the rescan the SCSI subsystem now recognizes the change:

[root@scaley ~|RootScaley]# fdisk -l /dev/sd[bcde] 3>&1 2>&3 | grep GB
Disk /dev/sdb: 161.0 GB, 161061273600 bytes
Disk /dev/sdc: 161.0 GB, 161061273600 bytes
Disk /dev/sdd: 161.0 GB, 161061273600 bytes
Disk /dev/sde: 161.0 GB, 161061273600 bytes

But the multipath subsystem doesn’t yet know about the change:

[root@scaley ~|RootScaley]# mpathutil status
36001f9300177800002ca000200000000 dm-0  XIOTECH,ISE1400
[size=100G][features=0      ][hwhandler=0       ][rw       ]
\_ round-robin 0 [prio=4][enabled]
 \_ 4:0:1:1 sde 8:64  [active][ready]
 \_ 5:0:0:1 sdd 8:48  [active][ready]
 \_ 4:0:0:1 sdb 8:16  [active][ready]
 \_ 5:0:1:1 sdc 8:32  [active][ready]

To get the multipath subsystem to recognize the change we have to tell it to resize the LUN.
Using the SCSI ID found in the mpathutil output (36001f9300177800002cb000200000000), run the following command:

[root@scaley ~|RootScaley]# multipathd -k"resize map 36001f9300177800002cb000200000000"
ok

or

/etc/init.d/multipathd reload

Now note that the multipath subsystem has become aware of the change and now reflects the 150GB LUN.

[root@scaley ~|RootScaley]# mpathutil status
36001f9300177800002cb000200000000 dm-0  XIOTECH,ISE1400
[size=150G][features=0      ][hwhandler=0       ][rw       ]
\_ round-robin 0 [prio=4][enabled]
 \_ 4:0:1:1 sde 8:64  [active][ready]
 \_ 5:0:0:1 sdd 8:48  [active][ready]
 \_ 4:0:0:1 sdc 8:32  [active][ready]
 \_ 5:0:1:1 sdb 8:16  [active][ready]

Now looking at the LVM subsystem, we find that it is still unaware of the change.

[root@scaley ~|RootScaley]# pvs | grep 172b7166-5fb7-fc63-75d9-cd3275129751
  /dev/mapper/36001f9300177800002cb000200000000 VG_XenStorage-172b7166-5fb7-fc63-75d9-cd3275129751 lvm2 a-   99.99G 99.98G

Using the device found in the previous pvs output (/dev/mapper/36001f9300177800002cb000200000000)
we’ll now expand the PV to use the new LUN size:

[root@scaley ~|RootScaley]# pvresize /dev/mapper/36001f9300177800002cb000200000000
  Physical volume "/dev/mapper/36001f9300177800002cb000200000000" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

And the change is reflected by reissuing the pvs command:

[root@scaley ~|RootScaley]# pvs | grep 172b7166-5fb7-fc63-75d9-cd3275129751
  /dev/mapper/36001f9300177800002cb000200000000 VG_XenStorage-172b7166-5fb7-fc63-75d9-cd3275129751 lvm2 a-   149.99G 149.98G

Finally, if you look at the General tab of the SR in XenCenter you’ll find that the XenServer management stack still hasn’t recognized the change. To make it aware we need to rescan the SR using the UUID we found earlier in the process:

[root@scaley ~|RootScaley]# xe sr-scan uuid=172b7166-5fb7-fc63-75d9-cd3275129751

Now you should have all subsystems and XenCenter reflecting the updated LUN size.

Quelle: http://blogs.citrix.com/2011/03/07/live-lun-resize-on-xenserver/

~~UP~~

it/virtual/xenserver/luns_erweitern.txt · Zuletzt geändert: 2019/05/14 21:16 von 127.0.0.1