VM /ETC

Posts Tagged ‘esx’

VMware announced the U2 (update 2) release of ESX 4.0, and unfortunately early adopters quickly discovered VMware View virtual desktop connections using the PCoIP protocol were failing. This post provides some quick info on both the new release and the new VDI problem it creates.

UPdate 2 Info

VMware ESX 4 Update 2 is available for download here. The following is a cut and paste of What’s New from the Release Notes:

• Enablement of Fault Tolerance Functionality for Intel Xeon 56xx Series processors— vSphere 4.0 Update 1 supports the Intel Xeon 56xx Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel Xeon 56xx Series processors.
• Enablement of Fault Tolerance Functionality for Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors— vSphere 4.0 Update 1 supports the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors.
• Enablement of IOMMU Functionality for AMD Opteron 61xx and 41xx Series processors— vSphere 4.0 Update 1 supports the AMD Opteron 61xx and 41xx Series processors without input/output memory management unit (IOMMU). vSphere 4.0 Update 2 enables IOMMU functionality for the AMD Opteron 61xx and 41xx Series processors.
• Enhancement of the esxtop/resxtop utility— vSphere 4.0 Update 2 includes an enhancement of the performance monitoring utilities, esxtop and resxtop. The esxtop/resxtop utilities now provide visibility into the performance of NFS datastores in that they display the following statistics for NFS datastores: Reads/s, writes/s, MBreads/s, MBwrtn/s, cmds/s, GAVG/s(guest latency).
• Additional Guest Operating System Support— ESX/ESXi 4.0 Update 2 adds support for Ubuntu 10.04. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.
• Resolved Issues – In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.

PCoIP Connections Issue

The following cut and paste is from the VMware KB Article Upgrading VMware Tools in a virtual desktop causes PCoIP connections to fail: Read the rest of this entry »

The vSphere Enterprise Plus vNetwork Distributed Switch (vDS) has been heralded as, and I might add lives up to it’s reputation of, an administrator’s time saver and single point of virtual networking configuration and visibility across many ESX/ESXi 4 hosts. However, the vDS presents some administrative challenges unique from the traditional vNetwork Standard Switch (vSS) that admins are used to. Specifically, since the vCenter 4 Server actually maintains the vDS configuration, some extra design thinking needs to be built into a vSphere 4 environment where a vDS will be used. If vCenter 4 Server itself will be a virtual machine in the environment with a vDS, the design gets even more involved.

There are a few possible problems to consider. In this post I’ll first cover (with the help of a several others) general VM and vCenter vDS networking issues, but along the way I’ll explore thoughts about designing around a vDS for keeping vCenter as a VM.

Read the rest of this entry »

http://kb.vmware.com/kb/1010718 explains the normal way for disabling and removing a VMware ESX/ESXi vNetwork Distributed Switch (vDS or DVS or VDS – LOL), but when I recently tried to do so I received the following error:

“The resource ’1′ is in use. DVS [vDS Name] port 1 is reserved by to entity <not-found.> vnic 4000, type:vmVnic”

The screen shot shows the actual error I received.

After thinking about that message, I decided to check to see if any ports were in fact being used on the vDS. Although PortID 1 dvPortGroups did not show it being used as expected, other PortIDs were, in fact, in use. See image below.

I tried messing around with disabling the ports (blocking was the terminology in the vSphere Client, I believe) but I still could not delete the vDS. It was Saturday and I had family stuff to do so I reluctantly gave up at the time. However, 3 days later I was able to easily remove it via the Remove link on vDS Configuration screen just like I was supposed to be able to do all along. Needless to say I was a bit perplexed.

After researching I discovered that

Read the rest of this entry »

I received an email today from VMware addressed to all customers about the end of availability for VMware Consolidated Backup (VCB). Quoting from the beginning of the communication but not the entire message, it reads:

“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).”

[omited]

I’ll go out on a limb and say that most of the VMware community will

Read the rest of this entry »

If you are looking at various options to automate virtual machine (VM) ip address reconfiguration when failing over virtual machines to a disaster recovery (DR) site, this post explains an option so simple it is beautiful. To give full credit, the Vizioncore vReplicator 2.5 Best Practices document enlightened me to the strategy of using a local only VMware vSwitch and an extra virtual NIC (vNIC) in each VM. It’s been a long time since I had a “ton of bricks” moment, but this concept crashed down on me with the realization of a configuration that works in any version of ESX, doesn’t require extra software or hardware, and better yet, doesn’t have to be scripted! Just configure some extra virtual networking and forget about it!

Here is a general outline for automating the DR ip addressing with this method:

At the Primary Site

• For these instructions assume the production vSwitch at the primary site has a Portgroup named VM Network
• Build a new vSwitch and do not attach any physical NICs (local only isolated switch). Create a Portgroup named DR Network
• For each VM you need to fail over to a DR site, add an extra vNIC and attach it to the DR Network Portgroup

At the DR Site

• Create your DR site production vSwitch, attach physical NICs and add a Portgroup named DR Network.
• Create another vSwitch and do not attach any physical NICs (local only isolated switch). Create a Portgroup named VM Network

All you have to do for this to work is

Read the rest of this entry »

The VMGuy has the scoop on all the VMware releases tonight! VMware has also made available an updated version of the GUI based virtual machine (VM) backup and restore plugin for vCenter 4, VMware Data Recovery 1.1 (VDR). Download it here and check the check the Release Notes here.

VMware is saying VDR has improved performance and progress information during intgregity checks, enhanced CIFS support, and that the previous experimental support status for File Level Restores of Windows VMs has been elevated to full support.

Although I could find no mention of it on the VDR web page, the data sheet, or in the new Release Notes, VDR was originally targeted for virtual infrastructure that hosted up to 100 VMs. I’m not sure if this VMware support limitation is still in effect or not.

Still, combined with the already built in de-duplication of VDR VM backups, SMBs have a great VCB alternative that continues to improve.

It was speculated that it might not happen until next week (Monday 11/23), but VMware engineer Dave Lawrence’s post Release: ESX 4.0 Update 1 on his VMGuy Blog confirms that ESX 4.0 U1 is now available for download. The most notable changes in this update include full support for VMware View 4 (expected to be available for download on 11/23), full support for Windows 7 and 2008 R2 in both 32 bit and 64 bit flavors, and an update to the vSphere Client that fixes the problem when installing on Windows 7 desktops – eliminating the need for the workaround VI admins have had to configure until now.

Go here for the full Release Notes that explain other new changes such as enhanced MSCS support, enhanced paravirtualized SCSI support, improved Distributed Switch performance, increased vCPU core limits, Intel Xeon 3400 CPU support, and several resolved issues.

VMware has also released vCenter 4 U1 tonight with matching support for View 4 along with Windows 7 and 2008 R2. The Release Notes indicate a few other goodies can be found in the vCenter update:

• Pre-Upgrade Checker Tool — A standalone pre-upgrade checker tool is now available as part of the vCenter Server installation media that proactively checks ESX hosts for any potential issues that you might encounter while upgrading vCenter agents on these hosts as part of the vCenter Server upgrade process. You can run this tool independently prior to upgrading an existing vCenter Server instance. The tool can help identify any configuration, networking, disk space or other ESX host-related issues that could prevent ESX hosts from being managed by vCenter Server after a successful vCenter Server upgrade.
• HA Cluster Configuration Maximum — HA clusters can now support 160 virtual machines per host in HA Cluster of 8 hosts or less. The maximum number of virtual machines per host in cluster sizes of 9 hosts and above is still 40, allowing a maximum of 1280 Virtual Machines per HA cluster.