Environment
Novell Open Enterprise Server 2 (OES 2) Linux
Novell SUSE Linux Enterprise Server 10 Support Pack 2
Novell SUSE Linux Enterprise Server 10 Support Pack 1
Novell SUSE Linux Enterprise Server 10 Support Pack 2
Novell SUSE Linux Enterprise Server 10 Support Pack 1
Situation
Common:
NSS Related:
- 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
- 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
- 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
- When EVMS is loaded, device-mapper multipath is unable to some or all DM-MPIO devices
- PowerPath does not see the devices as multipathed
Resolution
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
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
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:
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
title SUSE Linux Enterprise 10 SP2
root (hd0,0)
kernel /vmlinuz root=/dev/evms/lvm2/system/sys vga=0x317 splash=silent showopts
initrd /initrd
after (change in bold)root (hd0,0)
kernel /vmlinuz root=/dev/evms/lvm2/system/sys vga=0x317 splash=silent showopts
initrd /initrd
title SUSE Linux Enterprise 10 SP2
root (hd0,0)
kernel /vmlinuz root=/dev/evms/lvm2/system/sys emvs=disk vga=0x317 splash=silent showopts
initrd /initrd
root (hd0,0)
kernel /vmlinuz root=/dev/evms/lvm2/system/sys emvs=disk vga=0x317 splash=silent showopts
initrd /initrd
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
- Export the VMxm list -l OES2 > oes.2.py
- Open the exported configuration for editing
- Locate the following(linux
(kernel )
(args ' ')
(rtc_timeoffset 0)
(localtime 1)
(device_model /usr/lib/xen/bin/qemu-dm)
(notes - 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 - Save the file
- Test starting the DomU with the new parameterxm create -F oes2.py
- If the test is sucessful, shutdown the DomU
- Reimport the DomU configuration with the changexm new -F oes2.py
- Start the DomU normally
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:
- Go to /etc/xen/vm
- Find the plain text configuration file for the DomU
- Start the DomU using with xm commands Replace the "OES2" with the name of the file in step 2xm create OES2 extra=" evms=disk "
- Create the NSS pool
- If successful, shut down the DomU and continue on to permanent fix for para-virtual xen machines
- Open the configuration file, typically found in /etc/xen/vm
- Find the line reading "extra="extra=""
- Add "evms=disk"extra="evms=disk"
- Save the file
- Start the VM normally