WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

What Are the Shadow of vmnic in ESXTOP?

01.04.2013 by William Lam // 6 Comments

In ESXi 5.1, you might have noticed something new called Shadow of vmnic under the USED-BY column in the Network view of ESXTOP.

I initially heard about this from a few followers on twitter and I was curious myself since I could not find any documentation regarding this topic. It took a bit of digging but it turns out these shadow vmnics is actually related to the new VDS Health Check feature released in vSphere 5.1. A shadow port is created automatically for every uplink in your ESXi host and is used for transmitting and receiving health check related packets for each uplink. In ESXTOP, you can monitor the statistics for these shadow ports which can be used to debug/troubleshoot the network health check feature and this is why they are present.

One thing to note, these shadow ports are created regardless of whether or not your ESXi host is connected to a VDS or if you have the network health check features enabled. This is by design and there are four VMkernel modules that are responsible for the network health check feature:

  • vlanmtucheck
  • teamcheck
  • heartbeat
  • healthchk

Disclaimer: Do not modify or disable any of the above VMkernel modules else you can potentially disable network connectivity to your ESXi host (trust me, I know).

After some investigation and testing in my lab, I found that I could unload the above VMkernel modules and the shadow vmnics entries would no longer appear in ESXTOP. To do this, you will need an ESXi 5.1 host which is not running any virtual machines and you will need to run the following commands in this exact order (as there are module dependencies):

vmkload_mod -u vlanmtucheck
vmkload_mod -u teamcheck
vmkload_mod -u heartbeat
vmkload_mod -u healthchk

Once you have successfully unloaded all four VMkernel modules, if you open up ESXTOP, you should no longer see the shadow vmnics. To restore the shadow vmnics, you can either reboot (since the unload is not persistent) OR you can run the following commands in this exact order:

vmkload_mod heartbeat
vmkload_mod teamcheck
vmkload_mod vlanmtucheck

Note: By loading the heartbeat VMkernel module, it also loads the healthchk module.

Categories // Uncategorized Tags // ESXi, ESXi 5.1, esxtop, healthcheck, shadow, vds, vmnic

vCloud Director Simulator

01.03.2013 by William Lam // 8 Comments

I have received several questions from folks asking if there are other VMware solutions that could work with the vCenter Server Simulator (vcsim) which I recently wrote an article about back in 2012. Well, the answer is I do not know, as other solutions have not really been tested out with vcsim. The goal of vcsim was primarily focused at the vSphere layer and I suspect that other VMware solutions can probably leverage what vcsim has done but probably will not work (today) as some solutions require a fair amount of communication between itself and the vCenter Server. Now having said all that, you might be wondering about the title of this article?

The one solution that I am aware of today that works with vcsim is vCloud Director and this is merely a proof of concept than anything else, so I would like to set the proper (low) expectations. The available functionality from vCloud Director is quite limited when using it with vcsim and I have also ran into several issues which I will go into more detail later. For vCloud Director to be able to consume the simulated inventory from vcsim, a few tweaks are required in both vcsim and the vCloud Director database.

Disclaimer: This is not officially supported by VMware, use at your own risk.

Requirements:

  • VCSA 5.1 (vCenter Server Appliance)
  • VCNS 5.1 (vCloud Networking and Security)
  • VCD 5.1 Appliance
  • configureVCSimulator.sh script

I highly recommend you take a look at my vCenter Server Simulator article before getting started as it gives you some background that is required later on but you will not be required to configure the VCSA in advanced as there are some additional configurations that are needed. I will also be using the vCloud Director appliance which I recommend for quick ease of deployment and setup.

Configurations: 

Step 1 - Deploy VCSA and configure it as you would normally (do not touch the vcsim configurations, as that is handled in the next step using a script that is provided)

Step 2 - Download the configureVCSimulator.sh script and upload it to the VCSA. By default, vcsim's XML configuration files is set to ESXi 4.0 and we will need to adjust the version numbers to reflect either 5.0 or 5.1 as well as modify the hypervisor type from embeddedEsx to esx which is required by the simulator code. Go ahead and run the script on the VCSA which will setup the vcsim as well as modify the necessary files. Once the script has completed, if you wish to change the default inventory, go ahead and modify /etc/vmware-vpx/vcsim/model/initInventory.cfg and then restart the vCenter Server service by running service vmware-vpxd restart

Here is a screenshot of the script running:

Note: If you are interested in the files that are being modified, you can take a look at the shell script for more details. 

Step 3 - Deploy and configure VCNS appliance as you would normally. Make sure you also register the vCenter Server in the VCNS UI that you just deployed as this is needed before moving forward to the next step.

Step 4 - Deploy the VCD appliance using the embedded database and power on the system. Once the system is ready, go ahead and SSH to the host, we will need to execute a few SQL queries which will allow vCloud Director to support simulated hosts as well as the particular ESXi versions. First we need to switch over to the Oracle user, run the following command:

