Archives For HP-UX

If you need to get the licensing information from the Veritas products installed on an HP-UX just execute the vxlicrep command..

Additionally if you want to see what feature of Veritas Volume Manager are available you can do it with vxdctl license.

Juanma.

Like other virtualization software, HP Integrity Virtual Machines comes with several memory management capabilities. In this new post about HPVM I will try to explain what are these capabilities, their purpose and how to configure and use them.

  • Dynamic memory

Dynamic memory is an HPVM feature that allow you to resize the amount of memory of a guest without rebooting it. The HPVM manual mention an example in which dynamic memory is applicable.

…this feature allows a guest that is a Serviceguard node to be used as a standby server for multiple Serviceguard packages. When a package fails over to the guest, the guest memory can be changed to suit the requirements of the package before, during, and after the failover process.

Dynamic memory is only available on HP-UX guests with the guest management software installed.

Lets see how to enable an configure dynamic memory.

First thing to do is to enable dynamic memory.

root@hinata:~ # hpvmmodify -P batman -x ram_dyn_type=driver

There are three possible values for the ram_dyn_type option:

  1. None: Self explanatory.
  2. Any: In the next boot of the guest it will check if dynamic memory is enabled and if the driver is loaded. If the dynamic memory driver is in place the option will change its value to driver.
  3. Driver: When the ram_dyn_type is set to driver it means that every dynamic memory control and range is functional.

Specify the minimun amount of RAM to be allocated to the guest, the default unit is MB but GB can also be used.

root@hinata:~ # hpvmmodify -P batman -x ram_dyn_min=1024

Next set the maximum memory.

root@hinata:~ # hpvmmodify -P batman -x ram_dyn_max=4G

Set the amount of memory to be allocated when the guests starts, this value must be greater than the minimum one.

root@hinata:~ # hpvmmodify -P batman -x ram_dyn_target_start=2048

Check the status of the guest to see the newly configured options.

root@hinata:~ # hpvmstatus -r -P batman
[Virtual Machine entitlements]
 Percent       Cumulative
#VCPUs Entitlement Maximum   Usage            Usage
====== =========== ======= ======= ================
 6       10.0%  100.0%    0.0%                0 

[Virtual CPU details]
vCPU Cumulative       Guest   Host    Cycles   Sampling
ID   Usage            percent percent achieved Interval
==== ================ ======= ======= ======== ===========
 0                0    0.0%    0.0%     0MHz   0 seconds
 1                0    0.0%    0.0%     0MHz   0 seconds
 2                0    0.0%    0.0%     0MHz   0 seconds
 3                0    0.0%    0.0%     0MHz   0 seconds
 4                0    0.0%    0.0%     0MHz   0 seconds
 5                0    0.0%    0.0%     0MHz   0 seconds 

[Virtual Machine Memory Entitlement]
DynMem  Memory   DynMem  DynMem DynMem  Comfort Total    Free   Avail    Mem    AMR     AMR
 Min   Entitle   Max    Target Current   Min   Memory  Memory  Memory  Press  Chunk   State
======= ======= ======= ======= ======= ======= ======= ======= ======= ===== ======= ========
 1024MB     0MB     4GB  4096MB  4096MB     0MB     4GB     0MB     0MB   0       0MB DISABLED

Once dynamic memory is properly configured, from the VM host, the memory of a guest can be manually resized to a value between the ram_dyn_min and ram_dyn_max parameters in increments of the default chunk size, which is 64MB.

root@hinata:~ # hpvmmodify -P batman -x ram_target=3136

There is one final option named dynamic_memory_control, with this option the system administration can allow the root user of the guest to change dynamic memory options, from the guest side, while it is running. The dynamic_memory_control option is incompatible with automatic memory reallocation.

Just to show a small example from the guest side, to view the dynamic memory configuration:

root@batman:~# hpvmmgmt -V -l ram
[Dynamic Memory Information]
=======================================
Type                    : driver
Minimum memory          : 1024 MB
Target memory           : 4090 MB
Maximum memory          : 4096 MB
Current memory          : 4090 MB
Comfortable minimum     : 1850 MB
Boot memory             : 4090 MB
Free memory             : 2210 MB
Available memory        : 505 MB
Memory pressure         : 0
Memory chunksize        : 65536 KB
Driver Mode(s)          : STARTED ENABLED 

root@batman:~#
  • Automatic memory reallocation

The new HPVM 4.2 version from March expands dynamic memory with an interesting feature called Automatic Memory Reallocation. This new feature provides the possibility of automated changes in the amount of memory used by a guest based on load conditions.

Automatic memory reallocation is only supported on HP-UX guests with dynamic memory enabled and with the guest management software installed.

Automatic memory reallocation can be configured through two ways:

  1. System-wide values.
  2. On a per-VM basis.

Each way doesn’t exclude the other one, you can set the system-wide parameters for every VM and later customize some of the virtual machines adjusting their parameters to any additional requirement.

Automatic memory reallocation is enabled by default on the VM host. Open the file /etc/rc.config.d/hpvmconf and check that HPVMAMRENABLE=0 is not set to verify that automatic memory reallocation is enabled. The process hpmvmamrd, the automatic memory reallocation daemon, can also be check with a simple ps.

In the same file two system-wide tunables can be configured.

  1. HPVMCHUNKSIZE
  2. HPVMAMRWAITTIME

The first parameter determine the number of megabytes by the guest will attempt to grow if there is memory pressure. If the parameter is not set the default value will be 256MB. The best practice for this parameter is to be a multiple of the dynamic memory chunk size.

The second one set the maximum number of seconds that any VM startup process will wait for memory before reporting a failure due to insufficient memory. The default value is 60 seconds and the maximum configurable 600 seconds.

With the above parameter set to its defaults or customized the next step is to enable automatic memory reallocation in the virtual machines. The amr feature is DISABLED by default on the VMs. To enable use the amr_enable option.

root@hinata:~ # hpvmmodify -P batman -x amr_enable=1

Now set the memory entitlement for the virtual machine. The entitlement is the minimum amount of RAM guaranteed to the virtual machine.

root@hinata:~ # hpvmmodify -P batman -x ram_dyn_entitlement=1500

Take into account that if amr is not enabled the entitlement could be set but it will not work and any VM without the entitlement parameter set will be ignored by automatic memory reallocation.

The entitlement value can be modified online by the system administrator at any time, but there are some rules that apply:

  1. If there is not enough memory to grow the VM memory to the specified entitlement the operation will fail.
  2. The memory of virtual machine can not be grown beyond its maximum memory.
  3. The virtual machine memory always have to be set to a value between ram_dyn_max and ram_dyn_min parameters, no more no less.

When the memory of a guest is resized by default the HPVMCHUNKSIZE value is used but a per-VM chunk size can also be set. To do so use the amr_chunk_size parameter.

root@hinata:~ # hpvmmodify -P batman -x amr_chunk_resize=512

