I have collected quite a few updates over the last few weeks since VMworld ended, and now I should make them. However, the most important non-security update for me is the one for VMware Horizon View. My View environment is old, and though it is maintained, I am in need of several upgrades to Windows, View, and underlying bits. Given that I have nearly everything installed within my environment (except vCAC and vCD at the moment), it is time to find the proper upgrade order. Continue reading vSphere Upgrade Saga: Update Order
I use VMware Horizon View as an outside-in approach to VDI. That being said, once I upgraded to vCenter 5.5, I broke my Horizon View integration. This showed up about a month after the upgrade as a failure to log in to a desktop. But before I could find a solution, I had to look at all the changes I made, because this error showed up only after I updated my VMware vSphere Distributed Switch (VDS) to a 5.5 VDS. Continue reading vSphere Upgrade Saga: vCenter 5.5 w/Horizon View
I recently had an issue where my VMware View instances ceased to talk to my active directory server. As such, I thought they needed to be recomposed, but I also had to upgrade the VMs with a bunch of patches. So being the smart guy I am, I deleted the View desktop VMs and started over.
There are two ways to solve the issues with dvSwitches I spoke about before. The first is to place vCenter onto an administrative per host vSwitch. The second is to create new dvSwitch portgroups but first ensure the portgroup is marked as ephemeral. But if you already have portgroups, how would you migrate from one portgroup to these ephemeral portgroups. In theory, ephemeral ports do not require vCenter to be active in order for a port assignment to take place. So how do you migrate from Static dvSwitch portgroups to Ephemeral dvSwitch portgroups?
It sounds like a difficult process but all in all it was not. All I did, as per Figure 1 was to add a new portgroup with a different naming convention and make it an Ephemeral port binding portgroup. Then all there was to do was to migrate the VMs from the old port-group to the new port-group.
In theory this should be all I need to avoid the issues with the default static binding. Such as not Failing-Safe but failure to boot VMs when vCenter is no longer around.
An alternative was to create an administrative regular vSwitch per node, which you can see in Figure 1, is the approach I originally took. But given that I like alternatives, this is definitely one method to take. In a resent reboot of my blade servers OA, this approach seems to work just fine for those VMs already switched over, but then again I do ensure vCenter and those VMs it requires boot first on a standard vSwitch. So I have not lost any functionality, but have gain some if vCenter is not running for any reason.
I recently upgraded my entire infrastructure. The cost of going to 3 new servers at the latest hardware compared to going to a blade center was finally equal. In general, 3 2U DL380s are less expensive than upgrading to a c3000 blade enclosure and over the last several years I have been fighting with this decision. Finally, it was made for me. The price was attractive enough. 3 Blades were purchased with space for 5 more available within the enclosure. This upgrade-ability is what pushed me over to blades from the lower cost DL models. Continue reading vSphere Upgrade: Moving to a BladeSystem
Read the ongoing saga of the next phase of the upgrade on the Network World Blue Gears site.