Invalid Configuration for device ‘0’ Error Message

First time I’ve encountered this issue in my environment after a DRS initiated vMotion of a VM. I’ve noticed that the VM’s network card is disconnected and whenever I tried to connect it, the Invalid Configuration for device ‘0’  error pops up. From the looks of it, vMotion had a bandwidth issue but it did migrate successfully after another attempt.


This exact issue is documented in KB 2014469 and although vSphere 5.5 is not in the product list, I gave it a try to see if it will resolve this issue.

I did Option 1 of the KB article which is to move the VM into a different and unused dVPort. From the screenshot below, my VM Win2K8R2 is using port 104 of distributed switch vDS-DMZ.


To change this, edit the VM setting and highlight the network adapter. Under network connection, click Switch to advanced settings. In the Port ID box, change the Port to a new unused port. In the screenshot below, I changed the port from 104 to 105


Click OK then go back to Edit Settings and connect the NIC card. This resolved my issue and the VM is back into the network.newCapture6


Forwarding vCenter Server logs into Log Insight 2.0

Im loving Log Insight!!! Ever since I’ve installed this product in my lab, there is virtually no need to go over logging to each ESXi host and go through important log files like vmkernel.log, hostd.log, vpxa.log. For me, gone are the days where you have to go over these logs, using linux tools and commands to peak over log files when troubleshooting an issue. Its so easy to do query in the Interactive Analysis page of Log Insight and it presents it to you in a graphical manner. Filtering for keywords is a breeze.

Screen Shot 2014-07-11 at 9.15.42 AM The builtin vSphere Contect Pack will surely get you started pretty fast as it contains all the important queries in your vSphere environment. See below screenshot.

Screen Shot 2014-07-11 at 9.16.09 AM

In the GA version of Log Insight,  in order to forward vCenter Server (Windows version) log files such as vpxd.log, you have to install a 3rd part Syslog agents like Syslog-NG or Datagram Syslog agent and configure them to forward the log files to Log Insight. This is because Windows does not natively support Syslog

With the release of Log Insight 2.0, a Log Insight Windows agent has been included that allows collection of Windows events and log files from a Windows machine and forwards them into Log Insight. There is also a Content Pack for Windows where the important queries for Windows events are pre-created. More information about the Log Insight Windows agent can be found here.

Screen Shot 2014-07-11 at 9.31.16 AM

Back to the subject of this post 🙂 So now with the Windows agent included, how do we forward the vpxd.log file into Log Insight. Easy! Just install the Log Insight agent into your Windows vCenter Server and edit the liagent.ini file. Add the highlighted lines from the screenshot below. Restart the Log Insight service and  you are good to go!


For those interested or are using in Log Insight, I highly recommend following Steve Flanders blog at I’ve been constantly reading his excellent posts about Log Insight ever since I started using this product.

Deploying an Additional vSphere Replication Server

Depending on a customer’s requirement, there may be a need to deploy additional vSphere Replication servers. A few use cases are for availability and load balancing. Another one I can think of is if you want to deploy a vSphere Replication Server on a remote site that is managed by a vCenter Server on the main site. With vSphere Replication 5.5, you can add up to 9 VRS for a total of 10 including the first VR appliance which holds both the VRMS and VRS functionality. For a complete detail on vSphere Replication/SRM limits, see KB Article 2034768

In this article, I’ll show how easy it is to deploy an additional vSphere Replication Appliance.

1. In the web client, go to Manage–> vSphere Replication–> Replication Servers. Click on the OVF deployment icon to deploy the VRS ovf.

Screen Shot 2014-06-30 at 10.25.15 AM

2. The file to select is vSphere_Replication_Addon_OVF10.ovf. This OVF is only 512MB in RAM, all other resources (CPU, disk) is the same as the vSphere Replication appliance OVF.

Screen Shot 2014-06-30 at 10.27.08 AM

3. Review the OVF details and click Next.

Screen Shot 2014-06-30 at 10.27.50 AM

4. Select the name of the VRS and folder to place it to, then click Next

Screen Shot 2014-06-30 at 10.28.01 AM

5. Select the cluster as a resource to run the VRS. Click Next

Screen Shot 2014-06-30 at 10.28.15 AM

6. Select the datastore where the VRS will be located. If needed, you can also change the virtual disk format. Click Next

Screen Shot 2014-06-30 at 10.28.22 AM

7. Select the portgroup that will be used by the VRS. Under IP Allocation I selected Static-Manual and configured the DNS, Netmask, and Gateway settings. Click Next

Screen Shot 2014-06-30 at 10.29.45 AM

8. Provide a password for the VRS root account as well as the IP address of the VRS. Click Next

Screen Shot 2014-06-30 at 10.30.33 AM

9. Click Finish to start the OVF deployment.

Once the VRS is powered on and initialized, we now have to register this new VRS as an additional VRS. To do so, perform the following:

1.  In the web client, go to Manage–> vSphere Replication–> Replication Servers. Click the middle icon (Register a virtual machine as vSphere Replication Server) and select the newly deployed VRS.