As in the system-wide parameter the recommendation is to set the chunk size to a multiple of the dynamic memory chunks size.

Finally to display the configuration and the current use of the virtual machines resource entitlements use hpvmstatus -r.

root@hinata:~ # hpvmstatus -r
[Virtual Machine Resource Entitlement]
[Virtual CPU entitlement]
 Percent       Cumulative
Virtual Machine Name VM #  #VCPUs Entitlement Maximum   Usage            Usage
==================== ===== ====== =========== ======= ======= ================
rh-www                   1      4       50.0%  100.0%    0.0%                0
sql-dev                  2      4       50.0%  100.0%    0.3%         21611866
rhino                    3      4       50.0%  100.0%    0.0%                0
batman                   4      8       20.0%  100.0%    0.8%          1318996
robin                    5      8       20.0%  100.0%    0.8%            97993
falcon                   6      2       10.0%  100.0%    0.0%                0 

[Virtual Machine Memory Entitlement]
 DynMem  Memory   DynMem  DynMem DynMem  Comfort Total    Free   Avail    Mem    AMR     AMR
Virtual Machine Name  VM #   Min   Entitle   Max    Target Current   Min   Memory  Memory  Memory  Press  Chunk   State
==================== ===== ======= ======= ======= ======= ======= ======= ======= ======= ======= ===== ======= ========
rh-www                   1   512MB     0MB     8GB  8192MB  8192MB     0MB     8GB     0MB     0MB   0       0MB DISABLED
sql-dev                  2   512MB     0MB     8GB  8192MB  8192MB     0MB     8GB     0MB     0MB   0       0MB DISABLED
rhino                    3  1024MB  1500MB     6GB  2048MB  6144MB     0MB     6GB     0MB     0MB   0     256MB  ENABLED
batman                   4  1024MB  1500MB     4GB  4090MB  4090MB  1850MB     4GB  2214MB   500MB   0     256MB  ENABLED
robin                    5  1024MB  1500MB     4GB  4090MB  4090MB  1914MB     4GB  2165MB   531MB   0     256MB  ENABLED
falcon                   6   512MB     0MB     6GB  6144MB  6144MB     0MB     6GB     0MB     0MB   0       0MB DISABLED

I hope this helps to clarify how HPVM manage the memory of the virtual machines and how to customize its configuration. As always any comment would be welcome :-)

Juanma.

Dynamic Root Diks, or DRD for short, is a nice and handy tool that IMHO every HP-UX Sysadmin must know. In an HPVM related post I showed how to use DRD to clone a virtual machine but today I will explain the purpose DRD was intended when it was first introduced… patching a server. I’m going to suppose you have an spare disk for the task and of course have DRD installed in the server.

1.- Clone the root disk.

root@sheldon:/ # drd clone -x overwrite=true -v -t /dev/disk/disk2

=======  04/21/10 09:05:53 EDT  BEGIN Clone System Image (user=root)  (jobid=sheldon-01)

* Reading Current System Information
* Selecting System Image To Clone
* Selecting Target Disk
* Selecting Volume Manager For New System Image
* Analyzing For System Image Cloning
* Creating New File Systems
* Copying File Systems To New System Image
* Making New System Image Bootable
* Unmounting New System Image Clone
* System image: "sysimage_001" on disk "/dev/disk/disk2"

=======  04/21/10 09:38:48 EDT  END Clone System Image succeeded. (user=root)  (jobid=sheldon-01)

root@sheldon:/ #

2.- Mount the image.

root@sheldon:/ # drd mount

=======  04/21/10 09:41:20 EDT  BEGIN Mount Inactive System Image (user=root)  (jobid=sheldon)

 * Checking for Valid Inactive System Image
 * Locating Inactive System Image
 * Mounting Inactive System Image

=======  04/21/10 09:41:31 EDT  END Mount Inactive System Image succeeded. (user=root)  (jobid=sheldon)

root@sheldon:/ #

Check the mount by displaying the drd00 volume group.

root@sheldon:/ # vgdisplay drd00

VG Name                     /dev/drd00
VG Write Access             read/write     
VG Status                   available                 
Max LV                      255    
Cur LV                      8      
Open LV                     8      
Max PV                      16     
Cur PV                      1      
Act PV                      1      
Max PE per PV               4356         
VGDA                        2   
PE Size (Mbytes)            32              
Total PE                    4346    
Alloc PE                    2062    
Free PE                     2284    
Total PVG                   0        
Total Spare PVs             0              
Total Spare PVs in use      0  

root@sheldon:/ #

3.- Apply the patches on the mounted clone.

root@sheldon:/ # drd runcmd swinstall -s /tmp/patches_01.depot

=======  04/21/10 09:42:55 EDT  BEGIN Executing Command On Inactive System Image (user=root)  (jobid=sheldon)

 * Checking for Valid Inactive System Image
 * Analyzing Command To Be Run On Inactive System Image
 * Locating Inactive System Image
 * Accessing Inactive System Image for Command Execution
 * Setting Up Environment For Command Execution
 * Executing Command On Inactive System Image
 * Using unsafe patch list version 20061206
 * Starting swagentd for drd runcmd
 * Executing command: "/usr/sbin/swinstall -s /tmp/patches_01.depot"

=======  04/21/10 09:42:59 EDT  BEGIN swinstall SESSION
 (non-interactive) (jobid=sheldon-0006) (drd session)

 * Session started for user "root@sheldon".

 * Beginning Selection

 ...
 ...
 ...

=======  04/21/10 09:44:37 EDT  END swinstall SESSION (non-interactive)
 (jobid=sheldon-0006) (drd session)

 * Command "/usr/sbin/swinstall -s /tmp/patches_01.depot" completed with the return
 code "0".
 * Stopping swagentd for drd runcmd
 * Cleaning Up After Command Execution On Inactive System Image

=======  04/21/10 09:44:38 EDT  END Executing Command On Inactive System Image succeeded. (user=root)  (jobid=sheldon)

root@sheldon:/ #

4.- Check the installed patches on the DRD image.

root@sheldon:/ # drd runcmd swlist patches_01

=======  04/21/10 09:45:29 EDT  BEGIN Executing Command On Inactive System Image (user=root)  (jobid=sheldon)

 * Checking for Valid Inactive System Image
 * Analyzing Command To Be Run On Inactive System Image
 * Locating Inactive System Image
 * Accessing Inactive System Image for Command Execution
 * Setting Up Environment For Command Execution
 * Executing Command On Inactive System Image
 * Executing command: "/usr/sbin/swlist patches_01"
# Initializing...
# Contacting target "sheldon"...
#
# Target:  sheldon:/
#

 # patches_01                    1.0            ACME Patching depot
   patches_01.acme-RUN
 * Command "/usr/sbin/swlist patches_01" completed with the return code "0".
 * Cleaning Up After Command Execution On Inactive System Image

