When you’re booting a Lefthand Virtual SAN Appliance (this also applies to the Failover Manager), make sure you don’t disable ‘Serial port A’. It is required for console output, which is set to ‘ttyS0′ in the syslinux.cfg file of the underlying Linux OS:

So, make sure that the BIOS is set like this:

and not like this:

If you want more information about the boot process, use the ‘ESC’ key to abort the bootloader and type ‘vga’ in the ‘boot:’ prompt. This wil disable output to the serial port and enable output to the screen:

I’d like to warn you for a not-so-obviously documented fluke in the combination of a HP LeftHand (P4000) Multi-Site Cluster and VMware vSphere hosts on multiple sites.

The situation

HP LeftHand (P4000) Multi-Site Cluster

HP LeftHand Multi-Site Cluster requires the storage nodes to be divided into two subnets, one per site. Each subnet (or VLAN) requires a Virtual IP in that subnet.

Example

I.e.: VLAN 1 with Virtual IP 10.10.1.100 (/24) for site 1 which hold storage node 1 and storage 3 and VLAN 2 with Virtual IP 10.10.2.100 (/24) for site 2 which hold storage node 2 and storage node 4.

LUN Ownership

Whenever a LUN (or volume, in Lefthand’s CMC) on the LeftHand cluster is accessed by an iSCSI Initiator, that volume is bound to the Virtual IP (and thus subnet / VLAN) by which the LUN is accessed.

Example

I.e.: when an ESX-host on Site 1 rescans it’s vmhba38, the volumes presented to that ESX-server get bound to this site’s Virtual IP, which is in VLAN 1.

VMware ESX software iSCSI Initiator and multiple subnets

The VMware software iSCSI Initiator (and, by extension, the dependent hardware iSCSI Initiator) do not support accessing a iSCSI Target (or LeftHand Virtual IP) outside it’s own subnet.

Example

I.e.: the ESX-hosts on Site 2, which have their iSCSI adapter in VLAN 2, cannot traverse the network to access the LUN that is bound to VLAN1. They to a discovery to the Virtual IP in VLAN 2, but get redirected to the Virtual IP in VLAN 1, because that’s where the LUNs are bound to. You’ll see errors in  /var/log/messages about iscsid not being able to connect to the Virtual IP in VLAN 1.

The solution

Multiple VMkernel ports for iSCSI in multiple VLANs

The only way to maintain synchronous replication (‘Network RAID 10′ in LeftHand naming convention) is to maintain the HP LeftHand Multi-Site Cluster. This means maintaining the multiple VLANs for iSCSI. To enable hosts on site 2 to access the LUNs, you’ll need to configure additional VMkernel ports for iSCSI in the other VLAN. So in addition to the two VMkernel ports in VLAN 2 on an ESX-host in site 2, you’ll add two VMkernel ports in VLAN 1 on that ESX-host. On the ESX-hosts in site 1, you’ll add two VMkernel ports in VLAN 2.

The impact of this change is additional iSCSI traffic over the intersite link: not only does the replication traffic travel between sites, now also iSCSI traffic from the ESX-hosts in site 2 travels the intersite link to the storage nodes in site 1.

Another change in this environment is the added complexity to complete a site failover. You’ll need to rescan all software iSCSI adapters after the primary site has failed, because the LUNs are still attached to the (now failed) Virtual IP of the primary VLAN. By rescanning, the LUNs are attached to the Virtual IP of the other VLAN. If site 2 fails, only the replication is lost, as site 2 doesn’t do any iSCSI traffic with any of the ESX-hosts but merely does Network RAID 10 replication.

If you dare create a single vSphere Cluster, spanning HA/DRS across sites, VMware HA can take care of VM failover. If hosts on site 1 fail but storage is still alive, a rescan on the hosts on site 2 is needed before HA can restart the VM’s. You’d better be quick with that rescan! If hosts on site 2 fail, no rescan or other action is needed, as HA will restart VMs in the ESX-hosts in site 1 (because ESX-hosts in site 1 have an active session with the LUNs).

I’ve implemented a new five-node VMware vSphere cluster for a customer. The hardware we’re using are HP ProLiant DL360 G7′s. They’ve got the new Broadcom 5709c Gigabit Ethernet Adapters, which present themselves as both standard Ethernet network cards as well as storage controllers (‘Broadcom iSCSI Adapters’ in the Storage Adapter section of the host’s Configuration Tab). The main advantage of these dependent hardware iSCSI HBAs is the offloading of iSCSI traffic to the TCP/IP Offload Engine on the NICs, which reduces the amount of processor power needed for the iSCSI traffic. VMware describes dependent hardware iSCSI as “Depends on VMware networking, and iSCSI configuration and management interfaces provided by VMware. This type of adapter can be a card that presents a standard network adapter and iSCSI offload functionality for the same port. The iSCSI offload functionality depends on the host’s network configuration to obtain the IP, MAC, and other parameters used for iSCSI sessions.”

As they are dependent hardware iSCSI HBAs, you’ll need to use standard VMkernel components to make them work. In a nutshell, these are the steps you need to go through:

