WilliamLam.com

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

vOpenData: An Open Virtualization Community Database

04.12.2013 by William Lam // 11 Comments

Recently, I had the opportunity to help out with a very unique and cool project called vOpenData which was created by Ben Thomas (a former VMware GSS Technical Engineer). The idea for the project was sparked by a very simple tweet that came from Duncan Epping:

Ben wanted to help answer Duncan’s question but more importantly he wanted to help answer a bigger set of questions: what are some of the common virtual infrastructure deployment configurations, averages and consolidation ratios? These questions cross the minds of the everyday vSphere administrators, architects and consultants. It would be quite difficult and nearly impossible to answer these questions outside of their own environment.

Ben reached out to me with his idea and asked if I could help develop a script to collect basic configuration information from a vSphere environment to help test out his idea. I was immediately intrigued with his idea and saw the huge potential value that Ben’s unique solution could bring to the virtualization community. The coolest thing about this project is that we were able to put together a working prototype within a week’s time!

Note: Also be sure to check out Ben's article vOpenData - Crunching everyone's data fun for fun and knowledge and his perspective on how he was able to quickly develop a prototype leveraging a PaaS solution.

What is vOpenData?

vOpenData is an open community project that grew from the question "What is the average VMDK size for deployed virtual machines?” We wanted to create an open community database that is purely driven by users submitting their virtual infrastructure configurations. Leveraging the powerful virtualization community and applying simple analytics we are able to provide various trending statistics and data for virtualized environments. This is 100% community driven and the results will be available for everyone to view and hopefully you will contribute to the overall dataset!

What information do we collect?

We made an effort to not collect specific information such as hostnames or even display names that could be used to identify a particular organization. Instead, we are using UUIDs which are automatically generated by the virtualization platform to uniquely identify a particular object. This allows us to keep track of changes in the our database when a new data set is uploaded from an existing environment. In addition we are collecting various configuration data and you can find a complete list in the Data FAQs

More info on the data we collect is here: Data FAQs

What will this data be used for?

We are planning on using this data to create some interesting statistics and data modeling for the community to use in capacity planning and analysis. Most of this data will be made available through a dashboard or reports and eventually through an API to be mixed into other applications.

What about privacy concerns?

Though the data that is collected is already anonymized and non-identifying, please ensure that you are abiding by the privacy policies of your organization when uploading this data. If you are concerned about the data, it is recommended that you audit the zip contents before uploading which are just CSV files. We only ask that you do not modify the schema at all.

How do to get started?

Step 1 - Check out the sexy vOpenData Public Dashboard here to get a glimpse of some of the information you will find by submitting your configuration data.

Step 2 - Download either the PowerCLI or vSphere SDK for Perl script which you will run against a vCenter Server which will produces a compressed zip file containing several CSV files. Instructions are available on the download page. You may rename the default file name vopendata-stats.zip to something else, as long as you do not modify the contents of the file.

Step 3 - Open a browser and go to http://www.vopendata.org and sign up for new account.

Step 4 - Click on the “Infrastructures” tab at the upper left hand corner. An Infrastructure is a logical view that can help you organize the data you have collected. You can associate a single vCenter Server with an infrastructure or you can combine multiple vCenter Server data sets into a single infrastructure. The choice is really up to you on how you would like to visualize your data and whether you would like to map that to the physical location of your virtual infrastructure.

Step 5 - Once you have created your Infrastructures, you will then upload your data files to their respective Infrastructure. This may take some time as the data processing is executed in the background and will also depend on the number of users and uploads occurring at the moment. We ask that you please be patient and check back in a bit and you can refresh the page which will let you know when the processing is complete

Step 6 - After the data is uploaded to the system, there is a scheduled job that performs the analytics and calculations which occurs in periodic batches. These calculations can take up to 45minutes to an 1hour before the results are reflected in the public dashboard and is primarily governed by the single worker we have on the backend due to resource constraints. To view the results of the public dash board visit http://dash.vopendata.org

We hope you frequent the vOpenData site regularly as the community uploads more and more data and see how statistics are trending over time. We would also like thank the following people who were part of our early alpha program and assisted with both testing as well as code contributions: Frederic Martin, Raphaël SCHITZ, Timo Sugliani and of course my Automation colleague Alan Renouf! If you would like to learn more about the vOpenData project, we have also submitted a session for VMworld 2013 4976 - vOpenData - Crunching Everyone's Data For Fun And Knowledge, be sure to vote for it!

You can follow @vopendata on Twitter for new updates and notifications as well as both Ben Thomas at @wazoo and William Lam at @lamw

How can I help or contribute?

First and foremost, you can get involved by signing up for a free account and begin contributing your data to the open community database! We are also open to any suggestions and feedback as they would be very valuable to us, feel free to join the vOpenData VMTN Community Group to discuss further. We know that in this first release we are not going to be able to show everything, but have plan to show much more. Lastly, all the infrastructure that is used to provide the dashboard, the backend database and processing is all hosted and paid out of our own pockets. If you have found this to be a useful resource and would like to contribute either with a donation or sponsorship to help us continue developing this project, please contact us at vopendata[at]gmail[dot]com

Categories // Uncategorized Tags // vopendata, vSphere

Automating SSL Certificate Regeneration in VCSA 5.1 & 5.5 (vCenter Server Appliance)

04.08.2013 by William Lam // 4 Comments

The VCSA (vCenter Server Appliance) provides a very simple way of regenerating the self-signed SSL Certificate by using the VAMI web management interface. This is extremely useful if you change the IP Address or hostname of your VCSA and want a proper SSL certificate with the correct common name, especially important if you are plan on using something like vCenter Orchestrator which validates this. To regenerate the SSL Certificate, you just need to login to the VAMI web interface by pointing your browser to the following address: https://[VC-IP]:5480 and under the Admin tab there is a option to "Toggle certificate setting".