=======  04/21/10 09:45:32 EDT  END Executing Command On Inactive System Image succeeded. (user=root)  (jobid=sheldon)

root@sheldon:/ #

5.- Activate the image and reboot the server.

At this point you only have to activate the patched image with the drd activate command and schedule a reboot of the server.

If you want to activate and reboot at the same time use the -x reboot=true option as in the example below.

root@sheldon:/ # drd activate -x reboot=true

=======  04/21/10 09:52:26 EDT  BEGIN Activate Inactive System Image
 (user=root)  (jobid=sheldon)

 * Checking for Valid Inactive System Image
 * Reading Current System Information
 * Locating Inactive System Image
 * Determining Bootpath Status
 * Primary bootpath : 0/1/1/0.0.0 [/dev/disk/disk1] before activate.
 * Primary bootpath : 0/1/1/0.1.0 [/dev/disk/disk2] after activate.
 * Alternate bootpath : 0 [unknown] before activate.
 * Alternate bootpath : 0 [unknown] after activate.
 * HA Alternate bootpath : <none> [] before activate.
 * HA Alternate bootpath : <none> [] after activate.
 * Activating Inactive System Image
 * Rebooting System

If everything goes well after the reboot give the patched server some time, I leave this to your own criteria, before restoring the mirror.

Juanma.

If you need to determine the version of a Veritas diskgroup it can be done by two ways:

  • vxdg command:

Execute vxdg list <diskgroup> and look for the version field in the output.

root@vmnode1:~# vxdg list dg_sap
Group:     dg_sap
dgid:      1273503890.14.vmnode1
import-id: 1024.10
flags:     cds
version:   140 <--- VERSION!
alignment: 8192 (bytes)
local-activation: read-write
ssb:            on
detach-policy: global
dg-fail-policy: dgdisable
copies:    nconfig=default nlog=default
config:    seqno=0.1076 permlen=24072 free=24068 templen=2 loglen=3648
config disk disk27 copy 1 len=24072 state=clean online
config disk disk28 copy 1 len=24072 state=clean online
log disk disk27 copy 1 len=3648
log disk disk28 copy 1 len=3648
root@vmnode1:~#
  • vxprint command:

Run vxprint -l <diskgroup> and again look for the versión field as shown in the example.

root@vmnode1:~# vxprint -l dg_sap
Disk group: dg_sap

Group:    dg_sap
info:     dgid=1273503890.14.vmnode1
version:  140 <--- VERSION!
alignment: 8192 (bytes)
activation: read-write
detach-policy: global
dg-fail-policy: dgdisable
copies:   nconfig=default nlog=default
devices:  max=32767 cur=1
minors:   >= 4000
cds=on

root@vmnode1:~#

And as Nelson Muntz like to say… smell you later ;-)

Juanma.

In today post I will show how to create and brake a mirrored volume in Veritas Volume Manager and Logical Volume Manager.

## LVM ##

Creating a mirror of a volume and later split it in LVM is quite easy an can be done with a few commands. I’m going to suppose that the original volume is already created.

  • Extend the Volume Group that contain the lvol.

It has to be done with the same number of disks and of the same size that the ones within the VG.

[root@sheldon] / # vgextend vg_oracle /dev/disk/disk26
Volume group "vg_oracle" has been successfully extended.
Volume Group configuration for /dev/vg_oracle has been saved in /etc/lvmconf/vg_oracle.conf
[root@sheldon] / #
  • Create the mirror.
[root@sheldon] / # lvextend -m 1 /dev/vg_oracle/lv_oracle /dev/disk/disk26
The newly allocated mirrors are now being synchronized. This operation will
take some time. Please wait ....
Logical volume "/dev/vg_oracle/lv_oracle" has been successfully extended.
Volume Group configuration for /dev/vg_oracle has been saved in /etc/lvmconf/vg_oracle.conf
[root@sheldon] / #
  • Check the configuration.
[root@sheldon] / # lvdisplay /dev/vg_oracle/lv_oracle
--- Logical volumes ---
LV Name                     /dev/vg_oracle/lv_oracle
VG Name                     /dev/vg_oracle
LV Permission               read/write                
LV Status                   available/syncd           
Mirror copies               1            
Consistency Recovery        MWC                 
Schedule                    parallel      
LV Size (Mbytes)            208             
Current LE                  13             
Allocated PE                26             
Stripes                     0       
Stripe Size (Kbytes)        0                   
Bad block                   NONE         
Allocation                  strict                    
IO Timeout (Seconds)        default             
Number of Snapshots         0  

[root@sheldon] / #
  • Perform the split.
[root@sheldon] / # lvsplit -s copy /dev/vg_oracle/lv_oracle
Logical volume "/dev/vg_oracle/lv_oraclecopy" has been successfully created with
character device "/dev/vg_oracle/rlv_oraclecopy".
Logical volume "/dev/vg_oracle/lv_oracle" has been successfully split.
Volume Group configuration for /dev/vg_oracle has been saved in /etc/lvmconf/vg_oracle.conf
[root@sheldon] / #
  • Reestablish the mirror.

If the VG are 1.0 or 2.0 version the merge can not be performed if the group is in shared mode, for the 2.1 volume groups the lvmerge can be done in any mode.

The order to do the merge is the copy FIRST and the master SECOND. This is very important if don’t want to sync the mirror in wrong direction.

[root@sheldon] / # lvmerge /dev/vg_oracle/lv_oraclecopy /dev/vg_oracle/lv_oracle
Logical volume "/dev/vg_oracle/lv_oraclecopy" has been successfully merged
with logical volume "/dev/vg_oracle/lv_oracle".
Logical volume "/dev/vg_oracle/lv_oraclecopy" has been successfully removed.
Volume Group configuration for /dev/vg_oracle has been saved in /etc/lvmconf/vg_oracle.conf
[root@sheldon] / #

## VXVM ##

The process in VxVM is in many ways similar to the LVM one.

  • Add a new disk/disks to the diskgroup

Launch vxdiskadm tool and select Add or initialize one or more disks.

[root@sheldon] / # vxdiskadm 

Volume Manager Support Operations
Menu: VolumeManager/Disk

 1      Add or initialize one or more disks
 2      Remove a disk
 3      Remove a disk for replacement
 4      Replace a failed or removed disk
 5      Mirror volumes on a disk
 6      Move volumes from a disk
 7      Enable access to (import) a disk group
 8      Remove access to (deport) a disk group
 9      Enable (online) a disk device
 10     Disable (offline) a disk device
 11     Mark a disk as a spare for a disk group
 12     Turn off the spare flag on a disk
 13     Remove (deport) and destroy a disk group
 14     Unrelocate subdisks back to a disk
 15     Exclude a disk from hot-relocation use
 16     Make a disk available for hot-relocation use
 17     Prevent multipathing/Suppress devices from VxVM's view
 18     Allow multipathing/Unsuppress devices from VxVM's view
 19     List currently suppressed/non-multipathed devices
 20     Change the disk naming scheme
 21     Change/Display the default disk layouts
 22     Mark a disk as allocator-reserved for a disk group
 23     Turn off the allocator-reserved flag on a disk
 list   List disk information

 ?      Display help about menu
 ??     Display help about the menuing system
 q      Exit from menus

