William Lam

Cloud Native Apps, Containers & Docker sessions at VMworld

05.19.2015 by William Lam // Leave a Comment

I just saw a nice list of VMworld sessions that was shared internally by Ben Corrie, an Engineer working in our Cloud Native Apps team at VMware on some of the VMworld sessions related to Cloud Native Apps, Containers & Docker. I figure I would share his list with a wider audience for those interested and I have also included session proposals by both VMware Employees as well as from our partners which you can find below.

I am personally excited for session 5229 - Docker and Fargo: Exploding the Linux Container Host which will be presented by both Ben & George Hicken if it gets accepted. I was fortunate enough to catch a demo of this internal project at our R&D Innovation Offsite (RADIO) last week and I think folks will be blown away with some of the work that has been done in this area. I can not say anymore other than to vote for this session and any others that you might be interested in! If there are other sessions, please let me know and I will update the list.

I had to also thrown in a shameless plug at the very bottom of this post on three of the sessions that I have submitted for VMworld this year. Hope you find them interesting to vote for and hope to see you all at VMworld!

VMware Submitted Sessions (14)

Session #	Session Title
4590	Hypervisors vs. Containers - Wait That's the Wrong Question!
4600	An Interesting Application Software Based on Docker
4725	Scalable On-Demand Cloud Native Apps with Docker and Mesos
4767	Seven Things vSphere Admins Need to Know About Photon Lightwave and Containers
4853	Docker Containers on vSphere: Performance Deep Dive
4940	CIS Benchmark Compliance for Docker - Automated with VMware
5006	Monitoring Software Containers with vRealize Operations
5121	Containers as a Service with vRealize Automation and VMware Project Photon
5229	Docker and Fargo: Exploding the Linux Container Host
5266	Docker in the Real World: Tales Round the Campfire
5343	Rapid and Continuous Delivery Through Docker Container and VMware Cloud Technologies
5409	Migration of Docker Based Applications across Clouds
5627	How Do You Manage and Monetize the Docker Deployments as Containers Not VMs to Groups in Your Organization Using Your Existing vRealize Suite?
5860	Containers without Compromise: Providing Persistent Storage for Docker Containers using vSphere

Partner Submitted Sessions (8)

Session #	Session Title
4742	Understanding Databases for Distributed Containerized Applications
5078	Back to the Future: What Current Container Trends Mean for the Future of Application Deployment
5321	Building Container Infrastructure for Enterprise Applications with Docker VMware Photon and vSphere
5494	TOSCA: Containers Microservices OpenStack and Orchestrating the Whole Symphony
5520	Containers on VMware Infrastructure
5907	Taming Containerized Workloads with Photon and Tectonic
6081	Are You Prepared to Contain the Container? Understand the Security and Compliance Considerations for Application Containers
6126	Containers VMs and Microservices Walk into a Bar.....

William Lam Submitted Sessions (3)

Session #	Session Title
4528	vCenter Server Appliance (VCSA) Best Practices & Tips/Tricks
5106	Content Library
5278	VC Windows to VCSA Migration Fling Deep Dive

Extracting VID, DID & SVID from PCI devices in ESXi using vSphere API

05.18.2015 by William Lam // 3 Comments

From time to time, you may need to collect some hardware related information such as PCI devices found within your ESXi hosts. In the past, you may have gone directly to the ESXi Shell running some of the legacy esxcfg-* commands for extracting things like the PCI device's Vendor ID (VID), Device ID (DID) and Sub Vendor ID (SVID) which can be used to correlate against VMware's HCL as seen in the screenshot below.

I personally try to stay out of the ESXi Shell if I can help it and prefer to retrieve these things using an API, such as the vSphere API. Historically, I too thought the VID, DID & SVID properties were only available within the ESXi Shell, but they are actually readily available in the vSphere API. You can find all PCI devices under the hardware.pciDevice property of an ESXi host and below are the three variables that map to these properties.

Vendor ID (VID) = vendorId
Device ID (DID) = deviceId
Sub Vendor ID (SVID) = subVendorId

To quickly demonstrate how you can extract this information using the vSphere API which can be done by connecting either directly to an ESXi host or by going to vCenter Server, I have created a simple PowerCLI script called queryHostPCIInfo.ps1.

Here is an example output of running the script against my Mac Mini and we can see details such as the device name, vendor and the respective VID, DID & SVID values.

If there are other properties which you still find yourself going directly to the ESXi Shell, please leave a comment as I know the PM's are interested in these information and is working hard to ensure that all these properties are available through our vSphere API.

How to download offline VSAN HCL file for VSAN Health Check Plugin?

05.16.2015 by William Lam // 4 Comments

One of the coolest features in the new VSAN Health Check Plugin is the automatic verification of your underlying hardware (hosts, disks, storage controller & drivers) by automatically checking it against VMware's VSAN HCL (Hardware Compatibility List).

The VSAN HCL database can either be downloaded automatically from VMware.com or manually uploaded if you do not have direct or proxy internet access. There was a question this morning on Twitter asking where the offline VSAN HCL file be downloaded from? I was actually curious as well and looking at Cormac Hogan's excellent VSAN Health Check documentation, I found the answer at the very end of the document 🙂

http://partnerweb.vmware.com/service/vsan/all.json

To download the offline VSAN HCL file which is actually is just a JSON file, you just need to load the above URL into a web browser and then save the file.

After you have downloaded the VSAN HCL file, you can either upload using the vSphere Web Client under the "Health" section of the VSAN Health Plugin or you using the following RVC command and specifying the path to the file:

vsan.health.hcl_update_db /localhost/ -l /root/all.json

As a bonus, I also had some fun parsing the VSAN HCL JSON file. Below is a graph that I was able to generate after extracting some useful information using the following script found here.