Consider the following guidelines when planning to use NSS in a virtual environment:
NSS pools and volumes are not supported on the Xen host server in a Xen-based virtualized environment. You can install NSS on the guest servers from inside the guest server environment, just as you would if the guest servers were physical servers.
When you create a virtual machine, you must assign devices to it. If you plan to use the virtualization guest server as a node in a cluster and you need to be able to fail over cluster resources to differnt physical servers, you must assign SAN-based physical devices to the virtual machine. You create the NSS pools and volumes from within the guest server.
If you install Novell Cluster Services in the host server environment, the cluster resources use shared Linux POSIX volumes, and do not use shared NSS pools.
If you install Novell Cluster Services in the guest server environment, the guest server is a node in the cluster. The disk sharing is managed by Novell Cluster Services from within the guest server environment. You can use shared NSS pools as cluster resources that run on the guest server and on other nodes in that cluster.
For information about deployment scenarios using clustered NSS pools in clusters in a virtual environment, see Configuring Novell Cluster Services in a Virtualized Environment
in the OES 2: Novell Cluster Services 1.8.4 for Linux Administration Guide.
In a Xen virtual environment, if you need to use RAIDs for device fault tolerance in a high-availability solution, use hardware RAIDs. In this release, controller RAIDs and software RAIDs are not supported on the host or guest environments.
If a storage device has multiple connection paths between the device and the host server, use Linux multipathing to resolve the paths into a single multipath device. When assigning the device to a VM, select the device by its multipath device node name (/dev/mapper/mpathN). The guest server operating system is not aware of the underlying multipath management being done on the host. The device appears to the guest server as any other physical block storage device. For information, see Managing Multipath I/O for Devices
in the SLES 10 Storage Administration Guide.
If the vendor of the storage subsystem provides its own multipath management software, you can use it instead. In this case, the host is not aware that the device is multipathed, and you can handle the device normally.
Do not use multipath management tools in the guest environment.
For best performance in a Xen virtual environment, NSS pools and volumes on NetWare should be created on virtual devices that are SCSI devices, Fiber Channel devices, or iSCSI devices on the host server, or partitions on those types of devices.
SATA or IDE disks have slower performance because special handling is required when working through the Xen driver to ensure data writes are committed to the disk in the order intended before it reports back.
In a Xen virtual environment, do not use a file-backed disk image for a virtual device where you plan to use the NSS file system. This applies to Linux and NetWare.
WARNING:Data corruption can occur if you use Xen file-backed disk images for NSS volumes on the guest server.
Unless otherwise indicated, the issues in this section apply to both OES 2 Linux and NetWare, and to NetWare 6.5 SP7.
The primary virtual disk (the first disk you assign to the virtual machine) is automatically recognized when you install the guest operating system. The other virtual devices must be initialized before any space is shown as available for creating a pool. Without initializing the devices, no space is shown available for pool creation. For information, see Section 4.3, Initializing New Virtual Disks on the Guest Server.
Write barriers are needed for controlling I/O behavior when writing to SATA and ATA/IDE devices and disk images via the Xen I/O drivers from a guest NetWare server. This is not an issue when NetWare is handling the I/O directly on a physical server.
The XenBlk Barriers parameter for the SET command controls the behavior of XenBlk Disk I/O when NetWare is running in a virtual environment. The setting appears in the Disk category when you issue the SET command in the NetWare server console.
Valid settings for the XenBlk Barriers parameter are integer values from 0 to 255, with a default value of 16. A non-zero value specifies the depth of the driver queue, and also controls how often a write barrier is inserted into the I/O stream. A value of 0 turns off XenBlk Barriers.
A value of 0 (no barriers) is the best setting to use when the virtual disks assigned to the guest server’s virtual machine are based on physical SCSI, Fibre Channel, or iSCSI disks (or partitions on those physical disk types) on the host server. In this configuration, disk I/O is handled so that data is not exposed to corruption in the event of power failure or host crash, so the XenBlk Barriers are not needed. If the write barriers are set to zero, disk I/O performance is noticeably improved.
Other disk types such as SATA and ATA/IDE can leave disk I/O exposed to corruption in the event of power failure or a host crash, and should use a non-zero setting for the XenBlk Barriers parameter. Non-zero settings should also be used for XenBlk Barriers when writing to Xen LVM-backed disk images and Xen file-backed disk images, regardless of the physical disk type used to store the disk images.
In the server console on the guest NetWare server, enter
SET XenBlkBarriers=value
For example, to turn off XenBlk Barriers for virtual disks based on physical SCSI, Fibre Channel, and iSCSI disks, enter
SET XenBlkBarriers=0
Table 4-1 identifies NSS features that are not supported in a Xen guest server environment: