VMware - RDM

About Raw Device Mapping

An RDM is a mapping file in a separate VMFS volume that acts as a proxy for a raw physical storage device. The RDM allows a virtual machine to directly access and use the storage device. The RDM contains metadata
for managing and redirecting disk access to the physical device.

The file gives you some of the advantages of direct access to a physical device while keeping some advantages of a virtual disk in VMFS. As a result, it merges VMFS manageability with raw device access.

RDMs can be described in terms such as mapping a raw device into a datastore, mapping a system LUN, or mapping a disk file to a physical disk volume. 

Physical Compatibility Mode

In physical mode the SCSI commands are passed via the VMkernel, as all the hardware characteristics are exposed to the VM.
VMFS-5 supports up to 64TB disks size.

• Can not convert a 2TB+ RDM disk to a virtual disk or clone the VM for that fact, it is not supported.
• No snapshot can be taken with PCM disks.
• MS Clustering is supported in PCM.

Virtual Compatibility Mode

• In virtual compatibility mode the maximum VMDK file can only be 2TB in size.
• Virtual machine snapshots are available for RDMs with virtual compatibility mode
• You can storage vMotion VCM disk to other datastores.
• MS Clustering is not supported in VCM.

VMware - Roles and Permissions

I came across this strange issue yesterday 14th Jan 2013, where by I modified some AD groups and forgot to remove the groups from vCenter "Hosts and Clusters" and "Networking" beforehand. 
The results I was getting were very strange because every time I modified the Permissions in vCenter using the roles I created, it kept on changing back to the ready-only role. I was scratching my head until I remembered that permissions set on the "networking" inventory were not removed and once I did that the strange behavior stopped. Phew it did not create any problems for the end users.

So if you ever do this please remember to remove the permissions from "Hosts and Clusters" and "Networking" and then modify your users and groups in AD. 

VMware - Building your own lab

If you want to build your own VMware lab environment, I've put together a list of kits that you may be interested in.
I can't guarantee that the built in NIC are fully compatible with ESXi 5.1, but I've seen a post where by the user said it worked without any problems.

My lab includes 4 esxi hosts, this is to actually simulate site to site scenario by having 2 esxi in site A and 2 in site B. The sites will be connected by a router and switches. The kit below is for a small form factor case and also to reduce the amount of power the kit will draw.

Specification


1: Komputerbay 16GB (2x 8GB) DDR3 PC3-12800 1600MHz DIMM x £39.99 from Amazon

2: Gigabyte GA-Z77N-WIFI, Intel Z77, S 1155 x £88.52  from Scan


3: Intel Core i3 3220 Ivy Bridge Dual Core Processor x £88.96 from Scan


4: CIT MTX001B, Black, mini-ITX Case with 300W PSU x £27.47 from Scan

VMware - Snapshot explained

In VMware the snapshot file grows by 16MB block size. Now there is no formula out there that you can use to predetermine the size of the snapshot beforehand. 

But VMware's best practice is to keep the snapshot no more then 24-72 hours & 1-2 snapshots per VM. Snapshot files will grow to the maximum size of the original disk, to avoid any problems and to mitigate future issues either delete the snapshot or consolidate it when you are happy that your VM is running as it should be.

Now I’ve taken some screenshots of a virtual machine with the memory and quiesce options to show the size of the snapshots.

1: What the snapshot options look like.

2: This shows the state of the files before any snapshots. See that the vswp file is 4GB in size, that is the memory that was allocated to the server during creation.

3: The 1st snapshot I took was with the memory option which by the way is the default. As you can see the size of the delta.vmdk file is 16MB and that the vmsn file is 4GB in size, which is the size of the memory in the virtual server.

4: The 2nd snapshot was taken with only the "quiesce" option ticked and as you can see the delta.vmdk file is still 16MB but the vmsn file is only 31K. The reason is because there were no real disk I/O happening on the server at the time of the snapshot.

5: The 3rd snapshot was taken with both the "memory& quiesce" options ticked. The delta.vmdk is still 16MB, but the vmsn file is a combination of the memory and disk state.