Virtually Jason

I’ve been working with Unidesk lately, as well as with the vSphere PowerCLI .  One of my customers has also been having an intermittent issue where they cannot browse their datastores (it just sticks at “Searching Datastore…” until they lose patience and close the window).  All of this has gotten me thinking about the relationship between vCenter and the ESXi hosts.  When we send a command to vCenter, such as creating a new VM, we all know that vCenter is simply relaying that command to one of its ESXi hosts, which does the actual work.  Same thing with file copies through the Datastore Browser, and in fact even reading the datastores through that same tool. How do we, as administrators, know which ESXi Host vCenter is using as its “workhorse”?  In a clustered environment, it’s really very unclear.  It turns out that, if that workhorse ESXi host is having an issue, it may prevent a lot of those basic vCenter functions from working (such as the aforementioned “searching datastore

One of my customers deleted their Unidesk desktops from the View Administrator again and, once again, the system happily deleted a layer from the CachePoint.  This causes a problem in that you can no longer build desktops on that CachePoint that use that Layer (read that linked older post if you want more detail about that situation).  Last time this happened, we knew which Layer was affected because it was a rarely assigned application, but this time we didn’t have any such indicator.  We went through a discovery process this time that we didn’t go through last time and we came up with a far easier solution this time, so here’s the scoop. First, we had to figure out which Layer was affected.  To do so, I used the Datastore Browser in the vSphere Client.  I knew which CachePoint was missing the Layer, for that CachePoint was the one that was failing to build out the desktops.  I simply Browsed the datastore that that CachePoint manages, as well as the datastore that houses the M

One of my customers has been having an intermittent issue with their Windows 7 VDI Desktops.  Occasionally after they update the Operating System, when the desktops boot back up they fail to use their NICs.  The NIC is still attached to the VM and is still on the right network, but Windows fails to recognize it (it doesn’t get a DHCP address and, in fact, registers within the OS as being physically disconnected from the network).  Restarting the desktop doesn’t help, reinstalling drivers doesn’t help (we’re using the VMXNET3 network adapter, for those who are interested).  Removing the adapter from Windows seems to be the key to getting the desktop back online.  We’ve gotten desktops back online by removing the adapter from Device Manager and then scanning for hardware changes (and rebooting).  We’ve also removed the NIC from the VM (with the VM shut down) and replaced it; that’s also alleviated the issue. Unfortunately, those steps just alleviate the symptom.  They get people ba