Let me start off by stating that this is NOT supported…..

I wanted to attach a local drive to a VM, but wanted the ability to move this drive to a physical Windows server at a later time without the time consuming data migration or drive reformatting. Although there is no way to do this through the VIC, there is a way to do this in the console.

First we need to find the disk we want to use as an RDM. This is accomplished by running the following:

ls -al /vmfs/devices/disks/

In this example the disk I needed was vmhba0:1:0:0….. Take note of  the string starting with vml.

Now we need to create the placeholder vmdk we will attach to our vm. We do this with the following command:

vmkfstools -r /vmfs/devices/disks/vml.<String we retrieved above> /vmfs/volumes/<Existing DataStore>/<VM Path>/<NAME>.vmdk

Now the only thing we need to do is to add the existing disk to our VM. You will notice the summary shows the new disk as a “Mapped Raw LUN”

Fire up the VM and format the disk for whatever file system you require.

Enjoy

     I have been working in the application consultancy for quite some time and it is hard to remember the last architecture or implementation I have done that has not included VMware. For many of my customers, this was the first time the virtualization concepts became a reality within their datacenter. Although they were aware of virtualization, they had some animosity and overall fear that this technology could actually perform “real” workloads.  Often times it took some hard convincing before they would actually accept the proposed architecture.

     Like most, once the implementation was complete and they could actually touch, feel and interact with this new architecture, they quickly gained confidence and were looking for other avenues to leverage their new found love for virtualization. The biggest problem my customers faced was still maintaining the belief in dedicated resources for specific applications. They would deploy silos of ESX servers to support a specific application needs (SharePoint, Exchange, etc…). While this appears to be a logical approach, it does not leverage the virtual infrastructure to it’s fullest. Yes, they are able to achieve server consolidation and a reduction of power, HVAC, and rack space, but they cannot fully appreciate the drive to maximum utilization of their computing resources.

     The hardest thing to communicate to customers new to virtualization is that they not only remove the OS from the hardware, they also remove the dedication of assets from applications. Most customers maintain separate shops for applications. These divisions not only own the applications, but the hardware they are running on as well. It is hard to convince an Exchange admin that they no longer have to worry about which physical “box” their application is running on.

     I often try to communicate this new ideal by leveraging what my customers currently know about their SAN. They have a centrally managed set of disk resources that are presented and consumed by an application. The application admin, although they know how much storage they can use, cannot point to a rack of disks and show you which physical drives they actually “own”. With virtualization, computing resources can be managed in much the same way.

     With virtualization, physical servers are grouped together in a cluster, much like the physical drives in a SAN. The resources of these servers can than be managed as a single entity and presented to applications based on their requirements. These clusters can be leveraged to drive maximum utilization of the physical resources, while maintaining application requirements regardless of which “box” they are running on. This allows the individual application owners to focus on their application and remove the physical requirements they previously had to manage.

     While the end goal is not always achieved quickly, most customers are evolving their virtual infrastructure and driving toward  this end. Once they see the benefits virtualization brings to the table, the long term vision starts to become reality. Removing the physical boundaries normally associated with application deployment, maintenance and disaster recovery allows my customers to not only see a reduction in operating costs, but they also achieve less downtime and easier management.

Hal Rosenberg has released a document to the VMware Communities titled “Performance Troubleshooting for VMware vSphere 4”. Hal’s document utilizes a flow chart approach in order to identify specific performance issues. For each problem covered, it includes a discussion of the possible root-causes and solutions. It is a must read for anyone administering a vSphere environment. Thanks Hal. You can find his post and download link here

     My team was deploying a new SharePoint portal for a customer and were seeing some strange behavior from some of our VMs. Our environment consisted of 3 BL685 servers running ESX and 9 VMs ( I know this is overkill, but our customer was very wary of the portal performance in a virtual environment, and our hope was to introduce a platform that could lead them into further virtualization and server consolidation). We were receiving some rather “interesting” errors while adding domain users to the local administrator group of some of the machines. While doing a “check name”, AD would return the account name along with some non-printable characters ( blocks, smiley face, etc…). We were also having issues copying files to the VM through UNC. Some would copy, others would not stating “source no longer available”. We were not seeing this behavior across all the VMs, which was disturbing as they were all deployed from the same template. We did manage to narrow it down to guests running on just one of the hosts.

     My initial thought was the possibility of bad memory installed on this host. After running some memory tests and the eventual replacement, our errors continued. We then replaced the host with another blade and swapped the hard drives so we wouldn’t need to reinstall ESX. After powering up the host and migrating a couple of VMs back, we were astonished that the issue still remained. It was then that we reinstalled ESX as we thought that was the only thing left.

   After reinstalling ESX, it was then that we found some additional problems. We added the host to the cluster and were attempting to configure HA. This would fail at random intervals with often different errors including, path not found, SSL errors, and others. It was at this point my attention turned to the network. This server was configured with 2 NICs with all network trunked and vlan tagged. I disabled one of the NICs and all traffic continued to work. I switched over to the remaining NIC and everything came to a halt. Finally, it looked like we were narrowing down the cause. When the blade was swapped out, the NICs were moved from the original. We swapped out the NIC and everything worked as advertised.

Although the initial errors did not point to the network, after all other troubleshooting did not result in success the NICs were the only thing left.

Forbes Guthrie over at vReference has provided some absolutely necessary documents for anyone working with/designing a virtual infrastructure.

• VI 3 Reference Card
• VI 4 Reference Card
• vSphere 4 Notes
• vSphere Connection Ports

Please give Forbes full credit as I am only placing these here for convenience.