Virtualinfo
 

Site sponsor

 

The “Project Virtual Reality Check” team just released a new whitepaper: “Hyper-V 2008R2, vSphere 4, XenServer 5.5 on Intel ‘Nehalem’ Xeon 5500“. 

 “If you are looking for an independent advise and a ‘Reality Check’ in relation to Virtualizing Terminal Server and Desktop workloads, if you are curious about the impact of different hypervisors and the performance differences with various hardware and if you are searching for best practices for your virtual Desktops … Project VRC whitepapers are a must read!”
The whitepaper contains: 
  • Highlights, performance differences and best practice conclusions for Terminal Services workloads on:
    • Bare metal Terminal Services; 2003/2008/x86/x64
    • Hypervisors: Citrix  XenServer 5.5, Microsoft Windows Server 2008R2 ‘Hyper-V’ and VMware vSphere 4.0
    • Performance impact using different HP Proliant state-of-the-art hardware using Intel Xeon ‘Nehalem’ x5500  Read the rest of this entry »

ThinApp licensing

posted by Sven Huisman
February 10, 2010

Yesterday during VMware vForum I was asked how ThinApp was licensed. I did know that ThinApp was licensed per device. But what does that mean, per device? What if I use the ThinApped applications on Citrix XenApp servers, do I have to pay a license per Citrix XenApp server? What if I put the ThinApp license on a USB-device? This knowledgebase article is clear about ThinApp licensing:

Not a lot of info is found when you Google for manually selecting/fixing the primary HA nodes in a VMware VI or vSphere environment. Of course Duncan Epping has a couple of extremely interesting posts on Yellow-Bricks.com concerning HA even when it comes down to selecting or promoting the HA status of ESX nodes (a must read!), but I want more …

Let’s start with what I assume to know about HA:

- HA works with primary and secondary HA nodes
- The primary nodes are aware of the states and configs of all nodes in an HA cluster
- The secondary nodes depend on the primary nodes
- There is an supported limit of 5 primary HA nodes per cluster
- The first 5 ESX hosts that are added in a HA cluster are initially defined as primary HA nodes
- All the other hosts that are added to the HA cluster are configured as secondary HA nodes
- There’s a way to configure a HA node as primary or secondary, however it’s not possible to configure an ESX host as a “fixed” primary HA node:
Read the rest of this entry »

VMware View and ThinApp Integration Guide

posted by Sven Huisman
January 25, 2010

Aaron Black from VMware posted a VMware View and ThinApp Integration Guide on his blog.

“The guide discusses several of the topics covered in the previous posts but brings it all together with some task based scenarios that walk you through initial setup and configuration with screenshots and sample scripts.”

The guide should give answer to the following questions:

  1. Should I stream all my ThinApp packages from a fileshare or deploy them into the VMs?
  2. Where you I put my ThinApp packages? On the C:, the User Data Disk, a fileshare?
  3. How do I manage updates after the packages are in use?
  4. Will users keep their unique settings like toolbar buttons when running ThinApps from different desktops?
  5. How do I manage shortcuts and FileTypeAssociations for multi-user VMs?

It’s a straight-forward guide and it describes the different setup tasks between Persistent and non-persistent desktop.

vSphere bug can bring down entire cluster (not fixed in Update1).

posted by Matthijs Haverink
January 22, 2010

Last month I was on-site at one of my customers and experienced a major problem on the vSphere environment. We suddenly experienced about 150 virtual servers running on 16 hosts in 2 clusters (on the same SAN) going in jabber-mode. They froze, which made them unavailable for pings and other traffic. The freeze moment varied from 1 to 30 seconds. After that the VM’s went back on-line again. This seemed to happen in groups of about 10 to 30 VM’s.

Pretty soon we saw in the logs that a VMFS LUN was removed by one of the SAN administrators. This LUN was still attached to all the ESX hosts in that cluster but was not “in use”, meaning, there were no VM’s running on it.

Off course the unclean removal on SAN-level of a LUN before detaching it from the ESX hosts is not the way to do this but that what I just described shouldn’t have happend!

The quick solution was Read the rest of this entry »