su - oracle

Next we will login to the VCD database using sqlplus and the default credentials which should be vcloud/VCloud, run the following command:

sqlplus vcloud/VCloud

The first SQL statement will allow VCD to support simulated ESXi hosts, type in the following SQL statement:

update config set value='1' where name='vzSim50Supported';

The next two SQL statements will define the version of ESXi that VCD will support, type in the following SQL statements that are applicable to you:

insert into os values (seq_config.NextVal, 'vmnix-x86', 'VMware ESX', '5.1.0', 0, 1);
insert into os values (seq_config.NextVal, 'vmnix-x86', 'VMware ESX', '5.0.0', 0, 1);

Finally, we just need to type "quit" to exit from sqplus and then type "exit" to logoff as the oracle user and this will bring us back to root context. The last thing we need to do is restart the vCloud Director service for the changes to go into effect by running the following command

service vmware-vcd restart

Here is a screenshot of running through the VCD database changes:

Step 5 - Once the vCloud Director service has been successfully restarted, we are now ready to setup our vCloud Director Simulator environment. Start off by adding both your VCSA and VCNS to the vCloud Director under Resources tab as you would normally.

Next, click on Provider VDCs to create your Pvdc and when you arrive at the ESXi host preparation step, you can type in anything for the username/password (since these are simulated ESXi host).

After you click next or finish, you then click into the Hosts tab to watch the ESXi host preparation. This is where you will notice the first issue, the preparation should finish almost immediately as thgey are simulated hosts, so no VCD agent is installed or services needing to be enabled, but from what I have seen this process can take up to 30minutes if not longer. You will need to be patient when you get to this point and do not try to cancel the process and just let it sit and finish. To ensure your environment is setup correctly, make sure the following three columns show green check marks: Enable, Ready and Available during the preparation.

This is probably a good time to get some coffee or tea and check out other cool articles on virtuallyghetto.com 😉

Once the ESXi hosts have completed preparation, you should see a green check box under the Status column which means you are now ready to create an Organization which is a pre-requisite before creating an Organization VDC. I will assume you know how to proceed from here and depending if you setup an ESXi 5.0 or ESXi 5.1 environment in vcsim, you will need to choose the appropriate virtual machine compatibility (virtual hardware) to support in your OrgVDC.

Note: If you setup an ESXi 5.0 environment, you may see an error with too many connected datastores, to resolve this, you need to either decrease the number of hosts in your simulated environment or use ESXi 5.1

You can probably guess the last step is to start provisioning VMs/vApps in our vCloud Director instance, but sadly this is where you will face another issue. What I have found is that when you deploy a new vApp, an exception is thrown regarding a NULL pointer and VCD will fail on the deployment.

However, if we take a look at our vcsim environment, you will see that the VM actually does get created but this still poses a problem for us in VCD, as the task is still not considered successful.

I have not been able to figure out why and I know from running through several tests, there was a case where I was able to successfully provision a VM in the VCD simulator. This might be related to the version of virtual hardware selected, I had more luck using either 7 or 8 but not so much with 9. Unfortunately, without provisioning capabilities, this may not be as useful as one would like but I encourage you to still give this a try if you are interested.

The vCloud API can also be access in the simulated environment, but remember that the operations will be limited to what has been shown and will probably work for most of the inventory based API calls, but again, YMMV.

Though vCloud Director Simulator is somewhat limited today and with a few known issues, it is a proof of concept that other VMware solutions can leverage what vcsim has provided as a base foundation. If you think this is something that is useful to have or have other use cases for, please leave a comment. You never know, this could be a VMware Fling one day if there is enough interest from the community.

Categories // Uncategorized Tags // notsupported, simulator, vcloud director, vcloud director 5.1, VCSA, vcsim, vcva

vCenter Server Simulator

12.19.2012 by William Lam // 47 Comments

I recently spent some time experimenting with a really cool tool found only in the VCSA (vCenter Server Appliance) called vcsim, short for vCenter Simulator. I initially noticed vcsim during some of my early beta testing of vSphere 5.1 and during this period it is not uncommon to find various utilities and debugging tools used by developers and QE for testing. At the time, I was more focused on usability issues and reporting bugs with the product and I did not think much of this vcsim. It was only until recently, after talking to Mr. Not Supported aka Randy Keener, did I look into vcsim again as it appears to have been included in the GA (generally available) build of the VCSA 5.1 which I had not expected.

Disclaimer: This is not officially supported by VMware, use at your own risk.

