http://kb.vmware.com/kb/2013639

Access failed, an unknown discovery error has occurred

I rebooted several services but nothing seemed to solve it. Internally I bumped on a thread which had the fix for this problem: DNS. Yes I know always DNS right. Anyway, I used “DHCP” for my VIN appliance and this DHCP server pointed to a DNS server which did not have the IP/name of my ESXi hosts listed. Because of this the discovery didn’t work as VIN tries to resolve the names of the hosts as they were added to vCenter Server. I configured VIN with a fixed IP and pointed the VIN appliance to the right DNS server. Problem solved.

• vCloud Director support
• Infrastructure Navigator discovers VMware services, such as Site Recovery Manager (SRM) Server, VMware View Server, VMware vCloud Director Server, and VMware vShield Manager Server.

For those who don’t know, Infrastructure Navigator is an application awareness plugin for vCenter Server. This enables you to  get a better understanding of what is running on top of your virtual infrastructure. A lot of you may say, well why would I care? Think about DR for a second. What is the most challenging part of creating a DR Plan? Indeed, figuring out all dependencies. That is exactly where vCenter Infrastructure Navigator comes in to play as shown in the screenshot below, which I stole from Ben Scheerer. Ben wrote an excellent blog about some of the cool new features in vCenter Infrastructure Navigator, I am not going to repeat those just read his. It is worth it if you are serious about providing the best service to your (internal) customers!

• Stop the service (was already stopped)
• Delete the entire contents of the Inventory_Service_Directory/data directory
• Change directory to Inventory_Service_directory/scripts
• Run the createDB.bat command, with no arguments, to reset the vCenter Inventory Service database
• Run the register.bat command to update the stored configuration information of the Inventory Service
  register.bat vcenter-tm01.testlab.local 443
• Restart the vCenter Inventory Service

I also had to re-register the Web Client to vCenter Server. This is what I had to do:

• admin-cmd.bat register https://vcenter-tm01.testlab.local:9443/vsphere-client https://vcenter-tm01.testlab.local administrator password

Project Octopus is the successful marriage of Zimbra and Mozy technologies, with some additional code jointly developed by the two teams. Prior to GA release, it will be folded into Horizon, providing a centralized policy and entitlement engine that will broker user access to applications, virtual desktops and data resources. The result will be a simple, seamless end-user experience when accessing work resources across private and public clouds on whatever device the user chooses.

The beta is open to all and will last through VMworld. Due to limited support resources, priority will be placed on customers with active engagements.

The answer is short and sweet: Yes.

For each cluster a folder is created. The folder structure is as follows:

/<root of datastore>/.vSphere-HA/<cluster-specific-directory>/

The “cluster specific directory” is based on the uuid of the vCenter Server, the MoID of the cluster, a random 8 char string and the name of the host running vCenter Server. So even if you use dozens of vCenter Servers there is no need to worry.

Each folder contains the files HA needs/uses as shown in the screenshot below. So no need to worry around sharing of datastores across clusters. Frank also wrote an article about this from a Storage DRS perspective. Make sure you read it!

PS: all these details can be found in our Clustering Deepdive book… find it on Amazon.

Two advanced settings have been introduced in vSphere 5.0 Update 1 to enable HA to fail-over virtual machines which are located on datastores which are in a Permanent Device Loss state. This is very specific to stretchec cluster environments. The first setting is configured on a host level and is “disk.terminateVMOnPDLDefault”. This setting can be configured in /etc/vmware/settings and should be set to “True”. This setting ensures that a virtual machine is killed when the datastore it resides on is in a PDL state.

The second setting is a vSphere HA advanced setting called “das.maskCleanShutdownEnabled“. This setting is also not enabled by default and it will need to be set to “True”. This settings allows HA to trigger a restart response for a virtual machine which has been killed automatically due to a PDL condition. This setting allows HA to differentiate between a virtual machine which was killed due to the PDL state or a virtual machine which has been powered off by an administrator.

But why is “das.maskCleanShutdownEnabled” needed for HA? From a vSphere HA perspective there are two different types of “operations”. The first is a user initiated power-off (clean) and the other is a kill. When a virtual machine is powered off by a user part of the process is setting the property “runtime.cleanPowerOff” to true.

Remember that when “disk.terminateVMOnPDLDefault” is configured your VMs will be killed when they issue I/O. This is where the  problem arises, in a PDL scenario it is impossible to set “runtime.cleanPowerOff” as the datastore, and as such the vmx, is unreachable. As the property defaults to “true” vSphere HA will assume the VMs were cleanly powered off. This would result in vSphere HA not taking any action in a PDL scenario. By setting ”das.maskCleanShutdownEnabled” to true, a scenario where all VMs are killed but never restarted can be avoided.

If you have a stretched cluster environment, make sure to configure these settings accordingly!

Version 3.3 (April, 2012)

• GetWebResponse timeout value changed from 5 minutes to 10 minutes (for very big environments)
• New tabpage with HBA information
• On vDatastore tab the definition of the Provisioned MB and In Use MB columns was confusing! This is changed now.
• RVToolsSendMail accepts now multiple recipients (semicolon is used as separator)
• Folder information of VMs and Templates are now visible on vInfo tabpage
• Bugfix: data in comboboxes on filter form are now sorted
• Bugfix: Problem with api version 2.5.0 solved
• Bugfix: Improved exception handling on vCPU tab.
• Bugfix: Improved exception handling on vDatastore tab.

• DR of the Cloud - In this session Chris Colotti and I will focus on vCloud Director infrastructure resilience.  We will go over the concept Chris and I developed and discuss the recommended practices and operational aspects of DR of the Cloud.
• Architecting and Operating a vSphere Metro Storage Cluster – In this session Lee Dilworth and I will discuss the design and operational considerations for vSphere Metro Storage Clusters environments. Our focus will primarily be vSphere though!

I am considering submitting another session. I know many have enjoyed the open-floor / Q&A style sessions, but the main topic was always HA and DRS aka vSphere Clustering. Currently I am thinking “Cloud Infrastructure Q&A”… but if you could pick a topic what would you like to see and who would you love to see on the panel? (Max 4 people) I try to make it happen!