• There is a static relationship between a NIC port (vmnic#) and a dependent iSCSI HBA (vmhba##). Use ‘esxcli swiscsi vmnic list -d vmhba##’ to view which vmnic belongs to this vmhba.
  In my case, vmnic0 corresponds to vmhba32. vmnic1 corresponds to vmhba33.
• Create a VMkernel port on a vSwitch with a single uplink (choose one of the vmnics which have a corresponding vmhba).
  I’ve created two vSwitch Port Groups: iSCSI0 and iSCSI1. iSCSI0 has vmk0 with uplink vmnic0, iSCSI1 has vmk1 with uplink vmnic1.
• Bind the vmk# to a vmhba in such a way that the uplink on the vSwitch of the VMkernel port corresponds with the vmhba##. Use ‘esxcli swiscsi nic add -n vmk# -d vmhba##’.
  I’ve bound vmk0 to vmhba32 and vmk1 to vmhba33.
• Verify that all is well with ‘esxcli swiscsi nic list -d vmhba##’

Some points to take into account:

An e-mail from the VMware User Group Team:

As announced earlier this year, VMware is supporting the establishment of an independent, customer-led, customer-driven global VMware User Group (VMUG). The VMUG Steering Committee has been focused on forming the structure for this new organization and we are pleased to announce the inaugural VMware User Group Board of Directors.

The board is comprised of a group of experienced VMUG leaders whose knowledge, expertise and vision will provide an invaluable contribution to the VMUG organization. There is much for this Board of Directors to accomplish, as we look forward to the formal launch of the independent VMUG at VMworld in San Francisco this coming August.

The board has developed a VMUG mission statement to reflect the new organization:
The VMware User Group is an independent, global, customer-led organization, which maximizes members’ use of VMware and partner solutions through knowledge sharing, training, collaboration, and events.

The VMware User Group is a user community—of the users, for the users, by the users. Through an independent global VMUG, we believe we can strengthen our collective VMware and VMUG value proposition with expanded collaboration, member programs, and benefits.

As a VMUG member, your feedback and ideas will be critical to improving the VMUG experience and taking it to the next level. We believe that some of the benefits of the new model will be:

• Tap into new VMUG member benefits and programs, such as Special Interest Groups and VMware technical education offerings
• Increase your value to your organization by becoming the recognized VMware subject matter expert through knowledge and contacts gained through VMUG
• Gain more direct access to VMware subject matter experts
• Become part of a global, collective customer voice, impacting VMware products/services

While we are planning the official launch of the new group for August, there are several ways VMUG is already driving value to the members:

• The VMUG Voice—VMUG’s monthly newsletter—will provide news and updates for members
• New member recruitment activities at all VMware events
• Development of new onsite program for VMUG Regional Events
• VMware Technical Sponsors have been assigned to all VMUG Local Groups
• VMUG members will receive the discounted “Early Bird” pricing throughout the VMworld registration period

As we work to establish an independent VMUG, we want you to know that your voice will be heard. To that end, the VMUG Board of Directors is conducting a short survey of our members to better understand the members’ vision for VMUG and define the VMUG value proposition. It should only take about ten minutes of your time and all results will be kept completely confidential. In addition, all survey respondents can enter to win an Apple iPad—just complete the survey by July 30.

We look forward to hearing your feedback and ideas about the new organization. Please direct all communications to memberservices@myvmug.org or 1.800.606.8695.

Together we look forward to launching the new VMUG at VMworld and we hope to see you there!

Sincerely,
The VMware User Group Board of Directors

The big news today is the release of VMware vSphere 4.1, but let’s not forget SRM! From the release notes:

New in This Release

This release of Site Recovery Manager introduces several new features and fixes:

• Full compatibility with vCenter 4.1.
• Support for IP customization of Windows 7 and Windows Server 2008 R2.
• Test recovery times have been improved for ESX 4.0.1 hosts that use iSCSI arrays.
• Full compatibility with vCenter Solution Licensing.
• New configuration file options: change guest operating system shutdown retry timeout when customizing IP address during recovery, and change datastore discovery timeout during recovery (see Configuration Notes).
• Full support for networks backed by a VMware vNetwork Distributed Switch (vDS) at the protected and recovery sites.
• Fixes for several problems identified in previous releases. For more information, see VMware Knowledge Base Articles 1019890, 1021827, 1021491, 1021829, 1017882, 1021919, and 1021920.

Compatibility

SRM 4.1 server software can be installed only on 64-bit host platforms. The SRM 4.1 server is incompatible with 32-bit hosts. The SRM 4.1 client plug-in remains compatible with 32-bit hosts. Regardless of the database server you are using, you must install a 32-bit database client (ODBC driver) on the SRM server host. The SRM server is not compatible with 64-bit database clients.

SRM 4.1 is designed for compatibility with vCenter 4.1. SRM 4.1 is incompatible with vCenter 4.0 and earlier releases.

SRM 4.1 can be installed as a new release or as an update to SRM 4.0. You cannot install SRM 4.1 as an update to SRM 1.x releases.

The Site Recovery Manager Compatibility Matrixes guide lists all compatible versions of VMware vSphere components, and also lists supported supported databases and guest operating systems. Compatible storage arrays and SRAs are listed in Site Recovery Manager Storage Partners.

Installation Notes for This Release

You can install SRM 4.1 in one of two ways:

• As a new installation on a 64-bit server host. This installation can either create a new SRM database or update an existing SRM 4.0database.
• As an update of an existing SRM 4.0 installation on a 64-bit server host, which also updates an existing SRM 4.0 database to the SRM 4.1 schema.

Additional information about installing SRM is available in the following documents:

• Getting Started with Site Recovery Manager provides a high-level architectural overview and workflow.
• The Administration Guide includes step-by-step guidance on installing and configuring SRM. This guide contains information about all requirements and procedures to set up SRM and also addresses prerequisites and scaling limits.
• The Site Recovery Manager Evaluation Guide provides a conceptual overview as well as step-by-step workflows describing planning for using SRM, setting up protected and recovery sites, testing failover, the failover and failback process, alarms and status monitoring, and a discussion of roles and privileges.

Note: If the SRM host is unable to contact vCenter during SRM installation, the installer will retry the connection for up to 30 minutes. Canceling the installation during the retry period can have unpredictable results. If you cannot correct the problems with the connection between SRM and vCenter, you should allow the retry timeout to expire so that the installer can terminate gracefully and roll back.

The VMware Uptime blog has posted a nice article about upgrading to SRM 4.1.

A couple of products will change licensing model from a per-socket to a per-vm model.

What You Need to Know About Per VM Licensing

As cloud computing becomes the norm in IT environments, IT increasingly needs to manage at the virtual machine (VM) level rather than the physical hardware from which it is abstracted. With virtual machines now being the new unit of management, IT organizations need flexible deployment and licensing options that fit the demands of the new model.

Starting September 1, 2010, some VMware vCenter products will transition from the existing per processor licensing to per VM licensing. Other vCenter products will continue to be sold under existing licensing models.

How Much Will the Per VM Licenses Cost?

Products will be sold in packs of 25 virtual machine licenses (prices do not include SnS). This is a more cost-effective way for customers to implement the management products since it eliminates the need to license them on a per processor basis.

*VMware vCenter CapacityIQ will be offered in a per VM model beginning at the end of 2010 / early 2011, and you can continue buying per processor licenses for vCenter CapacityIQ until then.

As noted above, customers who have purchased per processor licenses for these products prior to September 1, 2010, will be eligible to exchange their licenses to receive a specific number of per VM licenses for each per processor license.

VMware will provide more details for existing customers in the coming weeks.

Moving to Per VM Licensing

• vCenter AppSpeed
• vCenter CapacityIQ (offered in a per VM model late 2010 / early 2011)
• vCenter Chargeback
• vCenter Site Recovery Manager

Continuing with Existing Licensing Models

• VMware vSphere
• vCenter Server
• vCenter Server Heartbeat
• vCenter Lab Manager
• vCenter Lifecycle Manager

How This Affects You

If you are new to the VMware vCenter products, you will benefit from the new pricing model which makes it easier and less expensive to take advantage of the vCenter product capabilities.

If you have previously purchased per processor licenses for vCenter AppSpeed, vCenter CapacityIQ, vCenter Chargeback or vCenter Site Recovery Manager, VMware will provide a transition plan that allows you to exchange your current per processor licenses for ones that are based on the new per VM licensing model. If you own per processor licenses for the above products as of September 1, 2010 you will be able to exchange them for per VM licenses.

Do I Need to Convert to Per VM Licenses?

No. You can continue to use the per processor licenses you already own. You can continue to renew VMware Support and Subscription (SnS) for the per processor licenses using your regular renewal terms.

If you have purchased per processor licenses and wish to continue with this model, you will also be able to continue purchasing per processor licenses through December 15, 2010. However, after December 15, 2010, you will only be able to buy Per VM licenses for vCenter AppSpeed, vCenter CapacityIQ, vCenter Chargeback and vCenter Site Recovery Manager. These products will be sold in increments of 25 VMs per license.

How Per VM Licensing Works

Per VM licensing is more flexible. Rather than requiring licenses for every server deployed, you will only need licenses foraverage maximum number of virtual machines that are managed. Let’s look at an example:

Per VM licensing is based on a rolling average of the highest number of VMs over the last 12 months.

• You want to manage cost reporting effectively and decide to buy VMware vCenter Chargeback.
• On an average day, you run between 90 and 125 virtual machines.
• As shown in the chart above, at the end of the year, usage typically spikes to 200 to 250 virtual machines for two months.
• The daily maximum total virtual machines still averages only about 130 virtual machines.
• You would only need enough licenses for 130 VMs – the average high watermark over the course of the trailing12 months. In this case, the customer would buy six licenses for a total of 150 VMs (each license contains a pack of 25 VMs).
• If the average usage over time exceeds 150 VMs, you will receive an alert through VMware vCenter Server, but will be able to continue managing the environment without restrictions.

Source.

I’ve been away for a long time (almost two months), but with a good excuse, I think. I’ve been in the process of buying a house, so I’ve gone through the financial and administrative bureaucracy, bought new furniture, a new kitchen and have been packing and cleaning up my current place. Besides that, I’ve been incredibly busy at work, creating many documents for standard workflows for project implementations of VMware vSphere and a reference architecture for coworkers so they know what they need to think of when implementing VMware vSphere. And lastly, I rediscovered my passion to go sailing, which takes up a couple of my evenings and weekends, especially with the good summer weather in the Netherlands lately.

But a couple of documents on VMware’s Partner Central caught my eye. I found loads of PDFs and Powerpoint presentations demonstrating vSphere 4.1′s new features and improvements. I just couldn’t let this one slip by. It even seemed I was right on time, forbidding publication until only a couple of hours later. So, What’s New and Improved? Quite a lot, actually:

Hypervisor (ESX / ESXi) Improvements

• Memory Compression (accelerates swap files, among other things);
• Host-connected USB Device Pass through (uses networking for inter-host connectivity!);
• Host AD Integration;
• Boot from SAN for ESXi is fully supported;
• ESXi scripted installation like ESX;
• ESXi Local and Remote Tech Support fully functional from vSphere Client;
• Couple of new vCLI commands (like esxcli swiscsi session, nic, vmknic, vmnic, vaai device, corestorage device).

Network and Storage Improvements

• Storage I/O Control (Set quality of service priorities to guarantee access to a storage resource, works with the limits and shares we know);
• Network I/O Control (only for Enterprise Plus with a dvSwitch, works with the limits and shares we know);
• vStorage API for Array Integration (Full Copy, xcopy-like function to offload work to array, atomic test and set). EqualLogic already has support for this, as does EMC, among four or five others. This has huge implications for Storage vMotion, provisioning VMs from Templates, thin provisioned disk performance and VMFS scalability. Supports only block-based storage in this release;
• Load based teaming (only for Enterprise Plus with a dvSwitch, avoids congestion by balancing load on the team);
• Full IPv6 NIST Compliance;
• Performance improvements in vNetwork (UDP and inter- and intra-host VM to VM performance improvements with Tx Worldlet and Large Receive Offload);
• VMkernel TCP/IP Stack performance improvements (vMotion, NFS, FT Logging, iSCSI by as much as 90% with Broadcom iSCSI HW offload);
• dvSwitch scales to more than 350 hosts per dvSwitch;
• Cisco Nexus 1000v new and improved (easier software upgrade with ISSU and binary compatibility, Weighted Fair Queueing, VLAN pinning to pNIC, Scale Port Profiles beyond 512).

Cluster Improvements

• HA Diagnostics and Health check, HA Operational Status;
• DPM improvements: turn on or off with scheduled tasks. Disabling DPM brings hosts out of standby;
• EVC improvements to support latest generation of processors (AMD NextGen without 3DNow!) and a couple of usability improvements like a better ‘add host’ workflow which checks for more errors;
• DRS Host Affinity (strict/required and preferential affinity rules, enables you to segregate VMs based on blade-enclosure, for instance);
• DRS Anti-affinity rules can now contain more than two hosts;
• HA and DRS Cluster Limits: 32 hosts/cluster, 320 VMs/host (regardless of number of hosts/cluster), 3000 VMs/cluster. These are Post-Failover limits;
• Improved HA-DRS interoperability during HA failover, reduce slot fragmentation and improve HA’s ability to restart failed VMs;
• Improved vMotion performance and scale by a factor of five, 8 live vMotions simultaneously on 10Gbit/s, max 8Gbit per vMotion. 128 vMotions per datastore;
• Fault Tolerance is now fully integrated with DRS (DRS load balances FT Primary and Secondary VMs, although EVC is required);
• Host profiles will include Cisco Nexus 1000v, PCI device ordering, iSCSI Support, root password, PSA configuration.

Managementplatform Improvements

• 64-bit-only vCenter (migration tool included) to enable scalability;
• Virtual Serial Port Concentrator to connect to traditional, secure, low-bandwidth remote consoles, usually for Linux VMs;
• Import Hyper-V VMs (powered-off VMs only at this time);
• New performance monitoring metrics (amongst others for NFS, datastore activity per host and per VM. Even virtual disk activity per VM!);
• Patch recall support for VMware vCenter Update Manager;
• Support for 3rd Party modules patching (EMC PowerPath is one of them).

Data Protection

• vDR support management for up to 10 appliances and 1000 VMs per vCenter Server;
• File Level Restore for Linux VMs;
• Improved VSS support for Microsoft Windows 2008 and 7 in the form of application level quiescing;
• Extended support for DAS, CIFS, NFS, iSCSI and FC Storage;
• Improved deduplication performance;
• Better GUI and usability by improving the vSphere Client Plugin-in.

Naming Changes

• VMotion if now vMotion. Also applies to Storage vMotion;
• ESXi (Free Edition) is now called vSphere Hypervisor.

Shifting features between editions and kits

• vMotion moved downstream to Standard Edition and Essentials Plus kit;
• vSphere Storage APIs for Multipathing and vStorage API for Array Integration are moved downstream to Advanced;

Pricing

• VMware vSphere Essentials Kit, $495 per 6 processors (includes VMware vCenter for Essentials);
• VMware vSphere Essentials Plus Kit, $3,495 per 6 processors (includes VMware vCenter for Essentials);

• VMware vSphere Standard, $995 per processor;
• VMware vSphere Advanced, $2,245 per processor;
• VMware vSphere Enterprise, $2,875 per processor;
• VMware vSphere Enterprise Plus, $3,495 per processor;
• VMware vSphere Enterprise Plus and Cisco Nexus 1000v bundle, $3,895 per processor;

• VMware vCenter Server Foundation, $1,495;
• VMware vCenter Server Standard $4,995;

• VMware vSphere Advanced Acceleration Kit for 6 Processors, $10,495;
• VMware vSphere Midsize Acceleration Kit for 6 Processors, $17,795;
• VMware vSphere Enterprise Plus Kit for 8 Processors, $26,395.

In my earlier post, I showed you some videos on installing and configuring XenClient but also some basic stuff about the options in Virtual Machine as well as the client-side interaction with the Synchroniser. I’ll dive deeper into both the virtual machines and the Synchroniser. Also, I’ll insert some of  my semi-random thoughts about the whole package along the way.

Virtual Machines

I’ve tinkered around some more. I inserted a USB drive, swapped it between VMs, played some HD-content (both 720p and 1080i) while switching between my work and home VM and even tried to get application sharing (with Citrix Dazzle) to work. Sadly, that last one was a big miss, it required multiple reboots (to get the agents installed), editing text files, and even then, it didn’t work, even after starting all over again, disabling the Windows Firewall, playing around with Remote Desktop settings, etc. I did however manage to get my multi monitor setup working on one of the VMs! Truth be told, multi monitor is a bit buggy (as Citrix clearly states) and certainly doesn’t win any prizes (monitor flickers when changing VMs, etc). That being said, I really liked the fact that it did work. Also, the 3D (HDX) support out-of-the-box (ticking a single box did the trick) amazed me. I was able to view both a 720p and a 1080i WMV HD video without any major glitches. I must add that only one virtual machine can enjoy 3D/HD capabilities at the same time.

Synchroniser

I fail to see the added value for the Synchroniser completely. It doesn’t allow for any import/export from a Citrix XenServer or XenDesktop VDI farm and doesn’t allow for import from a VHD (converted with XenConvert). This only thing is currently does is upload/synchronisation from a running XenClient instance for backing up and restoring. Also, you can assign the backup to other users, so they can use the desktop image. Without any good integration with VDI or a virtualization platform, there’s really no good central management of your desktop images, thus making Synchroniser more or less useless at this point. I did use it once to restore a Windows 7 desktop to my XenClient machine after I killed it, but that’s about it. I also fail to see the distinction between a ‘New VM’ and a ‘Restore VM from Backup’. I don’t really know what either one does differently, except for overwriting a previous VM or downloading a new copy.

Nonetheless, here are some screenshots:

[Show as slideshow]

Citrix Receiver for XenClient

So, let’s change focus to the main part: the XenClient itself. I’ve spent a couple of hours getting to know it, and am pleased, overall. Let me begin by saying that it won’t install inside a VMware Workstation VM. Bummer .

There are a lot of little things that tell me that it’s an obvious RC, like the boot time and locking up when I (gracefully) shutdown a VM. It takes about two whole minutes from power on to usable XenClient. Remember, XenClient adds the hypervisor layer, and that layer will boot and shutdown whenever you use your laptop, unlike a server with a hypervisor that will only boot every couple of months. Those two minutes are without booting any VMs though, that will set you back another minute or two. Also, I wasn’t able to autoboot my personal VM on XenClient boot. Sleeping and waking the system is good though, about 5 seconds when no VMs are active. Even with running VMs, it was as fast as I expected:

XenClient has good support for WiFi-adapters, USB-controllers and the like. Although XenClient currently has a very restrictive HCL, I can assume that the ones on there do work fantastic. My Dell Latitude E6500 certainly does. The interface is good, has the right amount of options in the right place, although I wasn’t about to fire up esxtop xentop or any other way to show load information.

What’s next?

I’m still trying to sort out the application publishing deal. I will have to rebuild the lab to see if it’ll work. More on that later. Maybe.

I just learned that Citrix released a Release Candidate of their Client Hypervisor. I noticed my laptop, a Dell Latitude E6500, is compatible with XenClient, and decided to set up a home lab.

I burned the ISO to a CD, attached an external USB SATA drive to the E6500, and fired up the installer. The installation went very smoothly, and it was able to leave my SSD and other SATA-drive (both of which contain my regular Windows 7 installation) alone.

Now I’ve got this dual-boot scenario with Windows 7 (on the SSD, data on the integrated SATA drive) and the XenClient hypervisor (on the external USB SATA drive). I didn’t even need the documentation . While burning the ISOs of XenClient and Windows 7 (32-bit), I spent a couple of minutes watching the videos.

I spend an hour or so creating and configuring virtual machines with various settings:

On my other laptop, a Zepto Znote 6324W, I installed the latest version of XenServer to host the XenClient Synchroniser. With the E6500 booted to Windows, I installed XenCenter and imported the Synchronisor into XenServer. Also, I installed a Windows 7 (32-bit) VM so I could test the Synchroniser. More on that later.

I found this in the community site of the latest release of VMware Workstation 7.1:

Many of our users are encountering issues with our Software Updates feature. We appreciate your patience and thank you for helping us iron out the bugs before we make the Workstation 7.1 release generally available.

We will be posting a second Release Candidate shortly to ensure that the issues that have been reported have been fixed.

In the meantime, if you are running Windows Vista or above on a non-English host operating system, and attempting to update your Beta fails after granting UAC access please try replacing vmUpdateLauncher.exe. A new version of this file and more details can be found here:

Non-English users: Having problems updating Tools or to RC? Fix within.

If you are running Windows Vista or above on a non-English host operating system, and attempting to update Workstation fails after granting UAC access, please try replacing vmUpdateLauncher.exe in C:\Program Files\VMware\VMware Workstation with the attached vmUpdateLauncher.exe.

The problem affects beta and RC and will not be properly released until later.

You can tell if you have the problem if the update does not work by checking Task Manager. If vmUpdateLauncher.exe is eating 100% of your CPU, you are experiencing this problem. If not, it may be something else.

Thank you for trying out the beta!

Download

I just started my copy of VMware Workstation for some vESX testing, and was greeted by this nice message:

IMPORTANT NOTE: If you are using the current beta license key, you will want to enter the following license key in VMware Workstation via the Help -> Enter License Key menu: M148Z-H010J-H8T8C-0JAUK-ADM4C  (expires on July 15, 2010).

Key improvements since the VMware Workstation 7.1 Beta include:

• Graphics Get Faster: Improved performance and better compatibility for both DirectX 9 and OpenGL 3D apps

• OVFTool 2: New version of the OVF Tool to import and export OVF packaged virtual machines and upload to vSphere

• Memory Management:  New UI to handle increased virtual memory capacity

• New Guests: Support for Ubuntu 10.04 and RHEL 5.5 added

• Reported Issues: This release candidate also address many of the issues reported via the forums

See the VMware Workstation release notes for more details.

My website is running on a single ESX machine in a remote datacenter somewhere. Because I am hosting the machine myself, I had to do my own routing and firewalling. I solved it by installing a pfSense virtual machine, hooking it up to both an internal and external vSwitch:

This way, my server is secure: both the Service Console as well as the virtual web server are only accessible through the firewall. I’m running OpenVPN on the pfSense machine, so if I need access to the internal subnet, I fire up OpenVPN. Sometimes, however, I don’t have the OpenVPN software running on the PC I’m working on, so I cannot access the Service Console and/or the web server.

A cool little solution for this is to use SSH tunneling. I connect to a third machine which is accessible through the Internet (runs a SSH daemon) and is able to connect to 10.10.100.2, the Service Console IP address. By configuring PuTTY to do some magic for us, I am able to connect my vSphere Client to my ESX server securely, without publishing my ESX-host to the world.

Steps

• Make sure you have a SSHd accessable from the Internet
• Make sure the VM running SSHd can access the Service Console IP
• Open PuTTY, navigate to [Connection] – [SSH] – [Tunnels], and fill in three forwarded ports: 443, 902 and 903. Fill in ‘Destination’ like this: [youresxip]:[port].

• Add an entry to your hosts file so the real DNS-name of the host refers to 127.0.0.1 (Source)

• Fire up the vSphere Client and connect to [youresxdnsname].[domain]

Today, Veeam announced SureBackup. It’s an automated framework to do verification of your backups. It ensures reliability of the backup. It enhances the granularity of restoration.

How does it work?

The way Veeam does backups does not change with this introduction. Veeam still does image-level backups of complete Virtual Machines. This is flexible because it is Guest OS and application agnostic, portable and really simple, because it does not use any application integration using agents. This, of course, is also a major downer: it doesn’t integrate well with rare or home-grown apps. Neither does it backup data twice (once for image-level, once for agent based backups).

Doing image-level backups uses snapshots of live systems. This doesn’t do anything good in the reliability department. Applications aren’t flushed to disk and filesystems aren’t unmounted. There’s really no way of knowing if the backup has succeeded. Veeam asks you “Unless you test every backup, you don’t know… but how can you possibly test every backup?” To add even more complexity into the mix: testing multi-tier applications. How can you verify that a certain service restores correctly? You’d need a mix of different VM’s, all running a part of the service. Testing such a restore is expensive, time-consuming, labor-intensive and frankly, not a reliable method.

So Veeam’s come up with a way to verify the image-level backup you’ve just made. Simply said, it can present the backup (which is deduped and compressed to a file on disk) as a (read-only) NFS datastore to an ESX cluster. The presented backup is seen as a standard VM and can be run in an isolated network bubble. All the pre-requisites (like the network bubble, NFS-server, etc) are automatically handled by Veeam Backup, so user interaction is minimized.

The backup file isn’t changed at all. Changed blocks/data is stored in a temp delta VMDK on a regular datastore. Using custom scripts, the service or application can be verified as working. Because the verify does not actually copy data from backup file to datastore, it is fast. 150GB-Exchange-in-2-minutes-fast.

Recovering data does not need to be performed by the administrator. If an application is restored, a user can access it using a custom URL generated by Veeam. The user logs in using his own credentials and restores his own e-mail or file. The administrator deletes the environment afterwards. Do you see the use-case for patch-testing and creating a shadow-environment for development or auditing.

Cool Stuff

It makes a cool solution for actually using your DR-site for the verify process. Just replicate the backups to the second site and do the verification there. As Lode Vermeien puts it: “So I can do cross-site backup and verify at my DR site? If so, bye bye SRM.. (for 90% of my customers, who can’t afford SRM in the first place)”. It does in fact differ hugely from SRM, as SureBackup does not require array-based replication.

Pitfalls

• Your backupserver becomes a storage server. Verifying multiple virtual machines concurrently puts the backupserver (which doubles as a NFS storage server) under higher load, which might justify bigger hardware for this purpose. By the way, the NFS server is a Veeam-specific implementation, it does not utilize the Windows NFS server feature, but it still does require a server OS.
• Multi-VLAN configurations. Without access to the physical router, how can an isolated multi-tier, multi-VLAN configuration connect to the other VMs?
• If you’re currently verifying a configuration, will a ‘backup everything’ schedule back up these temporary VM’s as well?
• Will it play nicely with VMware HA and DRS?

Join my on the Veeam Forums for a discussion on these points!

Availability and pricing

Boy-oh-boy-oh-boy, this is the best day since I know what VCB is! Finally, it’s being retired!

Dear Valued Customer,

The purpose of this letter is to inform you of our vSphere backup product strategy, ongoing enhancements, and end of availability plans for VMware Consolidated Backup.

VMware Backup Product Strategy
VMware released vStorage APIs for Data Protection (VADP) with the vSphere 4.0 release in May, 2009. VADP is the next generation of VMware’s backup framework. We have also been working with several backup partners to integrate VADP into their solutions to make backup of vSphere Virtual Machines fast, efficient and easy to deploy compared to VCB and other backup solutions. Several of our major backup partners have already released VADP integrated backup products and we expect most of the major backup partners to have VADP integrated backup software by the upcoming feature release of the vSphere platform in 2010.

Future Product Licensing
Given the strong interest and adoption of VADP by our backup eco-system and the benefits offered by VADP compared to VMware Consolidated Backup (VCB), we are announcing the End of Availability for VCB starting with next vSphere feature release in 2010. Starting with the next vSphere platform feature release, VCB will be removed from vSphere platform. VADP integrated backup products (including VMware Data Recovery) will be the recommended option for efficient backup and restoration of vSphere Virtual Machines. This will allow us to focus new value added feature development on VADP instead of two backup frameworks (VCB and VADP). You can find more information about the use of vStorage APIs for Data Protection in our Developer Community. For information on the availability of VADP integrated release of your backup product please contact your backup vendor.

End of Availability
With the release of the next vSphere platform, we will continue to provide the binaries for VCB, but they will not be compatible with the next platform release. We will continue to provide support for VCB on the current vSphere platform per the VMware support policy.

If you need assistance in the migration from VMware Consolidated Backup to the vStorage APIs for Data Protection, please contact your local reseller or storage backup vendor.

Best regards,
VMware Product Management

I’ve been preparing for the Design exam portion of VCDX for the last couple of days. Tomorrow is D-day for me! Meanwhile, some tweeps asked my what materials I used to prepare. Well, here you go:

Obviously, use the VMware VCDX Community Documents and the VCDX Design Exam Blueprint. I’ve read ‘Mastering vSphere 4′ by Scott Lowe, which is a nice addition on some of the details on vSphere. Only read if you’ve got the time, it weighs in at a hefty 700 pages.

The absolutely most valuable resources for me were:

• VMware Technical Paper - Business Continuity and Disaster Recovery
  • I highly recommend this VMbook!
• VMware Infrastructure 3 in a Cisco Network Environment
• iSCSI Design Considerations and Deployment Guide
• VMware VI3 Security Hardening
• Chad Sakacc - A “Multivendor Post” on using iSCSI with VMware vSphere
• Duncan Epping - HA Deepdive

Also, these were nice to read:

• Duncan Epping - Impact of decisions…
• Frank Denneman - Impact of Host local VM Swap on HA and DRS

The usual linkage on the blogs show some other useful documents, too:

• Scott Lowe - VCDX Design Exam Post-Mortem
• Jason Boche - VCDX Design Exam: been there, done that!
• Rick Scherer - VCDX Design Exam – Complete
• John Arrasjid - VCDX Tips from VCDX 001 John Arrasjid

As I’m a bit rusty on iSCSI, I’ve read up on those as well. Remember that the VCDX Design exam is on VI3.5, not vSphere, so these might not apply!

• iSCSI Design Considerations and Deployment Guide
• NetApp and VMware vSphere Storage Best Practices
• VMware vSphere and ESX 3.5 Multiprotocol Performance Comparison Using FC, iSCSI, and NFS
• Best Practices for File System Alignment in Virtual Environments

Specifically, I was also interested in the way Dell/EQL handles iSCSI

• Dell VMware vSphere Reference Architecture for SMB
• Dell EQL – Configuring VMware vSphere swiSCSI with PS-Series storage
• Jon Owings / 2vcps and a Truck – iSCSI Connections on EqualLogic PS Series

Digging deeper into templates and linked clones in VMware Workstation, we can create templates of ESX and ESXi. Using the previous post as a basis for the ESX template, it’s relatively simple:

Creating the template

When creating a virtual machine for ESXi, be sure to adhere to the 2 vCPU default value and the 2GB memory, as these are the minimum requirements for ESXi. There are, however, ways to reduce the minimum amount of RAM (see VCDX 007′s post). From experience, I know that selecting 1 vCPU also works. I’ve selected the LSI Logic SAS controller, and added three more Intel E1000 NICs to the configuration. Also, as I’m restricted in the amount of disk space, I’ve used a 2GB disk to install ESXi on.

One other thing to note, when you’re using the ‘hack’ to allow ESXi to boot with less than 2GB of memory is a chance you can’t add ESXi to vCenter.

[Show as slideshow]

Install ESXi

Just follow the default [F11] [Enter] installation procedure. A side note: ESXi does allow installation on a small 2GB drive:

Power off the VM after installation. Make sure that VM does not reboot and loads ESXi. This way, you are guaranteed a fresh, unique instance of ESXi. This prevents possible problems with generated SSL and SSH keys, among other things.

Make a snapshot of the VM

[Show as slideshow]

Deploying a virtual machine based on a template

[Show as slideshow]

After cloning and booting, ESXi is loaded with default settings. You can now assign a password, unique hostname and IP address settings. Make sure to reboot once after configuration.

In my earlier post, I described how I use my laptop as a mobile server. One of the optimizations I’ve applied is the use of templates and linked clones within VMware Workstation 7. Using templates and linked clones gives you a couple of advantages:

• Saves you time: no need to install the Guest OS every time you need a clean virtual machine.
• Saves you disk space: the template takes up the normal amount of disk space, as it contains the complete Guest OS. The linked clone only takes up a relatively small amount of disk space, as it contains only the changed data.

Creating a Virtual Machine

Create a virtual machine to your liking. I’ve used the following values:

[Show as slideshow]

Installing a guest OS in the Virtual Machine

Install a Guest OS like you want it. I’ve installed Microsoft Windows Server 2003 R2 Enterprise Edition SP2 in English. Make sure to install the VMware Tools. If you are planning to use this virtual machine in an Active Directory domain, you need to have a way to change the SID of the cloned machine, as VMware Workstation, unlike vCenter Server doesn’t do that for you. I’ve copied ‘newsid.exe’ to the desktop for this purpose.

Marking the VM as a template

Enabling Template Mode is merely a protection against accidental deletion of the parent VM (i.e. the template).

Make a snapshot of the VM

[Show as slideshow]

Deploying a virtual machine based on a template

[Show as slideshow]

My home lab isn’t actually some server that I’ve got lying around. As I’m on the road a lot, I need to have my VMs with me at all times. That’s why I came up with the ‘bag lab’. A laptop mobile enough to carry around with me on a day-to-day basis, but powerful enough to provide me with the resources to build a complete VMware vCenter Site Recovery Manager setup (which requires 5x Windows 2003, 2x ESX, 2x NetApp Sim) on the laptop.

As I explained earlier, the machine I’ve chosen is a Dell Latitude E6500. While maxed out specifications-wise, I’ve even added some extra tricks, like the SSD and the tray to accommodate the second hard drive. I’ve used this laptop for a few weeks now, and I’m thoroughly impressed. I’ll try to explain how I’ve organized the OS, applications and various types of data to my liking, as well as experiences with the weight & size while on the road.

Software layout

The laptop has two storage devices. A 80GB SSD (SSDSA2MH080G2C1 with 02HD firmware for TRIM support) from Intel is used to accommodate the operating systems, all applications, virtual machine templates and linked clones based on these templates. Also, it runs a 10GB iSCSI Target (using the free StarWind iSCSI Target software).

The 250GB 7200RPM 2,5″ SATA disk (Seagate ST9250410ASG) is used to store data that does not need high transfer speeds, such as application installers and ISO’s (a semi-complete library of all VMware software), my music, video and picture collections. Also, a (slower but bigger) iSCSI Target of 25GB is placed on this disk.

With the virtual machines placed on the SSD, they are lightning fast. Because I am using the linked clone technology in VMware Workstation in combination with template virtual machines, I do not have to worry about used disk space. Cloned VMs only use a little bit of storage. A complete SRM setup, which requires five Windows 2003 VM’s, two ESXi machines and two NetApp Simulator take up only 14GB’s of disk space, including the parent template VMs.

From a disk performance view, the laptop is more than capable to run the aforementioned VMware vCenter Site Recovery Manager configuration. As always, the amount of available memory is a problem. Too bad this laptop doesn’t accept more than 8GB…

Weight and size

The E6500 is a big laptop. Measuring in at 14.1″ (358mm) wide, 10.1″ (257mm) deep and 1.5″ high (38mm) and weighing in at 6.6 lbs (3kg), you’ll notice you are carrying a mobile datacenter around. That God I’ve got just the right item for lugging it with me:

Comparing the weight and size with its performance, I have to say that it’s worth the trade-off:

Obviously, the laptop lacks serious strength in the graphics department. As I’m not a gamer at all, frankly, I couldn’t care less. More graphics power will only drain the laptop’s battery power even faster.

I’ve been meaning to dig into something technical for a long time as a more than welcome change in daily routine. I’ve been on the hunt for a new house (in Utrecht), have been busy with the VMware Enterprise Solution Provider partnership and did a complete rebuild of my internal Lab Manager environment. Also, I’m beginning my preparations for the VCDX Design Exam (which I’m going to take at the end of February). A couple of months ago, I visited the subject of RDM’s from a different angle (link), but now I wanted to give a more complete report on the matter.

What is a Raw Device Mapping?

The VMware VMFS filesystem supports a special type of file. This file, an RDM, is a mechanism for a virtual machine to have direct access to a LUN on the SAN. This LUN can be formatted in any way desired, without the need to format it to VMFS and place a VMDK on it. This removes two additional layers of complexity (the VMFS and the VMDK).

An RDM is a symbolic link from a VMFS volume to a raw LUN. The mapping 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 acts as a proxy for a raw physical device. This file contains metadata for managing and redirecting disk access.

When a LUN is opened for access, the mapping file is read to obtain the reference to the raw LUN. Thereafter, reads and writes go directly to the raw LUN rather than going through the mapping file.

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.

Although VMware recommends that you use VMFS datastores for most virtual disk storage, on certain occasions, you might need to use raw LUNs or logical disks located in a SAN.

Virtual Compatibility Mode

Virtual mode for an RDM specifies full virtualization of the mapped device. It appears to the guest operating system exactly the same as a virtual disk file in a VMFS volume. The real hardware characteristics are hidden. Virtual mode enables you to use VMFS features such as advanced file locking and snapshots. Virtual mode is also more portable across storage hardware than physical mode, presenting the same behavior as a virtual disk file. When you clone the disk, make a template out of it, or migrate it (if the migration involves copying the disk), the contents of the LUN is into a virtual disk (.vmdk) file.

Physical Compatibility Mode

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. Physical mode is useful to run SAN management agents or other SCSI target based software in the virtual machine. Physical mode also allows virtual-to-physical clustering for cost-effective high availability. LUNs attached to powered-on virtual machines and configured for physical compatibility cannot be migrated if the migration involves copying the disk. Such LUNs cannot be cloned or cloned to a template either.

Dynamic Name Resolution

Provides a user-friendly name for a mapped device. When you use an RDM, you do not need to refer to the device by its device name. You refer to it by the name of the mapping file, for example:

/vmfs/volumes/myVolume/myVMDirectory/myRawDisk.vmdk

This reference is permanent and will not change between reboots. VMFS uniquely identifies all mapped LUNs, and the identification is stored in its internal data structures. Any change in the SCSI path, such as a Fibre Channel switch failure or the addition of a new host bus adapter, can change the device name. Dynamic name resolution compensates for these changes by adjusting the data structures to retarget LUNs to their new device names.

User-friendly Persistent Names

Stores unique identification information for each mapped device. VMFS associates each RDM with its current SCSI device, regardless of changes in the physical configuration of the server because of adapter hardware changes, path changes, device relocation, and so on.

When do you use a RDM?

SAN-based features

If you are using SAN-based features, sometime you have no choice but to use a RDM. Examples are Dell/Equallogic’s VSS Writer for snapshot and backup purposes, NetApp’s SnapManager for Exchange/SQL and so forth. Using a RDM enables these kinds of software to ‘see’ inside the LUN and to create a consistent snapshot of the data contained within the LUN. This allows for replication of data (snapshots) to a second SAN (on a different physical location) for Disaster Recovery. These types of software do require communication with the application, thus usually require an agent inside the VM. With VSS, the ‘agent’ is installed by default by the Guest OS, as it is a Windows feature.
It might also be use to create backups of the data on those LUNs in a much more efficient way as compared to traditional backup agents or even VM-based snapshots (using VCB or the vStorage API and Data Recovery). With these techniques, say, your Exchange database is backed up using resources (i.e. the hardware) of your SAN and thus relieving the hypervisor of any backup or snapshot tasks. This is also known as off-host backups. Depending on your environment, you can either use a physical backupserver (and integration between the backupsoftware such as Symantec Backup Exec and the SAN such as Equallogic), a NDMP-enabled VTL or a second SAN.
Also, in-band management software for your SAN running in Virtual Machines might require direct access to a management LUN. This usually requires physical compatibility mode.

Clustering

A second reason why you would want to use RDMs is in the case of a clustering service, such as Microsoft Clustering Services, Heartbeat and Novell Clustering Services (based on Heartbeat nowadays). There are three types of clustering, each with its own requirements on the storage side, which I will explain below.

Big ol’ disks

The last case for RDMs is ‘big datadisks’, with which you feel uncomfortable having it all in a single VMDK. In the words of Duncan Epping, ‘large’ is a disk larger than 800GB. This however does not mean that any virtual disk larger than 800GB should be a RDM. You could, for manageability and other reasons, create a dedicated VMFS Datastore with just this VMDK. Choosing between either is a matter of requirements as mentioned above and confidence in the technical feasibility of RDMs.

Requirements and limitations

• Blockbased storage. Both iSCSI and FC are supported. No NFS. No local storage. You need a VMFS datastore to store the mapping file.
• No partition mapping – RDM requires the mapped device to be a whole LUN.
• You cannot create a snapshot of a Physical Compatibility Mode RDM.
• You cannot enable Fault Tolerance for a VM using a Physical Compatibility mode RDM.
• VCB cannot backup a RDM in Physical Compatibility mode.
• VMware Data Recovery cannot backup a RDM in Physical Compatibility mode.
• When using VMware vCenter Site Recovery Manager, make sure you include both the raw LUN as well as the VMFS datastore holding the mapping file to SAN replication schedules. Placing the mapping file alongside the VMX file is highly recommended.
• VMware vCenter Server does not support LUN number changes within the target. When a LUN number changes, the vml identifier does not change accordingly. Remove and rebuild the RDM to generate a new vml ID that the LUN recognizes as a workaround.
• The maximum size of an RDM is 2TB minus 512 bytes.
• Use the Microsoft iSCSI initiator and MPIO inside the VM when you need more than 2TB on a disk.
• You cannot use a RDM (in conjuncture with NPIV) to give a VM access to a VMFS volume. This seems to make no sense at all, unless you want to run your VCB proxy as a virtual machine to access Fibre Channel LUNs. For iSCSI, you can still use the software iSCSI Initiator in your Guest OS. Mental note: obviously, it isn’t supported at all.

Compatibility with…

Storage VMotion and cold migration

A RDM can be included when you perform a Storage VMotion or cold migration. When using Physical Compatibility mode, only the mapping will be migrated (choose ‘Same as Source’ in the Migration Wizard). When using Virtual Compatibility mode, the raw disk will be migrated to either a thin provisioned or thick VMDK disk. Physical Compatibility mode RDMs cannot be migrated to a VMDK file. RDM converted to VMDK virtual disks cannot be converted back. Please note that NFS is not supported as a destination for a RDM disk migration. Use an intermediate step (Storage VMotion to a VMFS volume, either local or on an iSCSI/FC SAN) as a workaround.

RDM’s are fully supported for normal VMotion operations.

N-Port ID Virtualization

Makes it possible to use the NPIV technology that allows a single Fibre Channel HBA port to register with the Fibre Channel fabric using several worldwide port names (WWPNs). This ability makes the HBA port appear as multiple virtual ports, each having its own ID and virtual port name. Virtual machines can then claim each of these virtual ports and use them for all RDM traffic.
NPIV is supported only for virtual machines with RDM disks. Virtual machines with regular virtual disks continue to use the WWNs of the host’s physical HBAs.

Clustering

There are a couple of different ways to build a cluster environment, each with its own requirements on the storage side:

Cluster-in-a-box

Most often used for test- and development use cases, this type of clustering has two or more VM’s running on the same physical box. You can use both kinds of RDMs, as well as VMDK’s. VMware recommends using VMDK virtual disks, unless you are using Microsoft Clustering, in which case you need to use a RDM. I would recommend Physical Compatibility mode.

Cluster-across-boxes

Instead of running all cluster nodes on a single physical box, you run the VM’s across multiple physical boxes. This requires either type RDM. VMware recommends Virtual Compatibility mode. In the case of Microsoft Clustering Services, use Physical Compatibility mode.

Physical-to-Virtual Cluster

Using both physical boxes (without hypervisor) and virtual boxes requires the use of Physical Compatibility mode RDMs.

For Microsoft Clustering Services, there are some extra caveats. For instance, using Windows Server 2008 in a Failover Cluster scenario, you cannot use Virtual Compatibility mode. For clustered Continuous Replication Environment for Microsoft Exchange: use Physical Compatibility mode. Also, iSCSI is still not supported. You’ll need to use Fibre Channel.

FAQ

If using a RDM, what is written to physical disk regarding information about the RDM?
Nothing, the LUN contains only information about the filesystem the Guest OS formatted it with. There is no additional data on the disk.
Can I use a local disk as a RDM?
No, local RDM’s are not supported. Using the vSphere Client, you cannot assign local storage as an RDM to a VM. There are ways to achieve local RDM’s, though, for instance, connecting a SCSI device using SCSI-passthrough.
Can I detach a RDM and attach the LUN to a physical server?
Just like using normal LUNs or even simple external USB hard drives: yes you can, but it is up to the OS to whom the LUN is attached if this will work without a hitch. For the usual filesystems like NTFS, EXT3, ZFS and NSS, this is no problem at all.
How is a RDM presented to the Guest OS in a VM?
The Guest OS sees a local SCSI hard drive, just as it would when using a VMDK or Guest OS initiated iSCSI connected disk. Depending on the chosen compatibility, the Guest OS would see a ‘VMware Virtual SCSI Disk Device’ or a disk named by the storage array (it would be likely to have the vendor’s name somewhere in there).
Can I use RDM-like features on other products than vSphere?
Sure you can. VMware Workstation can give access to a complete LUN (or physical disk) or partitioned parts of a disk.

Sources for this blogpost

• Introduction to VMware vSphere
• vSphere Basic System Administration
• ESX Configuration Guide
• vSphere Availability Guide
• Fibre Channel SAN Configuration Guide
• VMware Data Recovery 1.1 Administration Guide
• VMware vCenter SRM 4 Release Notes
• VMware vCenter Server 4.0 Update 1 Release Notes
• Configuration Maximums for VMware vSphere 4.0
• Virtual Machine Backup Guide
• Setup for Failover Clustering and Microsoft Cluster Service
• 2vcps and a Truck: Using iSCSI to get some big ole disk in a Virtual Machine
• The VMguy: vSphere and MSCS
• Virtual Black Hole: To Use RDM’s or Not To Use RDM’s
• boche.net: Setup for Microsoft cluster service
• Leo’s Ramblings: Deciding between iSCSI RDMs and the Microsoft’s iSCSI initiator

Besides the two Labs I have at work, I’ve gotten myself a new laptop to use as a lab-inbetween-home-and-work-lab.

Hypervisor Lab @Work

Two Dell PowerEdge T605 (see my previous post)

Lab Manager @Work

We’re running Lab Manager on three Dell PowerEdge 1950′s (16GB RAM, dual core Xeon’s) and a Dell/EMC AX150i with 12×500 GB SATA. Nothing really fancy, but an adequate solutions for our training and testing purposes.

Mobile Lab @Bag

A brand new Dell Latitude E6500

• Intel Core 2 Duo P9700
• 8GB 800MHz DDR2 RAM (2x 4GB)
• 250GB SATA-II HDD 7200RPM
• 15.4″ Wide Screen WUXGA (1920×1200) 2CCFL
• Mobile Intel GMA X4500HD
• Intel WiFi Link 5100 (802.11 a/g/n 1X2) 1/2 MiniCard with Centrino label
• US/Int – Internal Qwerty LED Backlight Keyboard
• 6 Cell 54WHr LI-ION Primary Battery
• Microsoft Windows 7 Ultimate (x64, English)
• 8x DVD+/RW Drive

I’m planning to replace the DVD-drive with an caddy with an Intel 80GB SSD: