I’ve recently been testing a handful of reporting tools against vCenter Server endpoints. I have several lab instances for various major releases, which allow me to test a wide range of configurations. However, there are some tests that are hard to simulate, like what if a cluster has 100 hosts, or one host has 200 VMs? <\/p>\n\n\n\n
Years ago I remember stumbling on a vCenter Server simulator. I didn’t have a specific need for it at the time but with this recent testing I checked, and the tool still exists and is actively maintained here: https:\/\/github.com\/vmware\/govmomi\/blob\/main\/vcsim\/README.md<\/a>. There is even a container image available. This article will show how to create a single VM that can help simulate many vCenter Servers for our various reporting requirements.<\/p>\n\n\n\n I started with an Ubuntu 24.04 virtual machine (deployed from a template previously created with Packer, as described in this previous post<\/a>). I then installed docker compose and make a few configuration changes to make docker a bit easier to work with.<\/p>\n\n\n\n William Lam maintains a github repo with recordings of some lab inventories, available here: https:\/\/github.com\/lamw\/govc-recordings<\/a>. I downloaded this repo and extracted the contents to This repo also contains instructions on how to save an existing inventory for use in the simulator. Getting ready to do some maintenance or decommission an environment? Might as well save that point in time snapshot of the inventory we can report against later.<\/p>\n\n\n\n Looking at this file, you’ll see 3 instances of the In the This nginx configuration will extract the subdomain from the request, for example the word I’ve not included the certificate files, but as you can see from the With our When the system restarts, these containers will restart automatically. If we want to check stats or logs, we can do so with the following:<\/p>\n\n\n\n When running the Using the above steps, I have a single lab VM with ~10 vCenter inventories… using less than 2GB of RAM and 2vCPU. There are of course some caveats, like no UI and some methods that don’t exist in the simulator, but for many test scenarios when you just need the SOAP API this works great.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" I’ve recently been testing a handful of reporting tools against vCenter Server endpoints. I have several lab instances for various major releases, which allow me to test a wide range of configurations. However, there are some tests that are hard … Continue reading Server setup<\/h2>\n\n\n\n
# install docker compose, add our active directory user & root to the docker group\nsudo apt install docker-compose-v2\nsudo usermod -aG docker ${USER}\nsudo usermod -aG docker root\n# Log off\/on for new group membership to become effective\n\n# create a folder for some of our configs, make the docker group owner of that folder\nsudo mkdir \/data\nsudo chgrp docker \/data\nsudo chmod g+srw -R \/data \n\n# configure docker to not overlap network ranges and make ranges smaller than default\necho '{\"default-address-pools\":[{\"base\":\"172.17.0.0\/16\",\"size\":26}]}' | sudo tee --append \/etc\/docker\/daemon.json\nsudo systemctl restart docker\n\n# create a folder for our simulator \nmkdir vcsim\ncd vcsim<\/code><\/pre>\n\n\n\nSample vCenter Inventories<\/h2>\n\n\n\n
\/data\/vcsim\/sims<\/code>, which provides 5 different lab environments from about 4 years ago. <\/p>\n\n\n\nDocker
compose.yml<\/code><\/h2>\n\n\n\nvcsim<\/code> container running. There are two generic inventories, controlled by parameters passed to command<\/code> for things like number of hosts per cluster, port groups, and listening port. The third vCenter inventory is one of the saved inventories from the govc-recordings repo. I’m running multiple saved inventories, but in the interest of saving space have only included one sample below. Each vcsim<\/code> container will get a container IP and listen on port 8989. In this example, nginx<\/code> is handling all of the traffic coming in — we reference a reverse_proxy.conf<\/code> file as well as a certificate folder. Those will be discussed later.<\/p>\n\n\n\n\/data\/vcsim\/<\/code> folder, compose.yml<\/code> has the following contents:<\/p>\n\n\n\nversion: '2'\nservices:\n # This nginx web server will terminate at a wildcard SSL certificate, then use the first label\n # of the DNS entry to send requests to port 8989 on the associated container, for example:\n # https:\/\/small.vcsim.example.com:443 --> https:\/\/small:8989\n nginx:\n image: nginx:latest\n volumes:\n - \/data\/vcsim\/reverse_proxy.conf:\/etc\/nginx\/conf.d\/default.conf\n - \/data\/vcsim\/cert:\/etc\/nginx\/certs\n ports:\n - \"443:443\"\n\n # Here are a few simulated VCs with progressively larger inventories\n small:\n image: vmware\/vcsim:latest\n command: -api-version \"8.0.3\" -cluster 1 -dc 1 -folder 5 -host 8 -standalone-host 0 -l \"0.0.0.0:8989\" -vm 20\n restart: unless-stopped\n medium:\n image: vmware\/vcsim:latest\n command: -api-version \"8.0.3\" -cluster 2 -dc 2 -folder 5 -host 16 -standalone-host 0 -l \"0.0.0.0:8989\" -vm 100\n restart: unless-stopped\n\n # The following examples are from a github repo\n wlam7:\n image: vmware\/vcsim\n command: -load \/simdata -l \"0.0.0.0:8989\"\n restart: unless-stopped\n volumes:\n - \/data\/vcsim\/sims\/vcsim-vcsa.primp-industries.local:\/simdata<\/code><\/pre>\n\n\n\nnginx
reverse_proxy.conf<\/code><\/h2>\n\n\n\nsmall<\/code> from small.vcsim.example.com<\/code> and store it in a $sub<\/code> variable. We will then proxy the request for each subdomain to the appropriate container, for example https:\/\/small.vcsim.example.com:443\/<\/code> to the individual container of https:\/\/small:8989\/<\/code>. In DNS we only need to create a single cname record for *.vcsim.example.com<\/code> that points to our container host. Any container that gets created will automatically be available via our wildcard subdomain.<\/p>\n\n\n\ncompose.yml<\/code> and reverse_proxy.conf<\/code> files, there is a directory at \/data\/vcsim\/cert<\/code> containing a PEM formatted certificate and private key named wildcard-vcsim-example-com.pem<\/code> and wildcard-vcsim-example-com.key<\/code>. This allows all our requests (from PowerCLI or the like) to have a valid certificate, while we only need to maintain a single certificate file.<\/p>\n\n\n\nserver {\n # Listen for any HTTPS request\n listen 443 ssl;\n\n # Extract the subdomain name from 'SUB.vcsim.example.com'\n server_name ~^(?<sub>[^.]+)\\.vcsim\\.example\\.com$;\n\n # Define the path to the certificate and key\n ssl_certificate \/etc\/nginx\/certs\/wildcard-vcsim-example-com.pem;\n ssl_certificate_key \/etc\/nginx\/certs\/wildcard-vcsim-example-com.key;\n\n # For any request, proxy to the container name on port 8989\n location \/ {\n resolver 127.0.0.11 valid=1s;\n proxy_pass https:\/\/$sub:8989;\n }\n}<\/code><\/pre>\n\n\n\nBring Up<\/h2>\n\n\n\n
compose.yml<\/code>, reverse_proxy.conf<\/code>, certificate files, and simulated inventories in place, we are ready to startup the service. To this we only need to run a single command:<\/p>\n\n\n\ndocker compose up -d<\/code><\/pre>\n\n\n\ndocker stats\ndocker compose logs<\/code><\/pre>\n\n\n\ndocker compose<\/code> commands we need to be in the \/data\/vcsim\/<\/code> folder, or specify that folder via arguments.<\/p>\n\n\n\nConclusion<\/h2>\n\n\n\n