Windows 7 x64

We are installing a few Windows 7 x64 VM to continue testing VMware View 4.5.

Due to some limitations on the previously decommissioned cresskill, only Windows 7 x32 will go on this puppy.

Maintenance Day

Today will see backups of vCenter, Installation of a (additional) 1TB drive in westwood, the decommissioning of cresskill (utility ESXi 4.1 host), and some data backups.

The additional 1TB of space will be used for additional VMFS space as well as for the testing of OpenFiler for iSCSI shared storage.

Uber backdoor Gig-E not up

Ran into a minor issue with Uber that has been here ever since Uber was moved from cresskill to northvale ESXi hosts. Decided to look into it.

The symptom was that northvale (or any of the ESXi hosts) never recognized shared storage on Uber and showed the Datastores as grayed out. This would also cause the VM's using the shared storage to be disconnected and inaccessible.

After some investigation this morning, it was found that the 2nd network card in Uber VM, that connects the iSCSI and NFS shared storage to the back door Gig-e would not come up without a forced sudo ifup eth7 command to bring it up.

We first attributed this to a race condition of the northvale host coming up completely and doing it's scan for storage before the launch of Uber. This may still be the case for iSCSI.....

Anyway, for those following along, you will remember that all VM's were moved from the utility host (cresskill) to northvale since we needed to move to Win2k8 x64 for vCenter Server and cresskill does not support x64 VM's.

Uber was the last to be moved. When a Ubuntu VM is moved, the NIC cards become different eth numbers. Some fun was had (and documented) getting the correct eth numbers set on Uber. The file "/etc/network/interfaces" on Uber had to be modified to update the eth numbers after the move. Of course, there was a typo in the update for eth7, causing it to fail to load at boot.

Once corrected, Uber's back door Gig-e was loading properly. After a reboot, northvale now recognizes the NFS and iSCSI shares from Uber once Uber is up.

PCoIP working properly

Now that the agent issues are resolved, some preliminary testing shows that the PCoIP issues experienced with View 4.0+ are resolved. Obviously, more testing is needed to make sure other issues have not popped up.

View vDesktop not recognized

After some testing of the failed vDesktop, we were unable to find anything wrong with the installation of the agent.

Finally, the primary connection server was bounced and the vDesktop agent was recognized. This is not a good story, saying that when a new vdesktop is provisioned, the only way to add it to a pools is to restart the primary connection server. More testing is needed to validate this.

VMware View 4.5

Moving forward on the VMware upgrades, the primary connection server (Piermont) was updated to version 4.5. This update went in with much fanfare and the new GUI web site seems to be much better designed and has faster response than the 4.0 version.

All settings (Pools, Desktops, etc.) and configurations seem to have transferred properly. However, booting on of the vDesktops was vary slow so we reverted to a snapshot, which may have caused some recognition issues inside of View 4.5.

The 4.5 agent was removed and reinstalled, but View is still unable to recognize the agent. More troubleshooting is needed.

Citrix XenCenter

Once on the console of win2kmove1 VM, we surfed to the XenServer web server and attempted to install the XenCenter app, where we received a pop-up stating that .NET Framework 2.0 SP1 was required.

After installing this piece, the same error is being reported. a little searching found that installing .NET Framework 3.5 SP1 allowed us to install XenCenter.

Launching the XenCenter app, we were able to add XenServer, however, the server does not have access to the back door Gig-e, where the shared storage resides. Will need to add a 2nd vNIC to XenServer for this to work.