vCenter Simulator is an internal tool developed by two VMware engineers: Zhelong Pan and Kinshuk Govil which allows you to quickly simulate thousands of virtual machines all running in memory while requiring only a minimal amount resources within the VCSA (2vcpu & 8GB memory - default configuration). Building such a tool is definitely not a trivia task, but it is also not the first time we have seen something like this. Awhile back there was project called simDK created by Andrew Kutz that did something similar but only supported reading information from vCenter Server, it did not support any actual operations. vcsim is much more advanced and the really cool thing about vcsim is that even though the inventory is simulated, it actually supports some basic vSphere inventory operations such as create/destroy and power operations. It also supports a hybrid configuration where you can mix both simulated and actual ESXi hosts and virtual machines since it is an actual vCenter Server.

Before we dive into using vcsim, I wanted to go through a few use cases where a tool such as this would be useful:

  • Exploring and learning about the vSphere API and the basic inventory hierarchy of vSphere objects
  • Environment to develop and create various inventory reporting scripts (vCLI, PowerCLI, etc)
  • Developing performance metric gathering tools
  • Developing vSphere Web Client plugins and being able visualize large inventory of objects

As you can see, once you start to think about the potential of a such tool, the possibilities can be endless. Having said all of this, no amount of simulation can ever replace actual testing of a real system and any development made using vcsim should be validated against an actual vSphere environment.

To enable vcsim, you will need to add some configuration entries into the vpxd.cfg (vCenter Server configuration file) an example template of the configuration is provided in:

/etc/vmware-vpx/vcsim/model/vcsim.cfg.template

To setup a basic vCenter Simulator, you should deploy a brand new VCSA (you can use an existing VCSA, but the VCDB could potentially get wiped) and go through the basic setup as you would normally. Next, you need to add the following lines at the end of /etc/vmware-vpx/vpxd.cfg between </vpxd> and </config>

 <simulator>
    <enabled>true</enabled>
    <cleardb>false</cleardb>
    <initinventory>vcsim/model/initInventory.cfg</initInventory>
 </simulator>

Note: Notice the cleardb parameter is false in my example where as the template is set to true. This is very important because if you use the default of "true", you will not be able to view your vSphere inventory using the vSphere Web Client but only the vSphere C# Client as the Inventory Service DB is wiped.

Once you have added the configurations and saved the vpxd.cfg, you will need to restart the vCenter service by running the following command:

service vmware-vpxd restart

Note: A restart of the vmware-vpxd service ONLY works the very FIRST time you add in the vcsim configurations. For any additional changes to the vcsim configuration files, a different method is required to reload the changes, else the vCenter service will fail to start. This is shown in detail further in the article.

Once the vCenter service has restarted, you should now be able to login using either the vSphere Web Client or the vSphere C# Client and you should see a default vSphere inventory that contains a Datacenter, Cluster, several ESXi hosts with Resource Pools along with some powered on and off virtual machines.

Here is a screenshot of logging into the vSphere Web Client:

 
Here is a screenshot logging into the vSphere C# Client:

You might notice that your inventory may not be as large as mines ... oh about 10,000 VM large 🙂 Another cool thing about vcsim is that it has a configurable inventory that you can customize to fit whatever design you wish to have and this can be modified in /etc/vmware-vpx/vcsim/model/initInventory.cfg file. You can tweak the following in the configuration files:

  • Datacenter
  • Hosts per Datacenter
  • VM per Host
  • Powered On VM per Host
  • Cluster per Datacenter
  • Host Per Cluster
  • Resource Pool per Cluster
  • VM per Resource Pool
  • Powered On VM
  • vCPU for a VM
  • vMEM for a VM

Once you have saved your changes, to reload the new configurations into vcsim, you will need stop the vCenter service and run vpxd -b command to recreate the database and then start the vCenter service. To do so, run the following 3 commands (this is required each time for any changes):

service vmware-vpxd stop
vpxd -b
service vmware-vpxd start

When you log back into your vCenter Server, you now should see the new inventory based on your configurations. In addition to inventory configuration, the vcsim template also points to three other configuration files which I encourage to explore further:

  • vcsim/model/metricMetadata.cfg (simulated Performance Metrics, none by default)
  • vcsim/model/vcModules.cfg (simulated VC modules such as DRS)
  • vcsim/model/OperationDelay.cfg (operations latencies)

Note: You should only be modifying the *.cfg files and not the XML configuration files else you could potentially run into issues.

At this point, you are probably ready to start playing with vcsim and even though this is an internal tool, if you think this is something that is useful to have or have other use cases for, please leave a comment. You never know, this could be a VMware Fling one day if there is enough interest from the community.

Categories // Uncategorized Tags // appliance, notsupported, simulator, VCSA, vcsim, vcva, vSphere 5.1

  • « Previous Page
  • 1
  • …
  • 30
  • 31
  • 32
  • 33
  • 34
  • …
  • 74
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Automating the vSAN Data Migration Pre-check using vSAN API 06/04/2025
  • VCF 9.0 Hardware Considerations 05/30/2025
  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025