By now a great deal of folks in the community have heard and know about vOpenData and what it is, who is behind this cool project and what it does. For those of you who don’t know what vOpenData is or what it does vOpenData is an open community project that came to life based on user requests for knowledge about virtualization environments and their most common configuration ranging from average VMDK size, number of virtual machine deployments, etc. VMware’s own and my boy! (You ma Boy Blue) William Lam is one of the minds behind this useful can cool project.
By leveraging the volunteered community data and apply simplified analytics vOpenData can provide answers to a great deal of questions that people may be interested in acquiring but yet it may be difficult to get.
vOpenData collects various types of data from virtualized infrastructures with an effort to prevent the collection unique data points that could compromise infrastructure private information such as hostsnames, IPs, UUID, etc.
The data collected is used to virtualization based statistics and data modeling for the community that can be useful in a great deal of scenarios such as average VMDK sizes, number of virtual machines, most utilized or deployed hardware, average hosts connected per vCenter servers, etc.
vOpenDate Infrastructure Dashboard
By now, the entire community has shown interest on the vOpenData project and all the blogs have been raving about it from the very first day they saw it. Because of that, I didn’t add my two cents and wrote something about. I figured the project had gained enough attention from the blogger community and just waited for thing I can mention that was particularly of interest to me.
New to vOpenData statistics is the collection of data with regards to storage arrays. Now vOpenData can produce statistics gathered from storage system, LUN sizing, arrays by vendor types and more. As storage is one of the last pain points to be simplified, the more knowledge you have of what is out there and what is being use and in what capacity can help in many ways.
vOpenData Storage Related Dashboard
I’m a big fan of this new storage statistic capability and of vOpenData over all. This will help me with some of my queries with regards to storage centric topics in conjunction with my current responsibilities at VMware. I would highly recommend to give vOpenData project a look if you haven’t done so yet and sign up if possible and contribute to the communities wealth of valuable information and statistics.
For future updates, be sure to follow me on Twitter at @PunchingClouds
Alright!!!! VMware community members and followers, If you’re anywhere near Austin, Texas on April 2nd come an join us for a day of fun and knowledge transfer at the VMware User Group (VMUG). The event is set to be a very good one with great breakout sessions about the Software Defined Datacenter (SDDC), Software Defined Storage, VCDX Workshop bootcamps.
If you interested on the challenge and pursuing the VCDX certification you want to attend one of the bootcamps delivered by actual VCDX panel members. The VCDX bootcamps have shown to be very helpful for candidates. I will be there along other fellow VCDXs and panel members Wade Holmes, and Matthew Meyer.
The VCDX bootcamp will cover everything you need to prepare for the certification process and the defense with topics such as
- What the VCDX covers, and what it is designed to demonstrate
- Profiles of successful and unsuccessful candidates
- An insider’s view of the VCDX Panel Defense process, including perspectives from the panelists
- Advanced best practices for VMware design and architecture available nowhere else
- Practice VCDX Design and Troubleshooting Scenarios, and more
If you’re curious and want to learn more about the Software Defined Datacenter and Software Defined Storage, I will also be presenting a session on VMware’s Software Defined Storage (SDS) vision for the Software Defined Datacenter, and providing some insight into some of the features and technologies VMware is currently working on to make the vision a reality.
If you are already a VCDX, master of the universe and already know about all this stuff than great!, you’re the Man!!! or the Woman!!! still just come down and socialize with everyone it will be fun.
Feel free to sign up and register Austin VMUG User Conference
For future updates, be sure to follow me on Twitter at @PunchingClouds
As an avid Mac and ESXTOP user and I’ve been experiencing some challenges using the Terminal application in OSX for sometime. The OSX Terminal tool is definitely one of my favorite built-in applications. Terminal allows me to access all types of CLIs very easily and quickly but in particular, it allows me to connect to ESXi hosts without the need of any other application or operating system.
This is the complete opposite situation when using a Windows based operating system. When using Windows, there is a need to use third party tools such as Putty, SecureSSH, etc in order to access remote SSH shell and stuff like that. Ever since I upgraded to the latest version of OSX I’ve been experiencing problems when working with ESXi hosts and the ESXTOP tool. For some reason previously unknown to me, I thought that maybe there were changes made to the ESXi CLI that was preventing me from displaying the ESXTOP data correctly and I didn’t know about it.
To be honest, working with so many different ESXi builds and all, I never took the time to investigate the reason why I was experiencing problems displaying ESXTOP data with the OSX Terminal application. Needless to say, I was being lazy, but also because of being busy. After upgrading to the latest version of OSX whenever I used the Terminal application to launch ESXTOP, the information was no longer displayed in its conventional format. The data example I was getting is illustrated in the screenshots below.
- Launching ESXTOP
- ESXTOP Data Displayed
The release and support of VXLAN has raised a great level of interest in the community. As one of the first to deliver content with regards to VXLAN implementation examples I’ve been approach by customer and colleagues with questions around VXLAN architecture designs and use cases. For the most part, I see there is a large audience not really up to speed with the logistics of VXLAN as it relates to vSphere and vCloud infrastructures supported implementation scenarios. The knowledge gap is not entirely around the value of VXLAN technology but more around the architectures and uses cases where it can successfully be used today.
Based on my experiences lately, the use of VXLAN becomes the topic of conversation whenever connecting multiple data centers where each site has separate vSphere/vCloud Infrastructure becomes to topic of conversation. I can see how some folks have been mislead into thinking VXLAN is the answer for that as they can now leverage VXLAN to connect multiple vCenter Server and vCloud Director infrastructure together today. Well the truth is that plain and simple VXLAN CANNOT be use as the technology to connect multiple vCenter Server and vCloud Director environments today.
The reality is that with the current release of VXLAN there is no supported way of connecting multiple vSphere or vCloud Infrastructures together. Considering the platforms architectures and components both vSphere and vCloud based infrastructures have a lot of dependencies and moving parts which makes it very challenging to integrate in a way that would make that possible today. From what I understand this is something that all of the partners involved with the development of the VXLAN technology are looking to address soon.
One of the publications which I have found a lot of people reading and using as guidance for vCloud Director is the vCloud Architecture Toolkit (vCAT). As part of the vCAT implementation examples we have included a couple of VXLAN scenarios one of them being around disaster recovery and based on conversation this very topic I’ve noticed that some people have overlooked or missed one critical piece of the information discussed and illustrated as part of that example.
As one of the contributors to the vCloud Architecture Toolkit (vCAT) I have to come out and defend some of the misconceptions folks are gathering around the VXLAN implementation example in vCAT topic. The VXLAN disaster recovery example scenario is based around a stretched cluster scenario, and not two separate infrastructures. Two physical data centers in two different locations with one logical datacenter (vSphere/vCloud) spanning both physical data centers.
I recently posted an article about Architecting Storage Offering for vCloud Director 5.1. In the article I discussed new architecture considerations for the latest version of vCloud Director.
The middle of the article focuses around the use of Storage Profiles among other vSphere features that can now be leveraged by vCloud Director.
When I referenced the use of Storage Profiles I stated the following:
“The “*(Any)” storage profile is there by default, but it should not be included as part of any PVDC without considering the possible performance and operational risks.”
The reason for my statement was due to the possible risks any vCloud Director infrastructure can be exposed to without the correct use and understanding of the new storage features and capabilities discussed in the article.
As I’ve said before, vCloud Director is now capable of leveraging some of the vSphere storage technologies. For the most part, a majority of the storage related configurations are defined outside of the vCloud Director interface i.e. VM Storage Profile, Storage Clusters, etc. Cormac Hogan wrote an excellent article about the configuration and use of Storage Profiles. It’s a Must Read!
Storage Profiles are defined, organized, and configured in vSphere. The majority of the time we tend to label them by referencing precious metals. An example of that is illustrated in the figure below.