This chapter is from the book
This chapter is from the book
This chapter is from the book
Virtual Disk
Just like a traditional hard drive, the virtual disk contains the OS, applications, and data. A VM’s virtual disk is represented by a vmdk file or by an RDM volume.
VMDKs
The vmdks are the most important files because they are the VM’s virtual disks, so they must be protected and secured. In vSphere 5, the vmdk’s maximum size is 2 TB (more precisely, 2 TB minus 512 bytes). Two files make up a virtual disk: a descriptor bearing the extension .vmdk, and a file containing data, using the extension –flat.vmdk, which you can see in the command-line interface (see Figure 3.10) or in the graphical user interface (see Figure 3.11).
)
Figure 3.10. Command-line interface showing the vmdk files.
)
Figure 3.11. vCenter’s GUI showing a single vmdk file, the same size as the virtual disk.
- The vmdk file corresponds to a metadata file, which is the virtual disk’s description (editable file in some support maintenance needs). This file provides the link to the –flat.vmdk file and contains information regarding the UUID. (See the section “Re-Signature of a VMFS Volume as Part of a DRP,” earlier in this chapter.)
- The -flat.vmdk file corresponds to the virtual disk with its content.
Disk Types
When a VM is created, the following disk types can be used: thick disk (lazy zeroed or eager zeroed) or thin disk, depending on the option you select, as shown in Figure 3.12. Table 3.2 compares the advantages of these disk types.
Table 3.2. Disk Types and Their Respective Advantages
|
Advantage |
When to Use |
Zeroed thick |
Creation is faster, but performance is lower for the first writes. |
Standard when creating a VM. |
Eager zeroed thick |
Longer to create, but performance is better during the first writes. |
Cloning a VM or deploying a VM from a template uses this mode. |
Thin |
Very rapidly created, but write performance is not as good as in other modes. |
The NFS datastore uses this mode by default. |
)
Figure 3.12. Optional disk types.
Thick Disks
Thick disks are easier to administer because, after they are provisioned, verifying the space available for the VM is no longer required. However, this means additional costs because the disk space is not optimized. This type of disk supports the Fault Tolerance (FT) feature.
With a thick disk, the size of the vmdk file is equal to the size of the disk configured when creating the VM.
Thick disks have two formats:
- Lazy zeroed (also called zeroed): This is the default format. All disk space is allocated, but the data previously written at disk level is not deleted. Existing data in the storage space is not deleted but remains on the physical disk. Erasing data and zeroing out blocks (formatting) is done only when first writing on the disk, which somewhat deteriorates performance. This performance degradation is greatly reduced by the VAAI feature Block Zero (utilizing the SCSI command write same).
- Eager zeroed: All disk space is reserved; data is entirely deleted from the disk, and blocks are zeroed out (formatted) when the disk is created. Creating such a disk takes longer, but security is improved because previous data is removed and deleted. Compared with zeroed thick, it offers much better performance when writing on the disk.
The thick disk format is recommended for applications that require high levels of performance. A simple way to use this mode is to select Support Clustering Features Such As Fault Tolerance when configuring VM disks.
It is always faster to create a new VM than to create one from a clone or to deploy a template.
Thin Disks
Some studies show that 40% to 60% of disk space is allocated but never used. In cases where the thin disk option (called thin provisioning) is used, the reserved space on VMFS equals the space actually used on the disk. The size of this space increases dynamically so that storage space is optimized.
In thin mode, performance is inferior because the space is allocated dynamically upon request and disk blocks must be zeroed out. Thin disks are useful for avoiding wasted storage space, but they require particular care and supervision to ensure that there is no shortage of storage space. The Out of Space API allows proactive monitoring and alerting to prevent this situation.
You can convert a disk from thin to thick by using either of the following methods:
- Use the Inflate option in the Datastore Browser.
- Use Storage vMotion to change the disk type to thick, as shown in Figure 3.13.
)
Figure 3.13. Using Storage VMotion interface to change disk type.
Modes
There are three modes for virtual disks, as follows:
- Independent persistent: All disk writes by the VM are actually written on disk (in the vmdk file). Even after rebooting, the modifications are preserved. This mode offers the best performance.
- Independent nonpersistent: All changes made since the VM was started up are destroyed when it is shut down. Modifications are written in a file that logs all changes at the VM’s file system level. In this mode, rebooting the VM means going back to a reference VM. Performance is not as good.
- Snapshot: This enables the return to a previous state.
Raw Device Mapping
Using the Raw Device Mapping (RDM) format, raw storage volumes can be introduced to ESX servers. This mode is mainly used in the following situations:
- When a Microsoft Cluster (MSCS or Windows Server Failover Clustering under Windows 2008 Server) is used (the only supported mode)
- When array-based snapshots are taken
- When introducing volumes directly to VMs for high performance (database-type)
- When introducing big SAN volumes to a VM (from 300 TB), avoiding the long P2V volume conversion to vmdk
RDM takes the form of a file (a kind of pointer) stored in a VMFS datastore that acts as a proxy for the LUN volume.
Figure 3.14 illustrates the difference between vmdk and RDM.
)
Figure 3.14. vmdk versus RDM format.
The RDM format exists in two modes: RDMv (virtual compatibility mode) and RDMp (physical compatibility mode).
RDMv Disks
The maximum size of an RDMv disk is 2 TB (precisely, 2 TB minus 512 bytes). RDMv is mainly used for large volumes. Beyond 300 GB, introducing dedicated LUNs to the VM can be interesting. Indeed, the vmdk is a file that can be easily moved, but when it is a large file, moving it can be more complex. In this case, the better practice is to introduce the raw volume and use storage array functionalities to move volumes.
RDMv creates a file on the VMFS that acts as a proxy between the VMFS and the LUN in direct link with the VM. It allows the hypervisor to intercept I/O and logs them at need. RDMv authorizes VM snapshots (but not storage array snapshots) as well as the creation of clones and templates.
RDMp Disks
The maximum size of RDMp disks is 64 TB. This type of disk does not allow the hypervisor to intercept I/O. This means that VM snapshots cannot be taken (but array-based snapshots are possible), and creating clones or templates is not possible.
In general, RDMp disks are used to introduce to test servers the same data that is in the production databases, using the storage array snapshot functionality. They are also used for MSCS clustering. When using MSCS, the shared disks must not share the virtual controller of the OS.
Some companies might be hesitant about migrating their applications to virtual environments. With RDMp, the change can be done slowly and confidently because the company is free to return to a physical environment if tests are not conclusive in the virtual environment. For applications not officially supported in a virtual environment (for example, older versions of Oracle), RDMp can be used to provide a simple means of replicating the problem in a physical environment that is supported by the software publisher.
RDMp disks cannot be backed up like traditional VMs. The capabilities offered by the two modes are summarized in Table 3.3.
Table 3.3. RDMv Versus RDMp Disks
RDM Type |
vMotion |
Storage vMotion |
Filename |
VM Snapshot |
Snapshot at Storage Array Level |
Rdmv |
Yes |
Yes |
rdm.vmdk |
Yes |
Not recommended |
Rdmp |
Yes |
Yes |
rdmp.vmdk |
No |
Yes |
OVF Format
Current virtual disk formats are vmdk (used by VMware) and Virtual Hard Disk (vhd) (used by Microsoft Hyper-V and Citrix XenServer).
Open Virtual Machine Format (OVF) is not a virtual disk format; it is a file format whose particularities facilitate interoperability between the various virtualization and hypervisor platforms. An OVF file includes parameters and metadata such as virtual hardware settings, prerequisites, and security attributes. Provided OVF packages are not limited to one VM and can contain several. An OVF file can be encrypted and compressed.
The OVF template is made up of the following files:
- MF: A manifest file, serving to verify the integrity of the OVF template and determine whether it was modified.
- OVF: An XML file containing the information on the virtual disk.
- vmdk: A virtual disk in VMware, but this file can use a different format to facilitate the interoperability of hypervisors. VMware specifications authorize different types of virtual disks.
You can download preconfigured virtual appliances containing an OVF operating system and application solution from https://solutionexchange.vmware.com/store/category_groups/19.