Select an operation to perform:  1

Enter the disk and answer the questions according to your configuration and exit the tool when the process is done.

Add or initialize disks
Menu: VolumeManager/Disk/AddDisks

 Use this operation to add one or more disks to a disk group.  You can
 add the selected disks to an existing disk group or to a new disk group
 that will be created as a part of the operation. The selected disks may
 also be added to a disk group as spares. Or they may be added as
 nohotuses to be excluded from hot-relocation use. The selected
 disks may also be initialized without adding them to a disk group
 leaving the disks available for use as replacement disks.

 More than one disk or pattern may be entered at the prompt.  Here are
 some disk selection examples:

 all:          all disks
 c3 c4t2:      all disks on both controller 3 and controller 4, target 2
 c3t4d2:       a single disk (in the c#t#d# naming scheme)
 xyz_0:        a single disk (in the enclosure based naming scheme)
 xyz_:         all disks on the enclosure whose name is xyz

 disk#:        a single disk (in the new naming scheme)

Select disk devices to add: [<pattern-list>,all,list,q,?]  disk28
Here is the disk selected.  Output format: [Device_Name]

 disk28

Continue operation? [y,n,q,?] (default: y)  

 You can choose to add this disk to an existing disk group, a
 new disk group, or leave the disk available for use by future
 add or replacement operations.  To create a new disk group,
 select a disk group name that does not yet exist.  To leave
 the disk available for future use, specify a disk group name
 of "none".

Which disk group [<group>,none,list,q,?] (default: none)  dg_sap

Use a default disk name for the disk? [y,n,q,?] (default: y)  n

Add disk as a spare disk for dg_sap? [y,n,q,?] (default: n)  

Exclude disk from hot-relocation use? [y,n,q,?] (default: n)  

Add site tag to disk? [y,n,q,?] (default: n)  

 The selected disks will be added to the disk group dg_sap with
 disk names that you will specify interactively.

 disk28

Continue with operation? [y,n,q,?] (default: y)  

 Initializing device disk28.

Enter desired private region length
[<privlen>,q,?] (default: 32768)  

Enter disk name for disk28 [<name>,q,?] (default: dg_sap02)  

 VxVM  NOTICE V-5-2-88
Adding disk device disk28 to disk group dg_sap with disk
 name dg_sap02.

Add or initialize other disks? [y,n,q,?] (default: n)
  • Check the configuration.
[root@sheldon] / # vxprint -g dg_sap
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg dg_sap       dg_sap       -        -        -        -        -       -

dm dg_sap01     disk27       -        228224   -        -        -       -
dm dg_sap02     disk28       -        228224   -        -        -       -

v  sapvol       fsgen        ENABLED  204800   -        ACTIVE   -       -
pl sapvol-01    sapvol       ENABLED  204800   -        ACTIVE   -       -
sd dg_sap01-01  sapvol-01    ENABLED  204800   0        -        -       -
[root@sheldon] / #
  • Create the mirror.
[root@sheldon] / # vxassist -g dg_sap mirror sapvol dg_sap02
[root@sheldon] / #
[root@sheldon] / # vxprint -g dg_sap                        
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg dg_sap       dg_sap       -        -        -        -        -       -

dm dg_sap01     disk27       -        228224   -        -        -       -
dm dg_sap02     disk28       -        228224   -        -        -       -

v  sapvol       fsgen        ENABLED  204800   -        ACTIVE   -       -
pl sapvol-01    sapvol       ENABLED  204800   -        ACTIVE   -       -
sd dg_sap01-01  sapvol-01    ENABLED  204800   0        -        -       -
pl sapvol-02    sapvol       ENABLED  204800   -        ACTIVE   -       -
sd dg_sap02-01  sapvol-02    ENABLED  204800   0        -        -       -
[root@sheldon] / #
  • Break the mirror.

To do this just disassociate the corresponding plex from the volume.

[root@sheldon] / # vxplex -g dg_sap dis sapvol-02
[root@sheldon] / # vxprint -g dg_sap             
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg dg_sap       dg_sap       -        -        -        -        -       -

dm dg_sap01     disk27       -        228224   -        -        -       -
dm dg_sap02     disk28       -        228224   -        -        -       -

pl sapvol-02    -            DISABLED 204800   -        -        -       -
sd dg_sap02-01  sapvol-02    ENABLED  204800   0        -        -       -

v  sapvol       fsgen        ENABLED  204800   -        ACTIVE   -       -
pl sapvol-01    sapvol       ENABLED  204800   -        ACTIVE   -       -
sd dg_sap01-01  sapvol-01    ENABLED  204800   0        -        -       -
[root@sheldon] / #
  • Reattach the plex to the volume and reestablish the mirror.
[root@sheldon] / # vxplex -g dg_sap att sapvol sapvol-02

And we are done for now, more VxVM stuff in a future post :-)

Juanma.

DISCLAIMER NOTE: This method is based only on my personal experience working with HP-UX 11iv2, 11iv3 and EMC Symmetrix. I tested it with near a hundred LUNs from a DMX-3 and with six different servers. As far as I know this isn’t an official or supported procedure neither from EMC nor from HP.

Every time the storage people add a new LUN to your servers from an EMC disk array they provide you with a Logical device ID (or LUN ID) to identify the disk with PowerPath. If you are in HP-UX 11iv2 no problem here, just run a simple powermt command and look for the new LUN.

[root@totoro] / # powermt display dev=all | more
...
...
Symmetrix ID=000281150123
Logical device ID=0CED
state=alive; policy=SymmOpt; priority=0; queued-IOs=0
==============================================================================
---------------- Host ---------------   - Stor -   -- I/O Path -  -- Stats ---
###  HW Path                I/O Paths    Interf.   Mode    State  Q-IOs Errors
==============================================================================
20 0/0/10/1/0.11.15.0.0.1.3 c7t1d3 SP A0 active alive 0 1
23 0/0/10/1/0.11.47.0.0.1.3 c8t1d3 SP B0 active alive 0 1
26 1/0/8/1/0.21.15.0.0.1.3 c10t1d3 SP A1 active alive 0 1
29 1/0/8/1/0.21.47.0.0.1.3 c11t1d3 SP B1 active alive 0 1
...
...

But if you are in 11.31 you will find a small problem to perform this. PowerPath is not recommended in HP-UX 11iv3 because it can cause conflicts with the new native multipathing of the v3.

You can use the trick of doing a simple ll -tr in the /dev/disk directory just after the hardware scan and the device file creation, but this way is valid only if you have one or two disks with the same size. What if you have several disks with multiple sizes and want to use each disk for a different VG and/or task? The storage people will only provide the LUN IDs but you will not have the tool to match those IDs with your disks.