After enabling this option, you will need to reboot your VCSA for the new SSL certificate to be generated. Once the VCSA is booted up, you will need to go back into the VAMI interface and disable this setting, else another SSL certificate will be generated upon the next reboot.

I was recently asked if it was possible to automate the SSL regeneration via the command-line without using the GUI which would be very useful for automated VCSA deployments. In looking into this, it turns out the process is quite simple and the present of a file within the VCSA will determine whether a certificate regeneration is required.

To enable certificate regeneration, run the following command which will "touch" (create) allow_regeneration file under /etc/vmware-vpx/ssl directory:

touch /etc/vmware-vpx/ssl/allow_regeneration

To disable certificate regeneration, you just need to remove the file after the VCSA has rebooted. Behind the scenes, this is what is happening when you are toggling the option in the VAMI interface and now you can automate this from the CLI without using the GUI!

UPDATE (09/04/13)

For the new VCSA 5.5, there is a new option that you can specify which will re-generate the SSL certificate and then delete the file without requiring manual intervention after reboot. You would still need to create the /etc/vmware-vpx/ssl/allow_regeneration file but if the contents of the file contains "only-once", it will delete the file automatically which is nice from an Automation perspective.

To re-generate the SSL certificate and automatically have it clean itself up, run the following command:

echo only-once > /etc/vmware-vpx/ssl/allow_regeneration

Categories // Uncategorized Tags // ssl certificate, vami, VCSA, vcva

Dude, Where's My vCenter Server 5.1 Components Installed At?

04.03.2013 by William Lam // 5 Comments

You would be surprised at the number of times I have heard this question get asked and this is not regarding the installation path but the specific server a given vCenter Server 5.1 component is installed on. I am just wondering if people are somehow miss-placing their infrastructure? I would hope that most organizations have some type of CMDB (Configuration Management Database) even if it is just a spreadsheet or at a minimum a memorable hostname. In any case, this question is only relevant for those of you who decided to separate out the vCenter SSO (Single Sign-On) Server, vSphere Web Client, Inventory Service and the vCenter Server and are now wondering where a given component is installed at.
To begin, you will need to know at a minimum where your vCenter Server is installed at. If you do not know that, then you should take the walk of shame and install this utility (be-careful with port scanning tools, as it may not be allowed by your Security Operations team). Go to the advanced settings of your vCenter Server and look up one of the following settings:
  • config.vpxd.sso.sts.uri
  • config.vpxd.sso.groupcheck.uri
  • config.vpxd.sso.admin.uri

All three of these settings should contain the same hostname or IP Address which is the location of where your SSO Server is installed. You can also find this information by looking at the vCenter Server configuration file located in the following location:

Windows vCenter Server: C:\ProgramData\VMware\VMware VirtualCenter\vpxd.cfg
vCenter Server Appliance: /etc/vmware-vpx/vpxd.cfg

Next, you will need to login directly to your vCenter Server (RDP or SSH) depending on the version you are using. Using the hostname or IP Address of our vCenter SSO Server, we will now connect to the Lookup Service which is installed alongside the vCenter SSO Server. This service will provide us with the location of all services registered to vCenter SSO and we will be able to identify the location of the remainder vCenter Server components.

For Windows vCenter Server, make sure you have the JAVA_HOME environmental variable set to C:\Program Files\VMware\Infrastructure\jre and open up a command prompt and run the following (subsitute in the hostname or IP Address of your vCenter SSO Server):

vSphere 5.5

"C:\Program Files\VMware\Infrastructure\VMware\CIS\vmware-sso\ssolscli.cmd" listServices https://winvc.primp-industries.com:7444/lookupservice/sdk

vSphere 5.1

"C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli\ssolscli.cmd" listServices https://winvc.primp-industries.com:7444/lookupservice/sdk

We can take a look at the serviceName which describes the specific vCenter Server component such as the vSphere Web Client or Log Browser and endpoints property will tell you which server it is installed on.

For vCenter Server Appliance, there is a similar command by running the following:

/usr/lib/vmware-sso/bin/vi_regtool listServices https://172.30.0.186:7444/lookupservice/sdk

The only vCenter Server component that we have not found is the Inventory Service. To find the server where this component is installed, we just need to look at the vCenter Server Extensions and and we can simply open up a web browser and connect to the following URL (substitute in your vCenter Server address):

https://vcsa.primp-industries.com/mob/?moid=ExtensionManager&doPath=extensionList[%22com.vmware.vim.inventoryservice%22].healthInfo

Hopefully at this point you are able to figure out where all your vCenter Server 5.1 components are installed at and you are also documenting all this information in your CMDB or spreadsheet 🙂

Categories // Automation Tags // inventory service, lookupservice, sso, VCSA, vcva, vSphere 5.1, vSphere 5.5, vsphere web client

  • « Previous Page
  • 1
  • …
  • 462
  • 463
  • 464
  • 465
  • 466
  • …
  • 566
  • 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

  • Deploying VCF 9.0 on a single ESXi host? 06/24/2025
  • VCF 9.0 Single Sign-On (SSO) with Keycloak IdP 06/23/2025
  • Is my NIC supported with Enhanced Data Path (EDP) with VCF 9.0 06/23/2025
  • PowerCLI remediation script for running NSX Edge on AMD Ryzen for VCF 9.0 06/20/2025
  • Failed to locate kickstart on Nested ESXi VM CD-ROM in VCF 9.0 06/20/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