Oh you can do that?: vSphere Platform Services Controller (PSC) topology and Omnigraffle

A little while ago William Lam published a little python script called extract_vsphere_deployment_topology.py that basically lets you export your current vSphere PSC topology as a DOT (graph description language) file. Great stuff, and in itself useful as is, especially if you run it through webgraphviz.com as William suggests.

The thing is, you might want to edit the topology map, change colours and fonts, and even move the boxes around, after you get the output. If you have a large environment, you might want to combine all your PSC topologies into a single document? It turns out, that’s pretty easy to do!

Omnigraffle Pro imports the DOT files natively, and lets you play around with the objects as if they were drawn in Omnigraffle from the beginning. Save the output from the script somewhere as a .dot file. Then open Omnigraffle and go to File -> Open and select the file.Screenshot 2016-05-22 21.10.12

Now, select the Hierarchical option, and you’ll get a nicely formatted canvas with your PSC components already laid out inside of Omnigraffle. Now you can edit it at will!

Screenshot 2016-05-22 21.13.56

As far as I can tell, this isn’t possible with Microsoft Visio, as it doesn’t support the DOT format, but you could always save it as a Visio file with Omnigraffle if you need to sent it to your more Microsoft inclined friends.

I’m sure there are more fun to be had with these DOT files, it’s just text files after all, perhaps someone can even code up a script that converts them to Visio .vdx files or some other format that Visio can import natively.

 

VMware VSAN – More than meets the eye.

Way back in 2014 I wrote a piece called VSAN – The Unspoken Future, and I think it’s about time it got a revision. Of course, lots of things have happened to VSAN since then and even more is on the way, but I think there is more to this than adding features like erasure coding, deduplication and compression. All of these are important features, and frankly they need to be in a product that aims a lot higher than you might think.

 

At the moment, VSAN does storage internally in a vSphere Cluster. If you want to use that storage in other ways, you either have to share it from a VM over the network or use NexentaConnect for VMware Virtual SAN.

Yesterday, VMUG.it shared the following photo from Duncan EppingsGoodbye SAN Huggers, Hello Virtual SAN” session from their VMUG UserCon:

Generic Object Storage Platform

Look closely at that one for a minute. What is Duncan and VMware telling us here, if you squint your eyes and try to read between the lines? For me, this slide was a bit of a lightbulb moment: VMware wants to turn VSAN into a generic storage provider in the data center. You need some storage of some sort? VSAN will provide it, even if your applications are not located on the same cluster.  Object based? Sure. Block? Sure. REST? Sure, that’s what the cool kids do. VMFS? Only if you need to run a VM.

Couple this with  the vSphere Integrated Containers and Photon Platform announcements, VMware is already talking about the microvisor. So, remove the vSphere layer in the slide above, and replace it with a variant of the VSAN ROBO witness appliance of some sort, which runs enough to provide policy based storage services. Once you have those two bits talking to each other, you don’t need the traditional vSphere layer to provide hardware virtualization at all for those cloud native apps. Add NSX to the mix, and network policies that follow the application, and you have a portable application infrastructure that can run pretty much anywhere you prefer.  At VMworld 2015, VMware showed NSX for Multi-Hypervisor running on AWS, extending the network from on-premises to Amazon. Why not do the same with storage?  Want cloud based storage? Sure, add the little VSAN layer in front of your providers storage offering, and boom, instant policy  management and portability.

And of course, VMware will be there to provide you with the management and monitoring layer for all of this – Even if you don’t run vSphere.

VMware is getting ready for the post-virtualization, multi-platform, world, no question about it.  Are You Ready for Any?

 

vCenter / SSO unable to retrieve AD-information | Error while extracting local SSO users

After deploying a new VCSA 6.0u1 I was seeing some weird errors while trying to retrieve AD- users/groups (or anything from the esod.local domain):

_1446154857693

After some serious head scratching, it dawned on me after checking the DNS records for the DC in the domain, from the vCenter Appliance itself:

1
2
dig +noall +answer +search dc1.esod.local
dc1.esod.local. 3600 IN A 10.0.1.201

So far so good, the DNS lookup works as expected.

1
dig +noall +answer +search -x 10.0.1.201

That’s right, the reverse lookup returns exactly zilch, zero, zippo, nil, nada and null.

The Solution

Add reverse lookup zone to DNS and update the DC PTR record._1446155633910

 

Once that it done, it works as expected:

1
2
dig +noall +answer +search -x 10.0.1.201
201.1.0.10.in-addr.arpa. 3600 IN PTR dc1.esod.local.

Re-checking the domain in the vCenter Web Client, and  AD-information is retrieved correctly.

_1446154788631

 

It turns out that in VC6.0u1 reverse PTR records are required for SSO and Active Directory authentication to function properly.