Fortunately there is way to circumvent the lack of PowerPath in 11iv3. We are going to use the same disk as in the previous example, the 0CED.

First get the disks serial number with scsimgr.

[root@totoro] / # scsimgr get_attr -D /dev/rdisk/disk30 -a serial_number

 SCSI ATTRIBUTES FOR LUN : /dev/rdisk/disk30

name = serial_number
current = "100123CED000"
default =
saved =

Take note of the serial number.

100123CED000

As you can see the last the last three digits of the LUN ID are included in the disk serial number and if look carefully will see also the four last digits the Symmetrix ID (0123) just after the LUN ID.

Juanma.

PowerPath is a multipathing software for Unix operating systems from EMC. If you have ever worked or you are going to work in an environment that includes EMC storage systems it is more than sure that Powerpath will be installed in the Unix hosts.

Following are some notes and tips I’ve been creating since the very first time I found Powerpath, of course this isn’t a full user guide but a sort of personal quick reference. I decide to put it here in the hope that it will be helpful to anyone and for my personal use.

  • Show powermt command version
[root@totoro] / # powermt version
EMC powermt for PowerPath (c) Version 5.1.0 (build 160)
  • Display PowerPath configuration.
[root@totoro] / # powermt display
Symmetrix logical device count=898
CLARiiON logical device count=0
Hitachi logical device count=0
Invista logical device count=0
HP xp logical device count=0
Ess logical device count=0
HP HSx logical device count=0
==============================================================================
----- Host Bus Adapters ---------  ------ I/O Paths -----  ------ Stats ------
###  HW Path                       Summary   Total   Dead  IO/Sec Q-IOs Errors
==============================================================================
 5 0/2/1/0.101.16.19.0           optimal      61      0       -     0      0
 6 0/2/1/0.101.16.19.1           optimal     102      0       -     0      0
 7 0/2/1/0.101.16.19.2           optimal      97      0       -     0      0
 8 0/2/1/0.101.16.19.3           optimal     113      0       -     0      0
 9 0/2/1/0.101.16.19.4           optimal      82      0       -     0      0
 11 0/2/1/0.101.43.19.0           optimal     128      0       -     0      0
 12 0/2/1/0.101.43.19.1           optimal      49      0       -     0      0
 13 0/2/1/0.101.43.19.2           optimal      57      0       -     0      0
 14 0/2/1/0.101.43.19.3           optimal      83      0       -     0      0
 15 0/2/1/0.101.43.19.4           optimal      74      0       -     0      0
 16 0/2/1/0.101.43.19.5           optimal      33      0       -     0      0
 17 0/2/1/0.101.43.19.6           optimal      19      0       -     0      0
 19 0/5/1/0.102.16.19.0           optimal      61      0       -     0      0
 20 0/5/1/0.102.16.19.1           optimal     102      0       -     0      0
 21 0/5/1/0.102.16.19.2           optimal      97      0       -     0      0
 22 0/5/1/0.102.16.19.3           optimal     113      0       -     0      0
 23 0/5/1/0.102.16.19.4           optimal      82      0       -     0      0
 25 0/5/1/0.102.43.19.0           optimal     128      0       -     0      0
 26 0/5/1/0.102.43.19.1           optimal      49      0       -     0      0
 27 0/5/1/0.102.43.19.2           optimal      57      0       -     0      0
 28 0/5/1/0.102.43.19.3           optimal      83      0       -     0      0
 29 0/5/1/0.102.43.19.4           optimal      74      0       -     0      0
 30 0/5/1/0.102.43.19.5           optimal      33      0       -     0      0
 31 0/5/1/0.102.43.19.6           optimal      19      0       -     0      0

[root@totoro] / #
  • Check for death paths and remove them.
[root@sheldon] / # powermt display
Symmetrix logical device count=34
CLARiiON logical device count=0
Hitachi logical device count=0
Invista logical device count=0
HP xp logical device count=0
Ess logical device count=0
HP HSx logical device count=0
==============================================================================
----- Host Bus Adapters ---------  ------ I/O Paths -----  ------ Stats ------
###  HW Path                       Summary   Total   Dead  IO/Sec Q-IOs Errors
==============================================================================
 17 UNKNOWN                       failed        1      1       -     0      0
 31 UNKNOWN                       failed        1      1       -     0      0
 37 1/0/14/1/0.109.85.19.0        optimal      32      0       -     0      0
 39 0/0/14/1/0.110.85.19.0        optimal      32      0       -     0      0

[root@sheldon] / # powermt check
Warning: Symmetrix device path c17t9d6 is currently dead.
Do you want to remove it (y/n/a/q)? y
Warning: Symmetrix device path c31t9d6 is currently dead.
Do you want to remove it (y/n/a/q)? y
[root@sheldon] / #
  • List all devices.
[root@totoro] / # powermt display dev=all
  • Remove all devices.
[root@totoro] / # powermt remove dev=all
  • Add a new disk in HP-UX, configure it and save the config:

After a rescan of the disks with ioscan and the creation of the device files with insf run the following command  to add the new disk to PowerPath

[root@totoro] / # powermt config

Now display all the devices and look the for the Logical device ID of the disk.

[root@totoro] / # powermt display dev=all | more
...
...
Symmetrix ID=000287750035
Logical device ID=0004
state=alive; policy=SymmOpt; priority=0; queued-IOs=0
==============================================================================
---------------- Host ---------------   - Stor -   -- I/O Path -  -- Stats ---
###  HW Path                I/O Paths    Interf.   Mode    State  Q-IOs Errors
==============================================================================
20 0/0/10/1/0.11.15.0.0.1.3 c20t1d3 SP A0 active alive 0 1
23 0/0/10/1/0.11.47.0.0.1.3 c23t1d3 SP B0 active alive 0 1
26 1/0/8/1/0.21.15.0.0.1.3 c26t1d3 SP A1 active alive 0 1
29 1/0/8/1/0.21.47.0.0.1.3 c29t1d3 SP B1 active alive 0 1
...
...

If everything went fine save the config.

[root@totoro] / # powermt save

And these are the most common tasks I’ve been doing with PowerPath. I’ll try to put some order into my notes and personal how-to files and write more posts like this one.

Juanma.

I was playing this afternoon with DRD in an 11.23 machine and just after launching the clone process I decided to stop it with Ctrl-c since I wasn’t logging the session and I wanted to do it. The process stopped with an error and I was sent back to the shell.

       * Copying File Systems To New System Image
ERROR:   Exiting due to keyboard interrupt.
       * Unmounting New System Image Clone
       * System image: "sysimage_001" on disk "/dev/dsk/c2t1d0"
