It is important to plan your storage configuration in advance of deploying virtual infrastructure. Here are some guidelines to keep in mind:
Take care when adding, removing, and resizing LUNs as it may require a physical server reboot. Do not resize LUNs that are used as part of Logical disks; instead, create a new LUN and add it to the disk group.
If you resize a physical disk directly on the SAN server, you must refresh the physical disk within Oracle VM Manager to ensure that it is aware of the change and is capable of correctly determining the available disk space when performing other operations like creating a repository.
Avoid remapping LUNs as this can cause data corruption since the targets have been switched outside of the server. The Linux SCSI layer does not support dynamic remapping of LUNs from the storage array.
Test your configuration, especially fail over, in a test environment before rolling into production. You may need to make changes to the multipath configuration files of Oracle VM Server.
Plan the size and type of storage that you are using by workload. For example:
Boot volumes can typically be on higher capacity drives as most operating systems have minimal I/O activity on the boot disk, but some of that I/O is memory paging, which is sensitive to response times.
Applications can be on larger, slower drives (for example, RAID 5) unless they perform a lot of I/O. Write-intensive workloads should use RAID 10 on medium to fast drives. Ensure that log files are on different physical drives than the data they are protecting.
Infrastructure servers such as DNS tend to have low I/O needs. These servers can have larger, slower drives.
If using storage server features such as cloning and snapshots, use raw disks.
While it may be tempting to create a very large LUN when using logical disks, this can be detrimental to performance as each virtual machine queues I/Os to the same disks. You should size your repositories based on a thorough assessment of your requirements and then keep them to a size that is close to your exact requirements. Sizing of a repository should be based on a sum of the following values:
The total amount of disk space required for all running virtual machines. For instance if you have 6 virtual machines sized at 12 GB, you should ensure that the repository has at least 72 GB of available disk space.
The total amount of disk space required to provision each virtual machine with a local virtual disk. Consider that for 6 virtual machines, each with a 36 GB local virtual disk, you must have at least 216 GB of disk space available to your repository.
The total amount of disk space required to store any templates that you might use to deploy new guest images.
The total amount of disk space required to store ISO images for operating systems that may get installed to new guest images.
The total amount of disk space that you may require in reserve to deploy an additional number of virtual machines with local virtual disks in the future. As a rule of thumb, assume that you may need to deploy an additional virtual machine for each running virtual machine, so if you intend to initially run 6 virtual machines, you may find it sensible to size your repository for 12 virtual machines
Be sure to leave some disk space available to create smaller storage entities of, at least, 12 GB each to use as server pool file systems. The server pool file system is used to hold the server pool and cluster data, and is also used for cluster heartbeating. You create space for server pool file systems the same way as you create storage entities for storage repositories. For more information about the use and management of clusters and server pools, see Chapter 6, Understanding Server Pools and Oracle VM Servers and Servers and VMs Tab in the Oracle VM Manager User's Guide.
Place server pool file systems on a separate NFS server or use a small LUN, if possible. The cluster heartbeating function can be disturbed by I/O-intensive operations on the same physical storage. For example, importing a template or cloning a virtual machine in a storage repository on the same NFS server where the server pool file system resides may cause a time-out in the heartbeat communication, which in turn leads to server fencing and reboot. To avoid unwanted rebooting, it is recommended that you choose a server pool file system location with sufficient and stable I/O bandwidth.
Disable read and write caching on the underlying disk systems to guarantee I/O synchronization. Caching may result in data loss if the Oracle VM Server or a virtual machine fails abruptly. To disable write caching, change the applicable settings in the RAID controller BIOS. Alternatively, use the sg_wr_mode command or use the SCSI disk class directly: echo "write through" > /sys/class/scsi_disk/
scsi-device-id/cache_type.
When creating exports on a file server, if you choose to restrict access to a particular set of hosts, then all exports on the file server must have an identical list of permitted hosts in the export list. In Oracle VM Manager all of the hosts that have been permitted access must be added to the file server's list of Admin Servers. See Discover File Server in the Oracle VM Manager User's Guide for more information on adding Admin Servers to your file server in Oracle VM Manager.