Screen Shot 2014-06-30 at 10.36.36 AM

2. Once registered, you will now see the new VRS under the vSphere Replication tab

Screen Shot 2014-06-30 at 10.40.37 AM

You can now select this VRS or use Auto-assign when protecting a VM with vSphere Replication:

Screen Shot 2014-06-30 at 10.44.36 AM

If you decided you don’t need the additional VRS, you need to unregister the VRS before removing/deleting it.

Screen Shot 2014-06-30 at 10.45.37 AM

That’s it. Never gets easier than that..

SRA command ‘discoverDevices’ failed SRM 5.x and EMC VNX

It seems there is a known issue with the EMC Mirrorview SRA if all the MirrorView replicated LUNs are within a consistency group. Site Recovery Manager errors out during device discovery with the following error:

SRA command ‘discoverDevices’ failed. No replicated devices could be found. Please verify the correct array managers and array pairs are configured.

The SRA version is 5.0.2 and the Mirroview Enabler version is

The workaround is to create a new replicated LUN but DO NOT put it in any consistency group. I got this workaround from this post. Tried it and SRM was able to discover the replicated LUN’s.



VM Replication status is “Not Active” after upgrade to vSphere 5.5/VR 5.5

Weird issue I encountered after I deployed vSphere Replication appliance on my upgraded vSphere 5.5 lab. I was able to configure vSphere replication for a VM but for strange reasons, the VM replication shows as Not Active. This worked fine when I was still using vSphere 5.1/VR 5.1. The hostd.log file shows the following error:

Screen Shot 2014-04-29 at 1.30.21 PM

The configuration for vSphere Replication all looks good, all are green so I can’t figure out what’s wrong here.

Luckily, I found a  VM community post which is similar to my issue found here

I remember that in 5.1, I configured a vSphere Replication vmkernel port tick box in web client. This vmkernel port tick box is now removed in vSphere 5.5. As far as I know, that tick box is useless in vSphere 5.1 coz even though its checked, VR traffic will always default to the management vmkernel. See Sunny Dua’s article on properly configuring a different management network for vSphere replication

Going back to my issue, I followed the suggestion to remove the lines similar to the following in esx.conf of the ESXi host:

/net/vmkernelnic/child[0001]/tags/4 = “true”

The number [0001] may change depending on the environment. On mine its [0002]. After making the change and rebooting the ESXi hosts, vSphere Replication started working fine again.

Thoughts on vCenter Server Remediation for Heartbleed bug – vCenter Server with Heartbeat

KB 2076692  documents the vCenter Server upgrade and remediation to address the Heartbleed vulnerability. VMware released 2 updates in vCenter 5.5 which are 5.5.0c (for those in 5.5 GA or pre U1) and 5.5 U1a (for those in 5.5U1). If you read the KB article carefully, updating to those versions is just the first step, you still need to re-issue the certificate for the VMware Directory Service, and change the password for the Administrator@vsphere.local account. Quoting the KB:

“After the vCenter Server environment is upgraded, the Single Sign-On component requires the SSL certificate for the VMware Directory Service to be re-issued and the administrator@vsphere.local password to be changed. Any other vsphere.local users that have been defined will also require their passwords to be changed.

Failure to carry out these actions continues to expose the system to compromise from the OpenSSL Heartbleed vulnerability.”

The steps for re-issuing the certificate is also documented in KB 2076692

So how do we perform this if vCenter Heartbeat is protecting your vCenter Server? In my past articles regarding vCenter Server upgrade, I documented the steps from KB 207181, the steps which i called a re-clone method. I believe that using this method is the easiest way to upgrade your vCenter Server and remediate for the heartbleed bug.

You just have to add the remediation steps for Heartbleed (re-issue the certificate and update the administrator@vsphere.local password) after Step 6 under Upgrading the Primary Node of KB 207181. Just make sure you are using the vCenter Server’s public FQDN and IP address when generating a new certificate.

“Failed to Initialize” message on vSphere Replication 5.5 Appliance

I’m currently spending most of my lab time honing my SRM skills preparing for my next project. The past few days I have upgraded my lab to SRM 5.5.1 using a NetApp storage simulator and NetApp SRA 2.1. All works good so far with array based replication.

So I decided to try using vSphere Replication. However I am encountering issues after deploying the vSphere Replication appliance. It will deploy fine but its not taking the IP address that I set (reverts to DHCP). When I login to the management webpage https://ip-address:5480, it gives me the message “Failed to Initialize“. I tried redeploying the appliance a couple of times but still encounters the same issue.

Then I realized I have been deploying the appliance using the vSphere Client. So I tried deploying it using the Web Client, and after deployment and poweron of the appliance, I don’t see the error anymore and I was able to login and configure the appliance.

Screen Shot 2014-04-29 at 9.55.47 AM

I’m not sure if this is new to vSphere Replication 5.5 but anyways, will always try to remind myself to try and move away to the vSphere Client. But since SRM5.5 is still managed using the vSphere Client, then that will have to wait 🙂