ERROR:   Caught signal SIGINT.  This process is running critical code, this signal will be handled shortly.
ERROR:   Caught signal SIGINT.  This process is running critical code, this signal will be handled shortly.
ERROR:   Caught signal SIGINT.  This process is running critical code, this signal will be handled shortly.
ERROR:   Caught signal SIGINT.  This process is running critical code, this signal will be handled shortly.
ERROR:   Unmounting the file system fails.
         - Unmounting the clone image fails.
         - The "umount" command returned  "13". The "sync" command returned  "0". The error messages produced are the following: ""
       * Unmounting New System Image Clone failed with 5 errors.
       * Copying File Systems To New System Image failed with 6 errors.
=======  04/21/10 08:20:19 EDT  END Clone System Image failed with 6 errors. (user=root)  (jobid=ivm-v2)

I know it is a very bad idea but it’s not production server, just a virtual machine I use to perform tests. In fact my stupid behaviour gave me the opportunity to discover and play with a funny and pretty bunch of errors. Here it is how I manage to  resolve it.

I launched again the clone process in preview mode, just in case, and DRD fails with the following error.

[ivm-v2]/ # drd clone -p -v -t /dev/dsk/c2t1d0

=======  04/21/10 08:22:01 EDT  BEGIN Clone System Image Preview (user=root)  (jobid=ivm-v2)

        * Reading Current System Information
        * Selecting System Image To Clone
        * Selecting Target Disk
 ERROR:   Selection of the target disk fails.
          - Selecting the target disk fails.
          - Validation of the disk "/dev/dsk/c2t1d0" fails with the following error(s):
          - Target volume group device entry "/dev/drd00" exists. Run "drd umount" before proceeding.
        * Selecting Target Disk failed with 1 error.

=======  04/21/10 08:22:10 EDT  END Clone System Image Preview failed with 1 error. (user=root)  (jobid=ivm-v2)

It seems that the original process just leaved the image mounted but after trying with drd umount just like the DRD output said it didn’t worked. The image was only partially created, yeah I created a beautiful mess ;-)

At that point, and in another “clever” movement, instead of simply removing the drd00 volume group I just deleted /dev/drd00… who’s da man!! or like we use to say in Spain ¡Con dos cojones!

DRD, of course, failed with a new error.

ERROR:   Selection of the target disk fails.
         - Selecting the target disk fails.
         - Validation of the disk "/dev/dsk/c2t1d0" fails with the following error(s):
         - Target volume group "/dev/drd00" found in logical volume table. "/etc/lvmtab" is corrupt and must be fixed before proceeding.
       * Selecting Target Disk failed with 1 error.

Well it wasn’t so bad. I recreated /etc/lvmtab and yes… I fired up my friend Dynamic Root Disk in preview mode.

[ivm-v2]/ # rm -f /etc/lvmtab
[ivm-v2]/ # vgscan -v
Creating "/etc/lvmtab".
vgscan: Couldn't access the list of physical volumes for volume group "/dev/vg00".
Invalid argument
Physical Volume "/dev/dsk/c3t2d0" contains no LVM information

/dev/vg00
/dev/dsk/c2t0d0s2

Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c2t1d0s2

Scan of Physical Volumes Complete.
*** LVMTAB has been created successfully.
*** Do the following to resync the information on the disk.
*** #1.  vgchange -a y
*** #2.  lvlnboot -R
[ivm-v2]/ # lvlnboot -R
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
[ivm-v2]/ #
[ivm-v2]/ # drd clone -p -v -t /dev/dsk/c2t1d0

=======  04/21/10 08:26:06 EDT  BEGIN Clone System Image Preview (user=root)  (jobid=ivm-v2)

       * Reading Current System Information
       * Selecting System Image To Clone
       * Selecting Target Disk
ERROR:   Selection of the target disk fails.
         - Selecting the target disk fails.
         - Validation of the disk "/dev/dsk/c2t1d0" fails with the following error(s):
         - The disk "/dev/dsk/c2t1d0" contains data. To overwrite this disk use the option "-x overwrite=true".
       * Selecting Target Disk failed with 1 error.

=======  04/21/10 08:26:13 EDT  END Clone System Image Preview failed with 1 error. (user=root)  (jobid=ivm-v2)

I couldn’t believe that. Another error? Why in the hell I got involved with DRD? But I am an Sysadmin, and a stubborn one. Looked at the disk and discovered that it had been partitioned by the first failed DRD cloning process. I just wiped out the whole disk with idisk and just in case I used the overwrite option.

[ivm-v2]/ # idisk -p /dev/rdsk/c2t1d0
idisk version: 1.31

EFI Primary Header:
        Signature                 = EFI PART
        Revision                  = 0x10000
        HeaderSize                = 0x5c
        HeaderCRC32               = 0xe19d8a07
        MyLbaLo                   = 0x1
        AlternateLbaLo            = 0x1117732f
        FirstUsableLbaLo          = 0x22
        LastUsableLbaLo           = 0x1117730c
        Disk GUID                 = d79b52fa-4d43-11df-8001-d6217b60e588
        PartitionEntryLbaLo       = 0x2
        NumberOfPartitionEntries  = 0xc
        SizeOfPartitionEntry      = 0x80
        PartitionEntryArrayCRC32  = 0xca7e53ce

  Primary Partition Table (in 512 byte blocks):
    Partition 1 (EFI):
        Partition Type GUID       = c12a7328-f81f-11d2-ba4b-00a0c93ec93b
        Unique Partition GUID     = d79b550c-4d43-11df-8002-d6217b60e588
        Starting Lba              = 0x22
        Ending Lba                = 0xfa021
    Partition 2 (HP-UX):
        Partition Type GUID       = 75894c1e-3aeb-11d3-b7c1-7b03a0000000
        Unique Partition GUID     = d79b5534-4d43-11df-8003-d6217b60e588
        Starting Lba              = 0xfa022
        Ending Lba                = 0x110af021
    Partition 3 (HPSP):
        Partition Type GUID       = e2a1e728-32e3-11d6-a682-7b03a0000000
        Unique Partition GUID     = d79b5552-4d43-11df-8004-d6217b60e588
        Starting Lba              = 0x110af022
        Ending Lba                = 0x11177021

[ivm-v2]/ #
[ivm-v2]/ # idisk -R /dev/rdsk/c2t1d0
idisk version: 1.31
********************** WARNING ***********************
If you continue you will destroy all partition data on this disk.
Do you wish to continue(yes/no)? yes

Don’t know why but I was pretty sure that DRD was going to fail again… and it did.

=======  04/21/10 08:27:02 EDT  BEGIN Clone System Image Preview (user=root)  (jobid=ivm-v2)

       * Reading Current System Information
       * Selecting System Image To Clone
       * Selecting Target Disk
       * The disk "/dev/dsk/c2t1d0" contains data which will be overwritten.
       * Selecting Volume Manager For New System Image
       * Analyzing For System Image Cloning
