Earlier this month I hosted “vRA 6.2 Install and Config Live!“, an open-invite social event dubbed “vRA Live” (#vralive). To my surprise, I had 185 RSVP’s with more than 100 people — VMware partners, customers, and several of my peers — attending the 4 1/2+ hour online session. Although I tried to focus on the fundamentals of deploying vRA and associated services, the online Q&A and dialog provided by the experts panel added several examples, lesson’s learned, and plenty of colorful commentary. I couldn’t be more pleased with the turnout and hope to get the next session(s) queued up very soon!…
Network virtualization is by no means a new concept for VMware. Think about it for a moment — wherever vSphere (or any other VMware T1 or T2 hypervisor) has been implemented, a virtual switch exists and connects guest VMs to the physical world. That’s more than 500,000 customers globally, millions of vSphere hosts, and many more millions of virtual network ports backed by a standard (vSwitch) or distributed virtual switch (dvSwitch). In fact, if you count the network ports provisioned by vSphere and logically assigned to VM nics, one can argue that VMware is one of the top datalink providers on earth. Okay, perhaps that’s a stretch, but you get my point! VMware virtual networks have existed just about as long as VMware itself. And since the very beginning, there has been no shortage of innovation. The vSwitch has evolved in many ways, leading to new technologies, increased scope and scale, distributed architectures, open protocol support, ecosystem integration, and massive adoption. Over the years VMware has continued to introduce new networking technologies through organic maturity and strategic acquisition — ESXi platform security, dvSwitch (and associated services), vShield, vCloud Networking and Security (vCNS), etc. — and leveraged 3rd party integration into partner solutions, such as Cisco’s Nexus 1000v (a solution brought to market by tight collaboration between VMware and Cisco).…
Thanks to all who have shown interest in this event. I was expecting 50 RSVP’s…currently at 128! That just about guarantees this will be a fun (and informative) event. I have put together the following agenda based on feedback from the sign up survey.
The primary objective is to install, configure, and demonstrate vRA 6.2 from scratch. For this, I will follow the install and configure workflow I previously covered in my vCAC 6.0 POC and Detailed Implementation Guide. Although vRA 6.2 provides additional capabilities and a more streamlined installation, many of the concepts are the same.…
For starters, be sure to configure a vCO Endpoint (Infrastructure tab -> Endpoints -> Endpoints). In a POC or small environment you can point to the embedded vCO instances that ships with the vCAC VA. Otherwise point to an external vCO instance (note: if using an external instance, be sure to install the NSX 6.1 vCO plugin first).
Once the vCO Endpoint is configured, it’s time to add NSX support to the vSphere (vCenter) Endpoint. In vSphere (vCenter) Endpoint configuration, check the “Specify manager for network and security platform” box and enter the appropriate address / credentials for NSX. Be sure the account used has admin permissions (you can use the default admin account, or any account that has been added as NSX Admin users.
VMware’s Network Virtualization Platform, NSX, is an immensely powerful technology that can transform a datacenter’s infrastructure and streamline network service delivery across the enterprise. NSX’s scope, scale, and capability will easily impress techies, CCIE’s, and IT stakeholders alike. NSX changes the topology of a traditional hardware-bound network by eliminating the dependency on all that “intelligence” baked into proprietary hardware. Instead, the logic and associated services are delivered through a software control plane. Separating the control and data planes effectively reduces the physical network to a glorified IP packet forwarder.
With that said, it is also important to understand that NSX is not a re-write of your network and the fundamental concepts it is built upon. The abstraction of the logic from the physical underpinnings is a modern approach to designing, building, and servicing network architectures, but the fundamentals — the protocols, tools, concepts, etc. — are still at play. And for that reason, i’m often baffled when I enter into a debate with a “traditional” network engineer about the ins-and-outs of physical vs. virtual networking technologies like NSX. What I quickly realize is they are not defending the concepts or technology, they are defending their skill set. It’s a fear or reluctance of straying from what they know best.…
VMware vCloud Automation Center is the center piece of VMware’s Software-Defined Enterprise vision. It is also the primary user and admin interface for enterprise and application services, and therefore it makes a lot of sense for vCAC to be the core integration point for the SDDC.
Rawlinson Rivera (@PunchingClouds) recently posted a blog post titled “VMware Virtual SAN Interoperability: vCloud Automation Center“, where he highlights the use of vCloud Automation Center (vCAC) 6.0 to deploy applications directly to a VSAN Datastore while also leveraging a VM Storage Policy. In short, the desired storage policy is applied to the template backing the vCAC Blueprint. Once provisioned, the resulting machine adopts the associated storage policy and the rest is glorious, app-centric VSAN storage consumption. I recommend reviewing that post to get a better idea of what we’re doing here.
So now that we have a basic understanding of the interoperability between vCAC and VSAN, let’s dive into some more advanced concepts for a glimpse into the art of the possible by expanding on Rawlinson’s example and using some of vCAC’s extensibility features to deliver greater functionality.The integration between vCAC and VSAN can greatly enhance how applications are provisioned. Since storage policies can be configured per-application or VM, you can specify varying policies based on the use case, tier, application criticality, SLA, etc…all backed by a common VSAN Datastore.…
I recently had the opportunity to brief several dozen VMware Public Sector (US-Fed / SLED) partners in anticipation of the vCloud Automation Center (vCAC) 6.0 GA release. While most of the day focused on vCAC, I spent about an hour or so delivering an updated version of my SDDC Whiteboard brief to help set the stage for vCAC.
The whiteboard provides an overview of VMware’s SDDC / vCloud vision — starting from the foundation (i.e. vSphere) and capped off by the cloud automation layer (vCAC)…and all the loveliness in between.
This is a presentation I do often, but no two are the same. If you’ve got 45ish minutes to spare, please do and feel free to provide some feedback!
vCloud Automation Center 6.0’s “XaaS” feature will allow our customers to utilize any prepackaged, new, or existing vCenter Orchestrator workflow and deliver it as a Self-Serviced, Entitled, Governed, and Lifecycle-managed service. VMware will be shipping a more integrated View/vCAC DaaS integration in Q1’2014. Until then we have to improvise to come up with a “DaaS-like” solution that will help fill in the gap until the products are natively integrated.
vCAC’s Advanced Service Designer (ASD) provides a quick-fix for this needed capability using rather unsophisticated means. This use case guide will walk you on building a Desktop Request service using the ASD and vCenter Orchestrator’s Active Directory Plug-in.
DaaS Use Case Objectives:
- Allow cloud users to request a Horizon View Desktop machine from vCAC’s Service Catalog and add Self-Service, Governance, and Entitlement to existing View Environments
- Use vCAC’s Advanced Service Designer to create a Custom Service to deliver DaaS
- Configure a Governance (Approval) policy for VDI Desktop Requests
- Utilize vCO’s built-in Active Directory plug-in and a simple workflow to do the magic
DaaS Solution Summary:
- Horizon View is configured with 2 Desktop Pools:
- Floating Desktop Pool: DaaS-Engineering
- Dedicated Desktop Pool: DaaS-Operations
- DaaS-Engineering -> “DaaS-Eng”
- DaaS-Development-> “DaaS-Ops”
assumes you have good working knowledge of vCloud Automation Center 6.0
and Horizon View 5.x, as well as familiarity with vCAC’s UI and