Yellow Bricks

by Duncan Epping

ESX

Exchange (2007)on VMware

· ·

I had to prepare a meeting on virtualizing Exchange 2007 on a VMware VI3.5 environment. While searching the internet I found an enormous amount of pdf’s and whitepapers and decided to share them with you:

VMware.com:

VMworld.com:

(You’ll need an account to access the VMworld material)

Cisco / EMC / VMware:

VMware Technical papers

· ·

VMware lately published a whole bunch of must read technical papers:

Storage Design Options for VMware Virtual Desktop Infrastructure

Companies planning to deploy VDI face decisions about the use of both local and shared storage,
and in the case of shared storage solutions, choosing between differing technologies available in
today’s market. Selecting the appropriate storage model is important for both performance and costs reasons. Certain solutions require less overhead than others, as do different implementations of the same technology. Costs can vary greatly depending on which storage options are chosen. Fortunately organizations can leverage a myriad of best practices to help drive these costs down, while improving performance. This paper provides information on technical concepts related to storage implementations in a VMware ® Virtual Desktop Infrastructure ( VDI) environment.

VMware View Reference Architecture Kit

This reference architecture kit is comprised of four distinct papers written by VMware and our supporting partners to serve as a guide to assist in the early phases of planning, design and deployment of VMware View based solutions. The building block approach uses common components to minimize support costs and deployment risks during the planning of VMware View based deployments.

SQL Server Workload Consolidation

Database workloads are very diverse. While most database servers are lightly loaded, larger database workloads can be resource-intensive, exhibiting high I/O rates or consuming large amounts of memory. With improvements in virtualization technology and hardware, even servers running large database workloads run well in virtual machines. Servers running Microsoft’s SQL Server, among the top database server platforms in the industry today, are no exception.

Using IP Multi Cast with VMware

IP multicast is a popular protocol implemented in many applications for simultaneously and efficiently delivering information to multiple destinations. Multicast sources send single copies of information over the network and let the network take responsibility for replicating and forwarding the information to multiple recipients.

HA: who decides where a VM will be restarted?

· ·

During the Dutch VMUG someone walked up to me and asked a question about High Availability. He read my article on Primary and Secondary nodes and was wondering who decided where and when VM would be restarted.

Let’s start with a short recap of the  “primary/secondary” article: “The first five servers that join the cluster will become a primary node, and the others that will join will become a secondary node. Secondary nodes send their state info to primary nodes and also contact the primary nodes for their heartbeat notification. Primary nodes replicate their data with the other primary nodes and also send their heartbeat to other primary nodes.”

The question was, when a fail-over needs to take place cause an isolation occurred who decides on which host a specific VM will be restarted. The obvious answer is one of the primaries. One of the primaries will be selected as the “fail-over coordinator”. The fail-over coordinator coordinates the restart of virtual machines on the remaining hosts. The coordinator takes restart priorities in account. Keep in mind, when two hosts fail at the same time it will handle the restart sequentially. In other words, restart the VM’s of the first failed host(taking restart priorities in account) and then restart the VM’s of the host that failed as second(again taking restart priorities in account). If the fail-over coordinator fails one of the primaries will take over.

By the way, this is another reason why you can only account for 4 host failures. You need at least 1 primary, this primary will be the fail-over coordinator. When the last primary dies….

Create VMFS volumes from the command-line

· ·

I just had to create a couple VMFS volumes from the command-line on a local disk. It’s pretty straight forward but I needed to document it anyway, here it is:

  1. fdisk -l (check what the last partition is)
  2. fdisk /dev/sda
  3. n (new)
  4. default (start block)
  5. default (end block)
  6. t (partition type)
  7. 10 (partition 10, just created)
  8. fb (vmfs type)
  9. w (write config)
  10. reboot (Reboot the host before you format the newly created local partition)
  11. vmkfstools -C vmfs3 /vmfs/devices/disks/vmhba0:0:0:10
  12. Go to VI Client, Refresh storage view and rename the newly created volume
You can align the VMFS volume as follows, before you do step 9:
  1. X
  2. b
  3. 1
  4. 128 (disk alignment, check your SAN manual for the correct value, 128 is correct in most cases…)
  5. W

VM’s may unexpectedly reboot when using VMware HA with Virtual Machine Monitoring

· ·

This KB article has just been published:

Virtual Machines may unexpectedly reboot after a VMotion migration to an ESX 3.5 Update 3 Host OR after a Power On operation on an ESX 3.5 Update 3 Host, when VMware HA feature with Virtual Machine Monitoring is active.

There’s a work around for the problem but I will not be posting them here cause they might change somewhere in time. Just read the KB article for more info on how to fix this issue.