ERROR:   Analysis of file system creation fails.
         - Analysis of target fails.
         - The analysis step for creation of an inactive system image failed.
         - The default DRD mount point "/var/opt/drd/mnts/sysimage_001/" cannot be used due to the following error(s):
         - The mount point /var/opt/drd/mnts/sysimage_001/ is not an empty directory as required.
       * Analyzing For System Image Cloning failed with 1 error.

=======  04/21/10 08:27:09 EDT  END Clone System Image Preview failed with 1 error. (user=root)  (jobid=ivm-v2)

After a quick check I found that the original image was mounted.

[ivm-v2]/ # mount
/ on /dev/vg00/lvol3 ioerror=mwdisable,delaylog,dev=40000003 on Wed Apr 21 07:29:37 2010
/stand on /dev/vg00/lvol1 ioerror=mwdisable,log,tranflush,dev=40000001 on Wed Apr 21 07:29:38 2010
/var on /dev/vg00/lvol8 ioerror=mwdisable,delaylog,dev=40000008 on Wed Apr 21 07:29:50 2010
/usr on /dev/vg00/lvol7 ioerror=mwdisable,delaylog,dev=40000007 on Wed Apr 21 07:29:50 2010
/tmp on /dev/vg00/lvol4 ioerror=mwdisable,delaylog,dev=40000004 on Wed Apr 21 07:29:50 2010
/opt on /dev/vg00/lvol6 ioerror=mwdisable,delaylog,dev=40000006 on Wed Apr 21 07:29:50 2010
/home on /dev/vg00/lvol5 ioerror=mwdisable,delaylog,dev=40000005 on Wed Apr 21 07:29:50 2010
/net on -hosts ignore,indirect,nosuid,soft,nobrowse,dev=1 on Wed Apr 21 07:30:26 2010
/var/opt/drd/mnts/sysimage_001 on /dev/drd00/lvol3 ioerror=nodisable,delaylog,dev=40010003 on Wed Apr 21 08:19:46 2010
/var/opt/drd/mnts/sysimage_001/stand on /dev/drd00/lvol1 ioerror=nodisable,delaylog,dev=40010001 on Wed Apr 21 08:19:46 2010
/var/opt/drd/mnts/sysimage_001/tmp on /dev/drd00/lvol4 ioerror=nodisable,delaylog,dev=40010004 on Wed Apr 21 08:19:46 2010
/var/opt/drd/mnts/sysimage_001/home on /dev/drd00/lvol5 ioerror=nodisable,delaylog,dev=40010005 on Wed Apr 21 08:19:46 2010
/var/opt/drd/mnts/sysimage_001/opt on /dev/drd00/lvol6 ioerror=nodisable,delaylog,dev=40010006 on Wed Apr 21 08:19:46 2010
/var/opt/drd/mnts/sysimage_001/usr on /dev/drd00/lvol7 ioerror=nodisable,delaylog,dev=40010007 on Wed Apr 21 08:19:46 2010
/var/opt/drd/mnts/sysimage_001/var on /dev/drd00/lvol8 ioerror=nodisable,delaylog,dev=40010008 on Wed Apr 21 08:19:47 2010
[ivm-v2]/ #

Had to unmount the filesystems of the image one by one and after almost committing suicide with a rack rail I launched the clone again and without the preview, if I were going to play a stupid role at least it was going to the most stupid one in the world x-)

[ivm-v2]/ # drd clone -x overwrite=true -v -t /dev/dsk/c2t1d0

=======  04/21/10 08:38:22 EDT  BEGIN Clone System Image (user=root)  (jobid=rx260-02)

       * Reading Current System Information
       * Selecting System Image To Clone
       * Selecting Target Disk
       * The disk "/dev/dsk/c2t1d0" contains data which will be overwritten.
       * Selecting Volume Manager For New System Image
       * Analyzing For System Image Cloning
       * Creating New File Systems
ERROR:   Clone file system creation fails.
         - Creating the target file systems fails.
         - Command "/opt/drd/lbin/drdconfigure" fails with the return code 255. The entire output from the command is given below:
         - Start of output from /opt/drd/lbin/drdconfigure:
         -        * Creating LVM physical volume "/dev/rdsk/c2t1d0s2" (0/1/1/0.1.0).
                  * Creating volume group "drd00".
           ERROR:   Command "/sbin/vgcreate -A n -e 4356 -l 255 -p 16 -s 32 /dev/drd00
                    /dev/dsk/c2t1d0s2" failed.

         - End of output from /opt/drd/lbin/drdconfigure
       * Creating New File Systems failed with 1 error.
       * Unmounting New System Image Clone
       * System image: "sysimage_001" on disk "/dev/dsk/c2t1d0"

=======  04/21/10 08:38:46 EDT  END Clone System Image failed with 1 error. (user=root)  (jobid=rx260-02)

[ivm-v2]/ #

I thought that every possible error was fixed but there it was DRD saying that it failed with a bogus return code 255, oh yes very insightful because it’s not a 254 or a 256 it is a 255 code and everybody know what it means… Shit! I don’t know what it means. Yes it was true, I didn’t know what “return code 255″ stood for. After doing a small search on ITRC there was only one entry about a similar case, only one. I manage to create a beautiful error, don’t you think?

The question is that there was a mismatch between the minor numbers the kernel believed were in use and those really visible in the device files. DRD will always try to use the next free based on the device files and since in my case there was only one in use but the kernel thought there were two in use, one from vg00 and another one from the failed clone, it failed.

The solution is to cheat the kernel creating a fake group device using the minor number the kernel thinks is in use.

[ivm-v2]/dev # mkdir fake
[ivm-v2]/dev # cd fake
[ivm-v2]/dev/fake # mknod group c 64 0x010000
[ivm-v2]/dev/fake #

After that I launched DRD and everything went smoothly.

Fortunately everything happened in a test virtual machine and at any step of my frustrating trip through self-generated DRD error I could reset the VM and start over again with a clean system but since the purpose of Dynamic Root Disk is to minimize the downtime of production systems the reboot was not an option, at least no the first in the list.

The credit for the solution goes to Judit Wathen from the Dynamic Root Disk Team at HP, continue with your great work :-D

Juanma.

[ivm-v2]/ # idisk -p /dev/rdsl k/c2t1d0

idisk version: 1.31

EFI Primary Header:

Signature                 = EFI PART

Revision                  = 0×10000

HeaderSize                = 0x5c

HeaderCRC32               = 0xe19d8a07

MyLbaLo                   = 0×1

AlternateLbaLo            = 0x1117732f

FirstUsableLbaLo          = 0×22

LastUsableLbaLo           = 0x1117730c

Disk GUID                 = d79b52fa-4d43-11df-8001-d6217b60e588

PartitionEntryLbaLo       = 0×2

NumberOfPartitionEntries  = 0xc

SizeOfPartitionEntry      = 0×80

PartitionEntryArrayCRC32  = 0xca7e53ce

Primary Partition Table (in 512 byte blocks):

Partition 1 (EFI):

