Archive for March 2012

UEFI

UEFI = Unified Extensible Firmware Interface

After more than 30 years of unerring and yet surprising supremacy, BIOS — the IBM PC’s Basic Input Output System will be taking a backseat to UEFI. a specification that begun its life as the Intel Boot Initiative way back in 1998 when BIOS’s antiquated limitations were hampering systems built with Intel’s Itanium processors. Later, the Initiative became EFI, and in 2005 Intel donated EFI to the newly-formed UEFI Forum, a consortium made up of the usual suspects: AMD, Apple, IBM, Intel, Microsoft, and so on.

UEFI, or Unified Extensible Firmware Interface, is a complete re-imagining of a computer boot environment, and as such it has almost no similarities to the PC BIOS that it replaces. While BIOS is fundamentally a solid piece of firmware, UEFI is a programmable software interface that sits on top a computer’s hardware and firmware (and indeed UEFI can and does sit on top of BIOS). Rather than all of the boot code being stored in the motherboard’s BIOS, UEFI sits in the/EFI/ directory in some non-volatile memory; either in NAND on the motherboard, on your hard drive, or on a network share

As a result, UEFI almost resembles a light-weight operating system. A computer boots into UEFI, an arbitrary set of actions are carried out, and then it triggers the loading of an operating system. Further reinforcing its OSness, the UEFI spec defines boot and runtime services, protocols for communication between services, device drivers (UEFI is designed to work across all platforms), extensions, and even an EFI shell, where you can run EFI applications. On top of all this is the boot loader, which executes an operating system’s boot loader.

UEFI, being a pseudo-operating system, can access all of the hardware on the computer, you can surf the internet from the UEFI interface, or backup your hard drives, and it even has a full, mouse-driven GUI (below right). The fact that all of this boot data is stored on NAND flash or on a hard drive means that there’s a lot more space for things like language localization, boot-time diagnostics and utilities (backup, restore, malware scanners)

UEFI is still very young, and very few operating systems actually take advantage of any of the features listed above. Linux certainly supports UEFI, but doesn’t really utilizes it. Mac OS X makes slightly better use of UEFI with the Bootcamp boot manager. Windows 8, when it launches in 2012, will probably be the first major OS to take extensive advantage of UEFI, with Restore, Refresh, secure boot, and possibly more.

VMware vSphere 5 supports booting ESXi hosts from the UEFI. UEFI allows you to boot systems from USB Media (as well as hard drives and CD-ROM Drives)

VMware RDMs

What is RAW Device Mapping?

A Raw Device Mapping allows a special file in a VMFS volume to act as a proxy for a raw device. The mapping file contains metadata used to manage and redirect disk accesses to the physical device. The mapping file gives you some of the advantages of a virtual disk in the VMFS file system, while keeping some advantages of direct access to physical device characteristics. In effect it merges VMFS manageability with raw device access

A raw device mapping is effectively a symbolic link from a VMFS to a raw LUN. This makes LUNs appear as files in a VMFS volume. The mapping file, not the raw LUN is referenced in the virtual machine configuration. The mapping file contains a reference to the raw LUN.

Note that raw device mapping requires the mapped device to be a whole LUN; mapping to a partition only is not supported.

Uses for RDM’s

  • Use RDMs when VMFS virtual disk would become too large to effectively manage.

For example, When a VM needs a partition that is greater than the VMFS 2 TB limit is a reason to use an RDM. Large file servers, if you choose to encapsulate them as a VM, are a prime example. Perhaps a data warehouse application would be another. Alongside this, the time it would take to move a vmdk larger than this would be significant.

  • Use RDMs to leverage native SAN tools

SAN snapshots, direct backups, performance monitoring, and SAN management are all possible reasons to consider RDMs. Native SAN tools can snapshot the LUN and move the data about at a much quicker rate.

  • Use RDMs for virtualized MSCS Clusters

Actually, this is not a choice. Microsoft Clustering Services (MSCS) running on VMware VI require RDMs. Clustering VMs across ESX hosts is still commonly used when consolidating hardware to VI. VMware now recommends that cluster data and quorum disks be configured as raw device mappings rather than as files on shared VMFS

Terminology

The following terms are used in this document or related documentation:

  • Raw Disk — A disk volume accessed by a virtual machine as an alternative to a virtual disk file; it may or may not be accessed via a mapping file.
  • Raw Device — Any SCSI device accessed via a mapping file. For ESX Server 2.5, only disk devices are supported.
  • Raw LUN — A logical disk volume located in a SAN.
  • LUN — Acronym for a logical unit number.
  • Mapping File — A VMFS file containing metadata used to map and manage a raw device.
  • Mapping — An abbreviated term for a raw device mapping.
  • Mapped Device — A raw device managed by a mapping file.
  • Metadata File — A mapping file.
  • Compatibility Mode — The virtualization type used for SCSI device access (physical or virtual).
  • SAN — Acronym for a storage area network.
  • VMFS — A high-performance file system used by VMware ESX Server.

Compatibility Modes

Physical Mode RDMs

  • Useful if you are using SAN-aware applications in the virtual machine
  • Useful to run SCSI target based software
  • Physical mode is useful to run SAN management agents or other SCSI target based software in the virtual machine
  • Physical mode for the RDM specifies minimal SCSI virtualization of the mapped device, allowing the greatest flexibility for SAN management software. In physical mode, the VMkernel passes all SCSI commands to the device, with one exception: the REPORT LUNs command is virtualized, so that the VMkernel can isolate the LUN for the owning virtual machine. Otherwise, all physical characteristics of the underlying hardware are exposed.

Virtual Mode RDMs

  • Advanced file locking for data protection
  • VMware Snapshots
  • Allows for cloning
  • Redo logs for streamlining development processes
  • More portable across storage hardware, presenting the same behavior as a virtual disk file

Setting up RDMs

  •  Right click on the Virtual Machine and select Edit Settings
  • Under the Hardware Tab, click Add
  • Select Hard Disk
  • Click Next
  • Click Raw Device Mapping

If the option is greyed out, please check the following.

http://kb.vmware.com/RDM Greyed Out

  • From the list of SAN disks or LUNs, select a raw LUN for your virtual machine to access directly.
  • Select a datastore for the RDM mapping file. You can place the RDM file on the same datastore where your virtual machine configuration file resides,
    or select a different datastore.
  • Select a compatibility mode. Physical or Virtual
  • Select a virtual device node
  • Click Next.
  • In the Ready to Complete New Virtual Machine page, review your selections.
  • Click Finish to complete your virtual machine.

Note: To use vMotion for virtual machines with enabled NPIV, make sure that the RDM files of the virtual machines are located on the same datastore. You cannot perform Storage vMotion or vMotion between datastores when NPIV is enabled.