EVMS: After updating, odd behavior seen on systems with EVMS volumes, disks or multipath devices

Common:

• At least one volume, disk or partition IS managaged by EVMS
• EVMS is loaded by the INITRD.
  

NSS Related:

• Error 21705, "insufficient free extends" when attempting to create a new NSS pool
• Error 21705, "insufficient free extends" when attempting to expand or restripe an existing NSS pool
• NSS volumes and/or pools are inaccessible
  

LVM managed by EVMS related:

• On the volume group where root is, can be seen; other volume groups may not be seen or are inaccessible
  
• "lvscan" shows inactive volume groups which cannot be activated
  

Traditional partition problems:

• Unable to mount /dev kernel named devices
• logical volumes are mounted but traditional partitions are not able to be mounted
• Mount error stating that the device is in use when attempting to access traditional partitions
  

Multipath issues:

• When EVMS is loaded, device-mapper multipath is unable to some or all DM-MPIO devices
• PowerPath does not see the devices as multipathed

If, after updating, you have any problems accessing EVMS volumes, devices with EVMS volumes on them, or traditional volumes when EVMS is running on the system this document should be considered.

This Document addresses this problem for physical, fully virtual (i.e Xen, VMware, Hyper-V) and para-virtual kernels (Xen only)

background

The EVMS disk management system has two policies. The first being disk, and the second being partition. Normally the mkinitrd should detect and set the policy. However, it has been observed that the policy is not always set.

physical and fully virtual machines

change the evms policy via kernel parameter for physical and fully virtual machines
To test whether the policy is the issue, simply boot with the "evms=disk" kernel parameter. Attempt to create the pool. If successful, continue on to the permanent fix.

permanent fix for physical and fully virtual machines
If booting with the "evms=disk" parameter, you can add it to /boot/grub/menu.lst.  Below is an example.

before

after (change in bold)


para-virtual xen virtual machines
The procedure described below only applies to Xen para-virtual DomU's.

Xen para-virtual machines do not boot using Grub. As such, kernel parameters must be passed to the DomU loader or included in the initrd. There are two methods for making the changes required.

method 1: managed domains (default)
Managed Domains are DomU's that are started and stopped through Virt-Manager or YaST. If you are unsure, then you most likely using managed domains.

Replace "OES2" with the name of the virtual machine

1. Export the VM
   xm list -l OES2 > oes.2.py
   
2. Open the exported configuration for editing
   
3. Locate the following
      (linux
         (kernel )
            (args ' ')
            (rtc_timeoffset 0)
            (localtime 1)
            (device_model /usr/lib/xen/bin/qemu-dm)
            (notes
   
4. Add "evms=disk" within the args line
      (linux
         (kernel )
            (args ' evms=disk')
            (rtc_timeoffset 0)
            (localtime 1)
            (device_model /usr/lib/xen/bin/qemu-dm)
            (notes
   
5. Save the file
   
6. Test starting the DomU with the new parameter
   xm create -F oes2.py
   
7. If the test is sucessful, shutdown the DomU
8. Reimport the DomU configuration with the change
   xm new -F oes2.py
   
9. Start the DomU normally

method 2: unmanaged domains
Unmanaged domains are started and stopped using the configuration file created when the domain was first installed. Those using a cluster solution or where the DomU is migrated between physical hosts will need to use this option

To test whether the policy is an issue for Xen paravirtual machines, the following steps need to be made:

1. Go to /etc/xen/vm
2. Find the plain text configuration file for the DomU
3. Start the DomU using with xm commands Replace the "OES2" with the name of the file in step 2
   xm create OES2 extra=" evms=disk "
4. Create the NSS pool
5. If successful, shut down the DomU and continue on to permanent fix for para-virtual xen machines

Permanent implementation:

1. Open the configuration file, typically found in /etc/xen/vm
2. Find the line reading "extra="
   extra=""
   
3. Add "evms=disk"
   extra="evms=disk"
4. Save the file
5. Start the VM normally