Partition Type GUID       = c12a7328-f81f-11d2-ba4b-00a0c93ec93b

Unique Partition GUID     = d79b550c-4d43-11df-8002-d6217b60e588

Starting Lba              = 0×22

Ending Lba                = 0xfa021

Partition 2 (HP-UX):

Partition Type GUID       = 75894c1e-3aeb-11d3-b7c1-7b03a0000000

Unique Partition GUID     = d79b5534-4d43-11df-8003-d6217b60e588

Starting Lba              = 0xfa022

Ending Lba                = 0x110af021

Partition 3 (HPSP):

Partition Type GUID       = e2a1e728-32e3-11d6-a682-7b03a0000000

Unique Partition GUID     = d79b5552-4d43-11df-8004-d6217b60e588

Starting Lba              = 0x110af022

Ending Lba                = 0×11177021

[ivm-v2]/ #

[ivm-v2]/ # idisk -R /dev/rdsk/c2t1d0

idisk version: 1.31

********************** WARNING ***********************

If you continue you will destroy all partition data on this disk.

Do you wish to continue(yes/no)? yes

Last month HP released the last update of HP-UX 11iv3, the Update 6 or the March 2010 Update or 11.36… I decided some time ago to do not try to understand why we have a so stupid naming scheme for HP-UX.

Anyway, putting aside the philosophical rambling, HP-UX 11iv3 update 6 is here and it came full of new features. The following ones stand out, at least for me.

  • Improved system boot time thanks to RCEnhancement, Oliver wrote about it several weeks ago, until this release it was available in the Software Depot and now is included in the install media.
  • New DRD version capable of synchronize the clone with the running system.
  • LVM updated to version 2.2. With this version we have logical volume snapshots, can’t wait to try this :-D, logical volume migration within the same VG through the new lvmove command and boot support for LVM 2.2 volume groups, this is very cool because until this release the vg00 was stuck in LVM 1.0. Ignite-UX have also been updated to take advantage of this feature and we’ll be asked to choose between LVM 1.0 and LVM 2.2 bootable volume groups.

This release comes bundled with the new HPVM version, the 4.2, which also adds a bunch of new features. To name a few.

  • Automatic memory reallocation.
  • Capacity of suspend and resume a guest.
  • Support for CVM/CFS backing stores for HPVM Serviceguard cluster packages.
  • Encryption of the data during Online VM migration.
  • AVIO support for Veritas Volume Manager based backing stores.

In short, there are a lot of new interesting features, a lot issues have also been fixed and as I said at the beginning we still have to live with an odd naming scheme but in the end I’m quite happy with this new release at least in theory because I didn’t have the opportunity to try it yet but I will do very soon since I’m planning to deploy HPVM 4.2 in the near future. In fact my HPVM 3.5 to 4.1 migration project has become a 3.5 to 4.2 migration, how cool is that eh! ;-)

Juanma.

As I already said many times my current HPVM version is 3.5 so it doesn’t support guest online migration. But lacking the online migration feature doesn’t mean that we can not perform Integrity VM migration between hosts.

Currently there are two methods to perform migrations:

  • HPVM commands.
  • MC/ServiceGuard.

In this post I will only cover the HPVM way. I will leave HPVM ServiceGuard clusters for a future post but as many of you already know moving a guest between cluster nodes is like moving any other ServiceGuard package since the guests are managed by SG as packages.

PREREQUISITES:

There is a certain list of prerequisites the guest has to met in order to be successfully migrated between hosts.

  • Off-line state:

This is pretty obvious of course, the guest must be off.

  • SSH configuration:

In both hosts root must have SSH access through public key authentication to the other.

root@ivmcl01:~ # hpvmmigrate -P hpvm1 -h ivmcl02
hpvmmigrate: SSH execution error. Make sure ssh is setup right on both source and target systems.
  • Shared devices:

If the guest has a shared device like the CD/DVD of the host, the device has to be deleted from the guest configuration.

root@ivmcl01:~ # hpvmmigrate -P hpvm1 -h ivmcl02
hpvmmigrate: Device /dev/rdsk/c1t4d0 is shared.  Guest with shared storage devices cannot be migrated.
  • Storage devices:

There are two consideration about storage devices.

The storage devices of the guest must be physical disks. Migration of guests with lvols as storage devices is supported only in HPVM 4.1 release.

root@ivmcl01:~ # hpvmmigrate -P hpvm1 -h ivmcl02
hpvmmigrate: Target VM Host error - Device does not exist.
hpvmmigrate: See HPVM command log file on target VM Host for more detail.

The WWID of the device must be the same in both HPVM hosts.

root@ivmcl01:~ # hpvmmigrate -P hpvm1 -h ivmcl02
hpvmmigrate: Device WWID does not match.
hpvmmigrate: See HPVM command log file on target VM Host for more detail.
  • Network configuration:

The virtual switch where the guest is connected to must be configured on the same network card in both hosts. For example if vswitch vlan2 is using lan0 in host1 must be using lan0 in host2 or the migration will fail.

root@ivmcl01:~ # hpvmmigrate -P hpvm1 -h ivmcl02
hpvmmigrate: Target VM Host error - vswitch validation failed.
hpvmmigrate: See HPVM command log file on target VM Host for more detail.

PROCEDURE:

If all the prerequisites explained before are met by our guest we can proceed with the migration. The command to use is hpvmmigrate, the name or the VM number and the hostname of the destination server have to be provided. Some of the resources of the virtual machines like number of CPU, amount of RAM or the machine label can also be modified.

root@ivmcl01:~ # hpvmmigrate -P hpvm1 -h ivmcl02
hpvmmigrate: Guest migrated successfully.
root@ivmcl01:~ #

Check the existence of the migrated guest in the destination host.

root@ivmcl02:~ # hpvmstatus
[Virtual Machines]
Virtual Machine Name VM #  OS Type State     #VCPUs #Devs #Nets Memory  Runsysid
==================== ===== ======= ========= ====== ===== ===== ======= ========
oratest01                1 HPUX    On (OS)        4    10     3   16 GB        0
oratest02                2 HPUX    On (OS)        4     8     3   16 GB        0
sapvm01                  3 HPUX    Off            3     8     3    8 GB        0
sapvm02                  4 HPUX    Off            3     7     3    8 GB        0
sles01                   5 LINUX   On (OS)        1     4     3    4 GB        0
rhel01                   6 LINUX   Off            1     4     3    4 GB        0
hp-vxvm                  7 HPUX    On (OS)        2    17     3    6 GB        0
ws2003                   8 WINDOWS Off            4     4     3   12 GB        0
hpvm1                   10 HPUX    Off            1     1     1    3 GB        0
root@ivmcl02:~ #

As you can see once all the prerequisites have been met the migration is quite easy.

CONCLUSION:

Even with the disadvantage of lacking online migration the guest migration feature can be of usefulness to balance the load between HPVM hosts.

Juanma.