Skip navigation

As you guys may notice, I have spent some hours on vSphere vShield product recently. I have came cross a design flaw issue I would like to discuss with you.

First all, let me briefly describe my test environment.

I have two physical HP boxes and a EMC SAN as my test box. In this case, I have built a vCenter as VM sitting on one of ESX host. Therefore, I can even make snapshot if I want to. However, this has been generate some issues for vShield product.


In terms of testing installing and configuring vShield product. I normally install vShield on one host and move some test VMs to new host to see how VMs respond. Then, I will vMotion vCenter VM to new host and install vShield on the second host since some of vShield components requires reboot host. I have done that couple of times. Eventually, it happened.


I initialled vMotion from a host which has zone, firewall, vApp to a host which doesn’t have those settings. vCenter got frozen.

I was waiting for couple of minutes but I was still not able to connect to vCenter. Not even pingable.

so I jump on new host with directly vClient and I found vCenter is up running in the new host. But it’s not pingable. Other VMs sitting in the same vSwitch are not having issues at all. I vMotioned vCenter before I install vShield without any issues. Why I can’t connect to vCenter VM this time?


The reason is simple. It’s caused by vShield Zone and other components. Let’s take a look to see what happens when I vMotion a normal VM to a host installed with vShield.



The normal procedure should be:

  1. Query
  2. Migrate a new VM into new host.


However, as you can see from the picture, it actually reconfigured the VM afterwards.


And  if you monitor vMotion ping status, the ping drop during vMotion from 1 time out become 10 times out depends on how you configure vShield.



so what exactly this reconfiguration step do?

The answer is that virtual machine vmx file has been reconfigured with vShield information. The more important thing is this step is done by vCenter!!

With a host installed with vShield products(like Zone), any VMs vMotion into that host will automatically configured with vZone. If vZone information is not configured, the VM will not able to communicate with other VM even if VMs in the same vSwitch because it’s caused at vNic leve.

Just imagine what happened if you try to vMotion a vCenter? No one is going to modify vCenter VM since it’s temporary disconnect from network!!


I think this is a design flaw since use VM as vCenter is an option provided by VMware.

What I did was to use putty to connect to ESX host and manually modify vmx file of vCenter VM.

This is what old vmx looks like. This host has all vShield parts.


We need to remove and param1 and add vEndpoint to match whatever new host got. The result is following.


After modification, the vCenter is able to start and connect to network.


vShield is still a new product. VMware needs to resolve issues when vCenter in VM mode and let host , instead of vCenter, to reconfigure vmx files everytime a new VM vmotion into host or register a new VM.

Plus, the reconfiguration takes too long to finish. For important time sensitive machine, 10 time out may not be acceptable.


  1. GeekSilver,

    Great find on this one. I agree this is something we (I work at VMware) need to figure out a way to handle more cleanly in upcoming releases. That said, we do call this out in the Quickstart guide on page 20 as a known issue. I guess it really could have an explanation in there as to why you shouldn’t have vCenter on the the same ESX host where App or Zones is installed, but it is there. Although I know not many of us (me included) look at the docs. 😉

    The best practice today is to have a management cluster for your management VMs like vCenter, vShield Manager, and other management systems. Typically fine for large Enterprise deployments, but I agree that it is less than ideal for lab and smaller deployments.

    I hope this helps.

    Best Regards,
    Rob Randell

  2. GeekSilver Is there any way to work around this either by manually configuring vCenter to work on a vShield host or maybe FT could be used

    Is the problem just getting a vCenter vm initially configured to work with vShield hosts or is it an ongoing problem and a vCenter VM can never be protected by vShield?

  3. Great article, and it helped me climb out from under a mess. However, your screenshot shows the first line for the vEndpoint should be scsi0:0.filters = “VFILE”.

    I believe this should be ethernet0:0.filters = “VFILE”.

    Just a typo, or at least it was compared to my installation, and I wanted to point it out in case someone had trouble with it.

One Trackback/Pingback

  1. By Welcome to vSphere-land! » Security Links on 22 Apr 2011 at 3:58 am

    […] VMware vShield Endpoint and Trend Micro Deep Security 7.5 understanding Part 3 (GeekSilver) VMware vSphere vShield 1.0 design flaw with vCenter as VM? (GeekSilver) VMware vShield Zones – Reviewers Guide (VMware) Author: esiebert7625 Categories: […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: