Home > Blogs > VMware Consulting Blog > Author Archives: juliap

VMware Horizon 7 New Features

Dale CarterBy Dale Carter

With the release of VMware Horizon 7, I thought I would highlight some of the new features that have been added with this release.

Blast Extreme Protocol

With the update to Blast Extreme, VMware has upgraded the Blast Extreme protocol to the same level as PCoIP and RDP. Now you will be able to use the Blast Extreme protocol when connecting via HTML5, and also when you connect to a virtual desktop or RDSH app using your VMware Horizon client on any device.

DCarter_Edit LocalA

Just as with PCoIP and RDP, VMware Horizon Administrators will be able to configure the Blast Extreme protocol as the default protocol for both desktop and application pools.

DCarter_Edit Global Entitlement

Blast Extreme will not only be available for standard desktop and application pools but also global pools when configured with Cloud Pod Architecture.

VMware Instant Clone Technology

VMware Instant Clone is the long awaited technology built on VMware Fork technology that was previewed at VMworld. VMware has been working on it for some time. VMware Instant Clone helps to create the just-in-time desktop. It allows for a new virtual desktop to be created in seconds, and thousands of virtual desktops to be created in a very short time. This is one of the best features of the VMware Horizon 7 release, and I believe that VMware Horizon administrators are going to love creating desktop pools using this new Instant Clone technology.

For information on configuring the new VMware Horizon Instant Clone technology, see my blog here.

Cloud Pod Architecture

The two main updates to Cloud Pod Architecture are scale and home site improvements. I have written two new blogs to cover these new updates:

Cloud Pod Architecture New Features

Update to How CPA Home Sites Work with VMware Horizon 7

Smart Policies

The new Smart Policies are a way to have more granular control of what users can access when they connect to their virtual desktop or applications. With the first release of Smart Policies, you will be able to set the following policies based on certain conditions:

  • VMware Horizon Conditions
    • View client info (IP and name)
    • Endpoint location (Internal/external)
    • Tags
    • Desktop pool name
  • VMware Horizon Capabilities
    • Clipboard
    • Client drive
    • USB
    • Printing
    • PCoIP bandwidth profiles

For more information on these capabilities see my more detailed blog here .

To use Smart Policies, you will need VMware Horizon 7 and User Environment Manager 9. You will also need the latest view agent and clients installed to take advantage of these new features. The other thing to note is that these policies only work with the PCoIP and Blast Extreme protocols and not RDP.

Desktop Pool Deletion

The Desktop Pool Deletion feature is often a request from customers who want to stop administrators from deleting a desktop pool that currently has active desktops within it. With VMware Horizon 6.x and earlier versions, it was possible for an administrator to accidentally delete a desktop pool and all the VM’s within that pool. This new feature, when enabled, will stop that from happening. To enable this feature, follow the instructions in my blog here.

These are just some of the new features that have been released with VMware Horizon 7. For a full list of the new features, check out the release notes.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

3 Reasons VMware Horizon 7 Will Make You Smile

Michael BradleyBy Michael Bradley

The June 2014 release of VMware Horizon® 6 brought with it a long list of exciting new features. Cloud Pod Architecture (CPA), RDS hosted desktop and applications, and integration with VMware vSAN were just a few of the headlines that sent desktop administrators rushing to upgrade.

Although the new features marked huge advances in availability and scalability, they came with certain, shall we say, nuisances. These nuisances had a way of popping up at the most inopportune times, and although not showstoppers by any stretch of the imagination, could become very irritating very quickly. Now, I’m the kind of guy who is easily irritated by nuisances, so, seeing the list of features coming with Horizon 7 made me smile. With this upcoming release, VMware is introducing enhancements that fix three of the items on my personal list of nuisances in VMware Horizon 6. Let’s take a look.

Cloud Pod Architecture Home Sites

The introduction of Cloud Pod Architecture was a huge step forward in providing true high availability and scalability for a VMware Horizon 6 virtual desktop infrastructure. The ability to easily span pools across multiple data centers had been something that VMware customers had been requesting for some time. For the most part, Cloud Pod Architecture did exactly what it was designed to do. However, there was one small thing about it that really irritated me: home sites.

A home site is the affinity between a user and a Cloud Pod Architecture site. Home sites ensure that users always receive desktops from a particular data center, even when they are traveling. Home sites were a nice idea, and worked wonderfully, in most circumstances.

What I found to be irritating was the fact that if resources were unavailable in the user’s assigned home site, Cloud Pod Architecture would stop searching for available desktop/app sessions and deny access to the user, even if there were resources available in an alternate site.

HomeSites

The good news is that, with the release of VMware Horizon 7, this behavior has changed. When a user who is assigned a home site logs in to VMware Horizon, Cloud Pod Architecture will search for available resources in that user’s home site. However, if no available resources can be found, Horizon will search other eligible sites and, if found, assign an available desktop/app session to the user.

Certificate Single Sign-On

This problem is not uncommon to users logging into a VMware Horizon® View™ environment using RADIUS, RSA’s SecurID, or even VMware Identity Manager™. In each of these situations, it is possible that the users may not enter their active directory (AD) credentials, and, although VMware Horizon “trusts” that user, they may be forced to enter their AD credentials in order to access their Windows desktop. This is dependent on the 2 form factor authentication requirements and implementation.

This will change with the introduction of certificate SSO. In VMware Horizon 7, certificate SSO allows users to authenticate to a Windows desktop without requiring AD credentials or a smartcard. Authentication is based on a patented process whereby a short lived certificate is created specifically for the user allowing authentication to a singular Windows session, which then logs the user in. In all cases, the user will have previously been authenticated through another service using other “non AD mechanisms,” such as biometrics, SecurID, RADIUS, or VMware Identity Manager. The VMware Horizon 7 session is launched using security assertion markup language (SAML), and the SAML assertion will include a reference to the user’s UPN, which is then used to generate a custom certificate for the logon process.

Desktop Pool Deletion

It’s the stuff of nightmares. A VDI administrator working in the VMware Horizon administrator console accidently clicks “Delete” on the desktop pool that contains the desktops for every executive in the company. As the administrator watches each desktop delete, all he can do is update his resume and wait for the hammer to fall. If you’ve woken up in a cold sweat with this recurring nightmare, then you are in luck.

With the release of VMware Horizon 7, administrators can only delete desktop pools that are empty. If you try to delete a pool that contains desktops, a message will be displayed, instructing the administrator that the pool contains desktops. In order to delete a desktop pool, you must disable provisioning, and then delete all of the desktops from inventory first. This makes it virtually impossible to accidently delete a desktop pool, allowing desktop administrators everywhere to sleep a little easier.

DeletePool

So, VMware Horizon 7 doesn’t fix nuisances like traffic jams, global warming, or nuclear proliferation, but I’m excited to see its new features and enhancements, and I’m pleased to say that there are plenty more where they came from.


Michael Bradley, a VMware Senior Solutions Architect specializing in the EUC space, has worked in IT for almost 20 years. He is also a VCP5-DCV, VCAP4-DCD, VCP4-DT, VCP5-DT, and VCAP-DTD, as well as an Airwatch Enterprise Mobility Associate.

Hybrid Cloud and Hybrid Cloud Manager

Michael_FrancisBy Michael Francis

Disclaimer: This blog is not a technical deep dive on Hybrid Cloud Manager; it talks to the components of the product and the design decisions around the product. It assumes the reader has knowledge of the product and its architecture.

Recently, I have been involved with the design and deployment of Hybrid Cloud Manager for some customers. It has been a very interesting exercise to work through the design and the broader implications.

Let’s start with a brief overview of Hybrid Cloud Manager. Hybrid Cloud Manager is actually comprised of a set of virtual appliances that reside both on-premises and in vCloud Air. The product is divided into a management plane, control plane, and data plane.

  • The management plane is instantiated by a plugin in the vSphere Web Client.
  • The control plane is instantiated by the Hybrid Cloud Manager virtual appliance.
  • The data plane is instantiated by a number of virtual appliances – Cloud Gateway, Layer 2 Concentrator, and the WAN Opto appliance.

The diagram below illustrates these components and their relationships to each other on-premises and the components in vCloud Air.

MFrancis_Logical Architecture Hybrid Cloud Manager

Figure 1 – Logical Architecture Hybrid Cloud Manager

The Hybrid Cloud Manager provides virtual machine migration capability, which is built on two functions: virtual machine replication[1] and Layer 2 network extension. The combination of these functions provides an organization with the ability to migrate workloads without the logistical and technical issues traditionally associated with migrations to a public cloud; specifically, the outage time to copy on-premises virtual machines to a public cloud, and virtual machine re-addressing.

During a recent engagement that involved the use of Hybrid Cloud Manager, it became very obvious that even though this functionality simplifies the migration, it does not diminish the importance of the planning and design effort prior to any migration exercises. Let me explain.

Importance of Plan and Design

When discussing a plan, I am really discussing the importance of a discovery that deeply analyses
on-premises virtual workloads. This is critical, as the Hybrid Cloud Manager creates such a seamless extension to the on-premises environment, we need to understand:

  • Which workloads will be migrated
  • Which networks the workloads reside on
  • What compute isolation requirements exist
  • How and where network access control is instantiated on-premises

Modification of a virtual network topology in Public Cloud can be a disruptive operation; just as it is in the data center. Introducing an ability to stretch layer 2 network segments into the Public Cloud and migrating out of a data center into Public Cloud increases the number of networks and the complexity of the topology of the networks in the Public Cloud. So the more planning that can be done early the less likely disruptions to services will need to occur later.

One of the constraints in the solution revolves around stretching layer 2 network segments. A Layer 2 network segment located on-premises can be ‘stretched’ to one virtual data center in vCloud Air. So we have some implications of which workloads exist on a network segment, and which vCloud Air virtual data centers will be used to host the workloads on the on-premises network segment. This obviously influences the creation of virtual data centers in vCloud Air, and the principals defined in the design, which influence when additional virtual data centers are stood up – compared with growing an existing virtual data center.

Ideally, an assessment of on-premises workloads would be performed prior to any hybrid cloud design effort. This assessment would be used to size subsequent vCloud Air virtual data centers; plus, it would discover information about the workload resource isolation that drives the need for workload separation into multiple virtual data centers. For instance, the requirement to separate test/development workloads from production workloads with a ‘hard’ partition would be one example of a requirement that would drive a virtual data center design.

During this discovery we would also identify which workloads reside on which networks, and which networks require ‘stretching’ into vCloud Air. This would surface any issues we may face due to the constraint that we can only stretch a Layer 2 segment into one virtual data center.[2] This assessment really forms the ‘planning’ effort in this discussion.

Design Effort

The design effort involves designs for vCloud Air and Hybrid Cloud Manager. I believe the network design of vCloud Air is a critical element. We need to determine whether to use:

  • Dynamic routing or static routing
  • Subnet design and its relationship to routing summarization
  • Routing paths to the Internet
  • Estimated throughputs required for any virtual routing devices
  • Other virtual network services
  • Egress optimization functionality from Hybrid Cloud Manager
  • And finally, we need to determine where security network access points are required

The other aspect is the design of the virtual compute containers, such as virtual data centers in vCloud Air. The design for vCloud Air should define the expected virtual data center design over the lifecycle of the solution. It would define the compute resource assignment to each virtual data center initially, and over the lifecycle as anticipated growth is factored in. During the growth of use, the requirements for throughput will increase on the networking components in vCloud Air, so the design should articulate guidance around when an increase in size of virtual routing devices will need to occur.

The vCloud Air platform is an extension of the on-premises infrastructure. It is a fundamental expectation that operations teams have visibility into the health of the infrastructure, and that capacity planning of infrastructure is taking place. Similarly, there is a requirement to ensure that the vCloud Air platform and associated services are healthy and capacity managed. We should be able to answer the question, “Are my virtual data center routing devices of the right size, and is their throughput sufficient for the needs of the workloads hosted in vCloud Air?” Ideally we should have a management platform that treats vCloud Air as an extension to our on-premises infrastructure.

This topic could go much deeper, and there are many other considerations as well, such as, “Should I place some management components in vCloud Air,” or, “Should I have a virtual data center in vCloud Air specifically assigned to host these management components?”

I believe today many people take an Agile approach to their deployment of public cloud services, such as networking and virtual compute containers. But I believe if you are implementing such a hybrid interface as offered by Hybrid Cloud Manager, there is real benefit to a longer term view to the design of vCloud Air services to minimise risk if we paint ourselves into a corner in the future.

Some Thoughts on Hybrid Cloud Manager Best Practices

Before wrapping up this blog, I wanted to provide some thoughts on some of the design decisions regarding Hybrid Cloud Manager.

In a recent engagement we considered best practices for placement of appliances, and we came up with the following design decisions.

MFrancis_Design Decision 1

MFrancis_Design Decision 2

MFrancis_Design Decision 3

Key Takeaways

The following are the key takeaways from this discussion:

  • As Hybrid Cloud Manager provides a much more seamless extension of the on-premises data center, deeper thought and consideration needs to be put into the design of the vCloud Air public cloud services.
  • To effectively design vCloud Air services for Hybrid Cloud requires a deep understanding of the on-premises workloads, and how they will leverage the hybrid cloud extension.
  • Network design and ongoing network access controlling operational changes need to be considered.
  • Management and monitoring of the vCloud Air services acts as an extension of the data center needs to be included in the scope of a Hybrid Cloud solution.

[1] Leverages the underlying functionality of vSphere Replication; but isn’t a full vSphere Replication architecture.

[2] This constraint could be overcome; however, the solution would require configurations that would make other elements of the design sub-optimal; for example, disabling the use of egress optimization.


Michael Francis is a Principal Systems Engineer at VMware, based in Brisbane.

Configuring NSX SSL VPN-Plus

Spas_KaloferovBy Spas Kaloferov

One of the worst things you can do is to buy a great product like VMware NSX Manager and not use its vast number of functionalities. If you are one of those people and want to “do better” then this article is for you. Will take a look how to configure SSL VPN-Plus functionality in VMware NSX. With SSL VPN-Plus, remote users can connect securely to private networks behind a NSX Edge gateway. By doing so remote users can access servers and applications in the private networks.

Consider a software development company that has made design decision and is planning to extend it’s existing network infrastructure and allow remote users access to some segments of it’s internal network. To accomplish this the company will be utilizing the already existing VMware NSX Manager network infrastructure platform to create a Virtual Private Network (VPN).

The company has identified the following requirements for their VPN implementation:

  • The VPN solution should utilize SSL certificate for communication encryption and be used with standard Web browser.
  • The VPN solution should use Windows Active Directory (AD) as identity source to authenticate users.
  • Only users within a given AD organizational unit (OU) should be granted access to the VPN.
  • Users should be utilizing User Principal Names (UPN’s) to authenticate to the VPN.
  • Only users who have accounts with specific characteristics, like those having an Employee ID associated with their account, should be able to authenticate to the VPN.

If you have followed one of my previous articles Managing VMware NSX Edge and Manager Certificates, you have already made the first step towards configuring SSL VPN-Plus.

Configuring SSL VPN-Plus is a straightforward process, but fine tuning it’s configuration to meet your needs might sometimes be a bit tricky. Especially when configuring Active Directory for authentication. We will look into a couple of examples how to use the Login Attribute Name and Search Filter parameters fine grain and filter the users who should be granted VPN access.

Edit Authentication Server tab on VMware NSX Edge:

SKaloferov Edit Authentication Server

Please visit Configuring NSX SSL VPN-Plus to learn more about the configuration.


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

“Network Functions Virtualization (NFV) for Dummies” Blog Series – Part 2

Common Use Cases for the Transition to NFV

Gary HamiltonBy Gary Hamilton

In my previous blog posting I discussed the question – What is NFV? This blog post looks at the network functions that will be delivered as virtual network functions (VNFs), instead of as hardware appliances. SDx Central offers a nice article that helps with some of these definitions.

In very simple terms (remember this is a blog series for IT people, not network experts), a network function is a network capability that provides application and service support, and can be delivered as a composite whole, like an application. SDx Central does a good job in the aforementioned article of grouping these network functions by categorizing them into umbrella or macro use cases. By leveraging these macro use cases, I am able to provide a layman’s description of what these use cases are attempting to achieve, and the service support they deliver. The macro use cases I will focus on in my explanation are “virtual customer edge” and “virtual core and aggregation”, because these are the two use cases that are generally being tackled first from a NFV perspective.

Use Case – Connecting a remote office (using vCPE)

In layman terms, the SDx Central “customer edge” use case focuses on how to connect a remote office, or remote branch, to a central data centre network, and extending the central data centre’s network services into that remote office. In order to deliver this connectivity, a CPE (customer premises equipment) device is used. Generally, the types of device used would be a router, switch, gateway, firewall, etc., (these are all CPEs) providing anything from Layer 2 QoS (quality of service) services to Layer 7 intrusion detection. The Layer 2 and Layer 7 references are from the OSI Model. vCPE (virtual customer premises equipment) is the virtual CPE, delivered using the NFV paradigm.

The following diagram was taken from the ETSI Use Case document (GS NFV 001 v1.1.1 2013-10), referring to the vCPE device as vE-CPE. (I’ll discuss the significance of ETSI in a future blog post)

This diagram illustrates how vCPEs are used to connect the remote branch offices to the central data centre. It also illustrates that it is OK to mix non-virtualised CPEs with vCPEs in an infrastructure. Just as in the enterprise IT cloud world, the data and applications leveraging the virtual services are not aware – and do not care – whether these services are virtual or physical. The only thing that matters is whether the non-functional requirements (NFRs) of the application are effectively met. Those NFRs include requirements like performance and availability.

This particular use case has two forms, or variants –

  • Remote vCPE (or customer-premise deployed)
  • Centralised vCPE (deployed within the data centre)

The diagram below shows examples of both variants, where vCPEs are deployed in branch offices, as well as centrally. The nature of the application being supported, and its NFRs, would normally dictate placement requirements. A satellite/cable TV set-top box is a consumer example of a “customer-premise deployed” CPE.

GHamilton Customer Premise Deployed CPE

Use Case – Virtualising the mobile core network (using vIMS)

The SDx Central “Virtual core and aggregation” use cases are focused on the mobile core network (Evolved Packet Core – EPC) and IP Multimedia Subsystem (IMS). In layman terms, this is about the transportation of packets across a mobile operator’s network. This is focused on mobile telephony.

IMS is an architectural network framework for the delivery of telecommunications services using IP (internet protocol). When IMS was conceived in the 1990s by the 3rd Generation Partnership Project (3GPP), it was intended to provide an easy way for the worldwide deployment of telecoms networks that would interface with the existing public switched telephone network (PSTN), thereby providing flexibility, expandability, and the easy on-boarding of new services from any vendor. It was also hoped that IMS would provide a standard for the delivery of voice and multimedia services. This vision has fallen short in reality.

IMS is a standalone system, designed to act as a service layer for applications. Inherent in its design, IMS provides an abstraction layer between the application and the underlining transport layer, as shown in the following diagram of the 3GPP/TISPAN IMS architecture overview.

An example of an application based on IMS is VoLTE, which stands for “Voice over 4G LTE” wireless network. Examples of VoLTE applications are Skype and Apple’s FaceTime.

GHamilton 3GPP and TISPAN

Use Case – Virtualising the mobile core network (using vEPC)

While IMS is about supporting applications by providing application server functions, like session management and media control, EPC is about the core network, transporting voice, data and SMS as packets.

EPC (Evolved Packet Core) is another initiative from 3GPP for the evolution of the core network architecture for LTE (Long-Term Evolution – 4G). The 3GPP website provides a very good explanation of its evolution, and description of LTE here.

In summary, EPC is a packet-only network for data, voice and SMS, using IP. The following diagram shows the evolution of the core network, and the supporting services.

  • GSM (2G) relied on circuit-switching networks (the aforementioned PSTN)
  • GPRS and UMTS (3G) are based on a dual-domain network concept, where:
    • Voice and SMS still utilise a circuit-switching network
    • But data uses a packet-switched network
  • EPS (4G) is fully dependent on a packet-switching network, using IP.

GHamilton Voice SMS Data

Within an EPS service, EPC provides the gateway services and user management functions as shown in the following diagram. In this simple architecture:

  • A mobile phone or tablet (user equipment – UE) is connected to an EPC over an LTE network (a radio network) via an eNodeB (a radio tower base station).
  • A Serving GW transports IP data traffic (the user plane) between the UE and external network.
  • The PDN GW is the interface between the EPC and external network, for example, the Internet and/or an IMS network, and allocates IP addresses to the UEs. PDN stands for Public Data Network.
    • In a VoLTE architecture, a PCRF (Policy and Charging Rule Function) component works with the PDN GW, providing real-time authorisation of users, and setting up the sessions in the IMS network.
  • The HSS (Home Subscriber Server) is a database with user-related and subscriber-related information. It supports user authentication and authorisation, as well as call and session setup.
  • The MME (Mobility Management Entity) is responsible for mobility and security management on the control plane. It is also responsible for the tracking of the UE in idle-mode.

GHamilton EPC E-UTRAN

In summary, EPC, IMS and CPE are all network functions that deliver key capabilities that we take for granted in our world today. EPC and IMS support the mobile services that have become a part of our daily lives, and frankly, we probably would not know what to do without them. CPE supports the network interconnectivity that is a part of the modern business world. These are all delivered using very specialised hardware appliances. The NFV movement is focused on delivering these services using software running on virtual machines, running on a cloud, instead of using hardware appliances.

There are huge benefits to this movement.

  • It will be far less expensive to utilise shared, commodity infrastructure for all services, versus expensive, specialised appliances that cannot be shared.
  • Operational costs are far less expensive because the skills to support the infrastructure are readily available in the market.
  • It costs far less to bring a new service on-board, because it entails deploying some software in VMs, versus the acquisition and deployment of specialised hardware appliances.
  • It costs far less to fail. If a new service does not attract the expected clientele, the R&D and deployment costs of that service will be far less with NFV than in the traditional model.
  • It will be significantly faster to bring new services to market. Writing and testing new software is much faster than building and testing new hardware.
  • The costs of the new virtual network functions (VNFs) will be less because the entry point is far lower because it is now about developing software versus building a hardware appliance. We see evidence of this, where a lot of new players have come into the Network Equipment Provider (NEP) market (the suppliers of the VNFs), therefore creating more competition, which drives down prices.

All sounds great. But, we have to be honest, there are serious questions to be answered/addressed –

  • Can the VNFs deliver the same level of service as the hardware appliances?
  • Can the Telco operators successfully transform their current operating models to support this new NFV paradigm?
  • Can a cloud meet the non-functional requirements (NFRs) of the VNFs?
  • Are the tools within the cloud fit for purpose for Telco grade workloads and services?
  • Are there enough standards to support the NFV movement?

All great questions that I will try to answer in future blogs. The European Telecommunications Standard Institute (ETSI), an independent, not-for-profit organisation that develops standards via consensus of their members, has been working on the answers to some of these questions. Others are being addressed by cloud vendors, like VMware.


Gary Hamilton is a Senior Cloud Management Solutions Architect at VMware and has worked in various IT industry roles since 1985, including support, services and solution architecture; spanning hardware, networking and software. Additionally, Gary is ITIL Service Manager certified and a published author. Before joining VMware, he worked for IBM for over 15 years, spending most of his time in the service management arena, with the last five years being fully immersed in cloud technology. He has designed cloud solutions across Europe, the Middle East and the US, and has led the implementation of first of a kind (FOAK) solutions. Follow Gary on Twitter @hamilgar.

Planning a DRP Solution for VMware Mirage Infrastructure

Eric_MonjoinBy Eric Monjoin

When I first heard about VMware Mirage in 2012—when Wanova was acquired by VMware and Mirage was integrated into our portfolio—it was seen more as a backup solution for desktops, or a tool for migrating from Windows XP to Windows 7. And, with an extension, it was possible to easily migrate a physical desktop to a virtual one, so most of the time when we had to design a Mirage solution, the question of DRP or HA came up as, “Why backup a backup solution?” Mirage was not seen as a strategic tool.

This has changed, and VMware Mirage is now totally integrated as an Extended UNIX Code tool to manage user desktops through different use cases. Of course, we still have backup and migration use cases, but we also have more and more customers who are using it to ensure desktops conform to IT rules and policies to ensure infrastructure reliability for Mirage. In this post we’ll describe how to design a reliable infrastructure, or at least give the key points for different scenarios.

Let’s first have a look at the different components of a Mirage infrastructure:

EMonjoin Basic Mirage Components

Figure 1 – Basic VMware Mirage Components

  1. Microsoft SQL Database—The MS SQL database contains all the configurations and settings of the Mirage infrastructure. This component is critical; if the Microsoft DB fails, then all Mirage transactions and services—Mirage Management Server service and Mirage Server service—
  2. SMB Shared Volumes—These could be any combination of NAS, Windows Server, desktop files, apps, base layers, or USMT files—all stored on theses volumes (except small files and meta-data.)
  3. Mirage Management Server—This is used to manage the Mirage infrastructure, but also acts as a MongoDB server instance on Mirage V5.4 and beyond. If it fails, administration is not possible until a new one is installed, but there’s no way to recover desktops since small files stored in the MongoDB are no longer available.
  4. Mirage Server—This is used by Mirage clients to connect into. Often, many Mirage servers are installed and placed behind load-balancers to provide redundancy and scalability.
  5. Web Management—A standard Web server service can be used to manage Mirage using a Web interface instead of the Mirage Management Console. The installation is quite simple and does not require extra configuration, but note that data is not stored on the Web management server.
  6. File Portal—Similar to Web management above, it is a standard Web server service used by end users to retrieve their files using a Web interface, and again, data is not stored on the file portal server.
  7. Mirage Gateway—This is used by end users to connect to Mirage infrastructure from an external network.

Now, let’s take a look at the different components of VMware Mirage and see which components can be easily configured for a reliable and redundant solution:

  • Mirage Management Server—This is straightforward, and actually mandatory, because with MongoDB, we need to install at least one more management server, and the MongoDB will synchronize automatically. The last point is to use a VIP on a load-balancer to connect to, and to route traffic to any available management server. The maximum number of Mirage management servers is seven due to MongoDB restrictions. Keep in mind that more than two members can reduce performance as you must wait for acknowledgement from all members for each writing operation to the database. The recommended number of management servers is two.
  • Mirage Server—By default we install at least two Mirage servers or more; one Mirage server per 1,000 centralized virtual desktops (CVDs) or 1,500 (depending on the hardware configuration), plus one for redundancy and use load-balancers to route client traffic to any available Mirage server.
  • Web Management and File Portal—Since these are just Web applications installed over Microsoft IIS servers, we can deploy them on two or more Web servers and use load-balancers in order to provide the required redundancy.
  • Mirage Gateway—This is an appliance and is the same as the previous component; we just have to deploy a new appliance and configure load-balancers in front of them. Like the Mirage server, there is a limitation concerning the number of connections per Mirage gateway, so do not exceed one appliance per 3,000 endpoints, and add one for resiliency.

Note: Most components can be used with a load-balancer in order to get the best performance and prevent issues like frequent disconnection, so it is recommended to the set load-balancer to support the following:

  • Two TCP connections per endpoint, and up to 40,000 TCP connections for each Mirage cluster
  • Change MSS in FastL4 protocol (F5) from 1460 to 900
  • Increase timeout from five minutes to six hours

Basically, all Mirage components can be easily deployed in a redundant way, but they rely on two other external components, both of which are key: the Microsoft SQL database and the SMB shared volumes, both of which work jointly. This means we have to pay special attention to which scenario is privileged:

  • Simple backup
  • Database continuity
  • Or full disaster recovery

The level of effort required is not the same and depends on the RPO/RTO required.

So let’s have a look on the different scenarios available:

  1. Backup and RestoreThis solution consists of performing a backup and restore of both Microsoft SQL database and storage volumes in case a major issue occurs on either component. This solution seems relatively simple to implement and looks inexpensive as well. It could be implemented if the attending RPO/RTO is not high. In this case, you have a few hours to restore the service, and there is no need to restore data that has been recently backed up. Restoring lost data backed up in the last couple of hours is automatic and quick. Remember, even if you lose your Mirage storage, all data is still available on the end-users’ desktop; it will just take time to centralize them again. However, this is not an appropriate scenario for large infrastructures with thousands of CVDs as it can take months to re-centralize all the desktops. If you want to use this solution, make sure that both the Microsoft SQL database and the SMB volumes are backed up at the same time. Basically, this means stopping Mirage services, performing a backup of the database using SQL Manager to get a snapshot of the storage volumes, and stopping MongoDB from backing up files. In case of failure, you have to stop Mirage (if it has not already done that by itself) and restore the last database backup and revert to the latest snapshot on the storage side. Keep in mind you must follow this sequence: first, stop all mirage services, and then the MongoDB services.
  1. Protect Microsoft SQL DatabaseSome customers are more focused on keeping the database intact, and this implies using Microsoft SQL clustering. However, VMware Mirage does not use ODBC connections, so it is not aware of having to move to a different Microsoft SQL instance if the main one has failed. The solution resides in using Microsoft SQL AlwaysOn technology, which is a combination of the Microsoft SQL clustering and the Microsoft failover cluster. It provides synchronization between “non-shared” volumes among nodes, but is also a virtual IP and virtual network name that will move to the remaining node in case of disaster, or during a maintenance period.
  2. Full Disaster Recovery/Multisite Scenario—This last scenario concerns customers who require a full disaster recovery scenario between two data centers with a high level of RPO/RTO. All components are duplicated at each data center with load-balancers to route traffic to a Mirage management server, Mirage server, or Web management/File portal IIS server. This implies using the second scenario in order to provide Microsoft SQL high availability, and also to perform a synchronous replication between two storage nodes. Be aware that synchronous replication can highly affect storage controller performance. While this is the most expensive of the scenarios since it requires extra licenses, it is the fastest way to recover from a disaster. An intermediate scenario could be to have two Mirage management servers (one per data center), but to shut down Mirage services, and replicate SQL database and storage volumes during the weekend.

EMonjoin Multi-Site Mirage

Figure 2 – E.g. Multi-Site Mirage Infrastructure

For scenario two and three, the installation and configuration of Microsoft SQL AlwaysOn in a VMware Mirage infrastructure is explained further in the white paper.


Eric Monjoin joined VMware France in 2009 as PSO Senior Consultant after spending 15 years at IBM as a Certified IT Specialist. Passionate for new challenges and technology, Eric has been a key leader in the VMware EUC practice in France. Recently, Eric has moved to the VMware Professional Services Engineering organization as Technical Solutions Architect. Eric is certified VCP6-DT, VCAP-DTA and VCAP-DTD and was awarded vExpert for the 4th consecutive year.

Virtual SAN Stretch Clusters – Real World Design Practices (Part 2)

Jonathan McDonaldBy Jonathan McDonald

This is the second part of a two blog series as there was just too much detail for a single blog. For Part 1 see: http://blogs.vmware.com/consulting/2016/01/virtual-san-stretch-clusters-real-world-design-practices-part-1.html .

As I mentioned at the beginning of the last blog, I want to start off by saying that all of the details here are based on my own personal experiences. It is not meant to be a comprehensive guide to setting up stretch clustering for Virtual SAN, but rather a set of pointers to show the type of detail most commonly asked for. Hopefully it will help you prepare for any projects of this type.

Continuing on with the configuration, the next set of questions regarded networking!

Networking, Networking, Networking

With sizing and configuration behind us, the next step was to enable Virtual SAN and set up the stretch clustering. As soon as we turned it on, however, we got the infamous “Misconfiguration Detected” message for the networking.

In almost all engagements I have been a part of, this has been a problem, even though the networking team said it was already set up and configured. This always becomes a fight, but it gets easier with the new Health UI Interface and multicast checks. Generally, when multicast is not configured properly, you will see something similar to the screenshot shown below.

JMcDonald VSAN Pt2 (1)

It definitely makes the process of going to the networking team easier. The added bonus is there are no messy command line syntaxes needed to validate the configuration. I can honestly say the health interface for Virtual SAN is one of the best features introduced for Virtual SAN!

Once we had this configured properly the cluster came online and we were able to configure the cluster, including stretch clustering, the proper vSphere high availability settings and the affinity rules.

The final question that came up on the networking side was about the recommendation that L3 is the preferred communication mechanism to the witness host. The big issue when using L2 is the potential that traffic could be redirected through the witness in the case of a failure, which has a substantially lower bandwidth requirement. A great description of this concern is in the networking section of the Stretched Cluster Deployment Guide.

In any case, the networking configuration is definitely more complex in stretched clustering because the networking across multiple sites. Therefore, it is imperative that it is configured correctly, not only to ensure that performance is at peak levels, but to ensure there is no unexpected behavior in the event of a failure.

High Availability and Provisioning

All of this talk finally led to the conversation about availability. The beautiful thing about Virtual SAN is that with the “failures to tolerate” setting, you can ensure there are between one and three copies of the data available, depending on what is configured in the policy. Gone are the long conversations of trying to design this into a solution with proprietary hardware or software.

A difference with stretch clustering is that the maximum “failures to tolerate” is one. This is because we have three fault domains: the two sites and the witness. Logically, when you look at it, it makes sense: more than that is not possible with only three fault domains. The idea here is that there is a full copy of the virtual machine data at each site. This allows for failover in case an entire site fails as components are stored according to site boundaries.

Of course, high availability (HA) needs to be aware of this. The way this is configured from a vSphere HA perspective is to assign the percentage of cluster resources allocation policy and set both CPU and memory to 50 percent:
JMcDonald VSAN Pt2 (2)

This may seem like a LOT of resources, but when you think of it from a site perspective, it makes sense; if you have an entire site fail, resources in the failed site will be able to restart without issues.

The question came up as to whether or not we allow more than 50 percent to be assigned. Yes, we can set it to use more than half consumed, but there might be an issue if there is a failure, as all virtual machines may not start back up. This is why it is recommended that 50 percent of resources be reserved. If you do want to configure a utilization of more than 50 percent of the resources for virtual machines, it is still possible, but not recommended. This configuration generally consists of setting a priority on the most important virtual machines so HA will start up as many as possible, starting with the most critical ones. Personally, I recommend not setting above 50 percent for a stretch cluster.

An additional question came up about using host and virtual machine affinity rules to control the placement of virtual machines. Unfortunately, the assignment to these groups is not easy during provisioning process and did not fit easily into the virtual machine provisioning practices that were used in the environment. vSphere Distributed Resource Scheduler (DRS) does a good job ensuring balance, but more control was needed rather than just relying on DRS to balance the load. The end goal was that during provisioning, placement in the appropriate site could be done automatically by staff.

This discussion boiled down to the need for a change to provisioning practices. Currently, it is a manual configuration change, but it is possible to use automation such as vRealize Orchestrator to automate deployment appropriately. This is something to keep in mind when working with customers to design a stretch cluster, as changes to provisioning practices may be needed.

Failure Testing

Finally, after days of configuration and design decisions, we were ready to test failures. This is always interesting because the conversation always varies between customers. Some require very strict testing and want to test every scenario possible, while others are OK doing less. After talking it over we decided on the following plan:

  • Host failure in the secondary site
  • Host failure in the primary site
  • Witness failure (both network and host)
  • Full site failure
  • Network failures
    • Witness to site
    • Site to site
  • Disk failure simulation
  • Maintenance mode testing

This was a good balance of tests to show exactly what the different failures look like. Prior to starting, I always go over the health status windows for Virtual SAN as it updates very quickly to show exactly what is happening in the cluster.

The customer was really excited about how seamlessly Virtual SAN handles errors. The key is to operationally prepare and ensure the comfort level is high with handling the worst-case scenario. When starting off, host and network failures are always very similar in appearance, but showing this is important; so I suggested running through several similar tests just to ensure that tests are accurate.

As an example, one of the most common failure tests requested (which many organizations don’t test properly) is simulating what happens if a disk fails in a disk group. Simply pulling a disk out of the server does not replicate what would happen if a disk actually fails, as a completely different mechanism is used to detect this. You can use the following commands to properly simulate a disk actually failing by injecting an error.  Follow these steps:

  1. Identify the disk device in which you want to inject the error. You can do this by using a combination of the Virtual SAN Health User Interface, and running the following command from an ESXi host and noting down the naa.<ID> (where <ID> is a string of characters) for the disk:
     esxcli vsan storage list
  2. Navigate to /usr/lib/vmware/vsan/bin/ on the ESXi host.
  3. Inject a permanent device error to the chosen device by running:
    python vsanDiskFaultInjection.pyc -p -d <naa.id>
  4. Check the Virtual SAN Health User Interface. The disk will show as failed, and the components will be relocated to other locations.
  5. Once the re-sync operations are complete, remove the permanent device error by running:
    python vsanDiskFaultInjection.pyc -c -d <naa.id>
  6. Once completed, remove the disk from the disk group and uncheck the option to migrate data. (This is not a strict requirement because data has already been migrated as the disk officially failed.)
  7. Add the disk back to the disk group.
  8. Once this is complete, all warnings should be gone from the health status of Virtual SAN.
    Note: Be sure to acknowledge and reset any alarms to green.

After performing all the tests in the above list, the customer had a very good feeling about the Virtual SAN implementation and their ability to operationally handle a failure should one occur.

Performance Testing

Last, but not least, was performance testing. Unfortunately, while I was onsite for this one, the 10G networking was not available. I would not recommend using a gigabit network for most configurations, but since we were not yet in full production mode, we did go through many of the performance tests to get a baseline. We got an excellent baseline of what the performance would look like with the gigabit network.

Briefly, because I could write an entire book on performance testing, the quickest and easiest way to test performance is with the Proactive Tests menu which is included in Virtual SAN 6.1:

JMcDonald VSAN Pt2 (3)

It provides a really good mechanism to test different types of workloads that are most common – all the way from a basic test, to a stress test. In addition, using IOmeter for testing (based on environmental characteristics) can be very useful.

In this case, to give you an idea of performance test results, we were pretty consistently getting a peak of around 30,000 IOPS with the gigabit network with 10 hosts in the cluster. Subsequently, I have been told that once the 10G network was in place, this actually jumped up to a peak of 160,000 IOPS for the same 10 hosts. Pretty amazing to be honest.

I will not get into the ins and outs of testing, as it very much depends on the area you are testing. I did want to show, however, that it is much easier to perform a lot of the testing this way than it was using the previous command line method.

One final note I want to add in the performance testing area is that one of the key things (other than pure “my VM goes THISSSS fast” type tests), is to test the performance of rebalancing in the case of maintenance mode, or failure scenarios. This can be done from the Resyncing Components Menu:

JMcDonald VSAN Pt2 (4)

Boring by default perhaps, but when you either migrate data in maintenance mode, or change a storage policy, you can see what the impact will be to resync components. It will either show when creating an additional disk stripe for a disk, or when fully migrating data off the host when going into maintenance mode. The compliance screen will look like this:

JMcDonald VSAN Pt2 (5)

This represents a significant amount of time, and is incredibly useful when testing normal workloads such as when data is migrated during the enter maintenance mode workflow. Full migrations of data can be incredibly expensive, especially if the disks are large, or if you are using gigabit rather than 10G networks. Oftentimes, convergence can take a significant amount of time and bandwidth, so this allows customers to plan for the amount of data to be moved while in or maintenance mode, or in the case of a failure.

Well, that is what I have for this blog post. Again, this is obviously not a conclusive list of all decision points or anything like that; it’s just where we had the most discussions that I wanted to share. I hope this gives you an idea of the challenges we faced, and can help you prepare for the decisions you may face when implementing stretch clustering for Virtual SAN. This is truly a pretty cool feature and will provide an excellent addition to the ways business continuity and disaster recovery plans can be designed for an environment.


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments

Virtual SAN Stretch Clusters – Real World Design Practices (Part 1)

Jonathan McDonaldBy Jonathan McDonald

This is part one of a two blog series as there was just too much detail for a single blog. I want to start off by saying that all of the details here are based on my own personal experiences. It is not meant to be a comprehensive guide for setting up stretch clustering for Virtual SAN, but a set of pointers to show the type of detail that is most commonly asked for. Hopefully it will help prepare you for any projects that you are working on.

Most recently in my day-to-day work I was asked to travel to a customer site to help with a Virtual SAN implementation. It was not until I got on site that I was told that the idea for the design was to use the new stretch clustering functionality that VMware added to the Virtual SAN 6.1 release. This functionality has been discussed by other folks in their blogs, so I will not reiterate much of the detail from them here. In addition, the implementation is very thoroughly documented by the amazing Cormac Hogan in the Stretched Cluster Deployment Guide.

What this blog is meant to be is a guide to some of the most important design decisions that need to be made. I will focus on the most recent project I was part of; however, the design decisions are pretty universal. I hope that the detail will help people avoid issues such as the ones we ran into while implementing the solution.

A Bit of Background

For anyone not aware of stretch clustering functionality, I wanted to provide a brief overview. Most of the details you already know about Virtual SAN still remain true. What it really amounts to is a configuration that allows two sites of hosts connected with a low latency link to participate in a virtual SAN cluster, together with an ESXi host or witness appliance that exists at a third site. This cluster is an active/active configuration that provides a new level of redundancy, such that if one of the two sites has a failure, the other site will immediately be able to recover virtual machines at the failed site using VMware High Availability.

The configuration looks like this:

JMcDonald Stretched Virtual SAN Cluster 1

This is accomplished by using fault domains and is configured directly from the fault domain configuration page for the cluster:

JMcDonald Stretched Virtual SAN Cluster 2

Each site is its own fault domain which is why the witness is required. The witness functions as the third fault domain and is used to host the witness components for the virtual machines in both sites. In Virtual SAN Stretched Clusters, there is only one witness host in any configuration.

JMcDonald Stretched Virtual SAN Cluster 3

For deployments that manage multiple stretched clusters, each cluster must have its own unique witness host.

The nomenclature used to describe a Virtual SAN Stretched Cluster configuration is X+Y+Z, where X is the number of ESXi hosts at data site A, Y is the number of ESXi hosts at data site B, and Z is the number of witness hosts at site C.

Finally, with stretch clustering, the current maximum configuration is 31 nodes (15 + 15 + 1 = 31 nodes). The minimum supported configuration is 1 + 1 + 1 = 3 nodes. This can be configured as a two-host virtual SAN cluster, with the witness appliance as the third node.

With all these considerations, let’s take a look at a few of the design decisions and issues we ran into.

Hosts, Sites and Disk Group Sizing

The first question that came up—as it almost always does—is about sizing. This customer initially used the Virtual SAN TCO Calculator for sizing and the hardware was already delivered. Sounds simple, right? Well perhaps, but it does get more complex when talking about a stretch cluster. The questions that came up regarded the number of hosts per site, as well as how the disk groups should be configured.

Starting off with the hosts, one of the big things discussed was the possibility of having more hosts in the primary site than in the secondary. For stretch clusters, an identical number of hosts in each site is a requirement. This makes it a lot easier from a decision standpoint, and when you look closer the reason becomes obvious: with a stretched cluster, you have the ability to fail over an entire site. Therefore, it is logical to have identical host footprints.

With disk groups, however, the decision point is a little more complex. Normally, my recommendation here is to keep everything uniform. Thus, if you have 2 solid state disks and 10 magnetic disks, you would configure 2 disk groups with 5 disks each. This prevents unbalanced utilization of any one component type, regardless of whether it is a disk, disk group, host, network port, etc. To be honest, it also greatly simplifies much of the design, as each host/disk group can expect an equal amount of love from vSphere DRS.

In this configuration, though, it was not so clear because one additional disk was available, so the division of disks cannot be equal. After some debate, we decided to keep one disk as a “hot spare,” so there was an equal number of disk groups—and disks per disk group—on all hosts. This turned out to be a good thing; see the next section for details.

In the end, much of this is the standard approach to Virtual SAN configuration, so other than site sizing, there was nothing really unexpected.

Booting ESXi from SD or USB

I don’t want to get too in-depth on this, but briefly, when you boot an ESXi 6.0 host from a USB device or SD card, Virtual SAN trace logs are written to RAMdisk, and the logs are not persistent. This actually serves to preserve the life of the device as the amount of data being written can be substantial. When running in this configuration these logs are automatically offloaded to persistent media during shutdown or system crash (PANIC). If you have more than 512 GB of RAM in the hosts, you are unlikely to have enough space to store this volume of data because these devices are not generally this large. Therefore, logs, Virtual SAN trace logs, or core dumps may be lost or corrupted because of insufficient space, and the ability to troubleshoot failures will be greatly limited.

So, in these cases it is recommended to configure a drive for the core dump and scratch partitions. This is also the only supported method for handling Virtual SAN traces when booting an ESXi from a USB stick or SD card.

That being said, when we were in the process of configuring the hosts in this environment, we saw the “No datastores have been configured” warning message pop up – meaning persistent storage had not been configured. This triggered the whole discussion; the error is similar to the one in the vSphere Web Client.
In the vSphere Client, this error also comes up when you click to the Configuration tab:

JMcDonald Stretched Virtual SAN Cluster 4

In the vSphere Client, this error also comes up when you click to the Configuration tab:

JMcDonald Stretched Virtual SAN Cluster 5

The spare disk turned out to be useful because we were able to use it to configure the ESXi scratch dump and core dump partitions. This is not to say we were seeing crashes, or even expected to; in fact, we saw no unexpected behavior in the environment up to this point. Rather, since this was a new environment, we wanted to ensure we’d have the ability to quickly diagnose any issue, and having this configured up-front saves significant time in support. This is of course speaking from first-hand experience.

In addition, syslog was set up to export logs to an external source at this time. Whether using the syslog service that is included with vSphere, or vRealize Log Insight (amazing tool if you have not used it), we were sure to have the environment set up to quickly identify the source of any problem that might arise.

For more details on this, see the following KB articles for instructions:

I guess the lesson here is that when you are designing your virtual SAN cluster, make sure you remember that having persistence available for logs, traces and core dumps is a best practice. If you have a large memory configuration, this is the easiest way to install ESXi and the scratch/core dump partitions to a hard drive. This also simplifies post-installation tasks, and will ensure you can collect all the information support might require to diagnose issues.

 Witness Host Placement

The witness host was the next piece we designed. Officially, the witness must be in a distinct third site in order to properly detect failures. It can either be a full host or a virtual appliance residing outside of the virtual SAN cluster. The cool thing is that if you use an appliance, it actually appears differently in the Web client:

JMcDonald Stretched Virtual SAN Cluster 6

For the witness host in this case, we decided to use the witness appliance rather than a full host. This way, it could be migrated easily because the networking was not set up to the third site yet. As a result, for the initial implementation while I was onsite, the witness was local to one of the sites, and would be migrated as soon as the networking was set up. This is definitely not a recommended configuration, but for testing—or for a non-production proof-of-concept—it does work. Keep in mind, that a site failure may not be properly detected unless the cluster is properly configured.

With this, I conclude Part 1 of this blog series; hopefully, you have found this useful. Stay tuned for Part 2!


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments

 

VMware vRealize Automation 7.0 – Finally the most desirable features and capabilities in a VMware Private Cloud Automation Solution have arrived!

By Cory Allen, RadhaKishna (RK) Dasari and Shannon Wilber

Anyone who has previously worked with vRealize Automation 6.x or earlier versions of VMware Cloud Automation Center 5.x, understands historically just how challenging it can be to manage the overall planning, design, deployment and architecture of an end-to-end Private Cloud Automation solution.

Our Professional Services Engineering team over the past few years have worked extensively with VMware engineering organizations and many diverse customer Cloud Automation deployment scenarios globally.  Our team extensively tests and researches the most effective and proven methodologies to implement vRealize Automation as a solution help mitigate and reduce historical implementation challenges.

So guess what?  We are really excited and impressed with the new vRealize Automation 7.0… 🙂

VMware finally has a new Private Cloud Solution and Product with the launch of vRealize Automation 7.0, that delivers a much easier and user friendly deployment method using the new slick vRealize Automation Installation Wizard. This new installation and configuration wizard enables a simplified and centralized deployment unlike anything you have seen in vRealize Automation before. The challenges of the installation and configuration are a thing of the past, having been solved in a whole new way with this new release of vRealize Automation.

In particular, during early testing and validation our team had performed during betas, we quickly became very impressed with this new feature and capability and immediately realized just how valuable the new vRealize Automation Installation would be for efficiency, ease of use, intuitive, and stability for the VMware field delivery teams and customers globally. The most significant change our team observed that was very cool, was that you do not have to do so many manual installation tasks anymore – which can get really tedious during the deployment of a complex highly available VRA solution.

So now let’s get to the best part – where the fun begins – some basic questions and answers.

  1. How has the installation and configuration of vRealize Automation 7.0 changed from previous versions to include 6.x and 5.x?
    Response: Well, good news! The new installation features and capabilities offered include the option to deploy a Minimal Deployment and an Enterprise Deployment.
  • The vRealize Automation Installation Wizard Minimal Deployment offers a simple non-distributed installation without high availability shown here:
    PSE Deployment 1
  • The vRealize Automation Installation Wizard provides an option for an Enterprise Deployment distributed with or without high availability options shown here:

PSE Expanded Deployment

  1. Now I have two options to perform the installation, so what is the big deal?

    Response: That is not all the installation has to offer, we are just getting started! The new installation wizard now has a cool new Gadget called the “Prerequisite Checker” available within the Wizard. This new feature leverages a new IaaS Management Agent to install on each IaaS Hosts so that the “Prerequisite Checker” that can automatically from a central location within the Wizard, automate the installation and configuration of all Microsoft Windows Server IaaS Prerequisites. No longer do architects and engineers have to manually logon to each server, configure the prerequisites, reboot, or worse – forget to install all required prerequisites. The new vRealize Automation Installation Wizard Prerequisite Check Takes care of it all. Just be careful not to get to comfortable here, there is more fun.

The vRealize Installation Wizard Installation Prerequisites Page to Download Management Agents is shown here:

PSE Deployment 3

vRealize Installation Wizard New “Prerequisite Checker” scanning IaaS Hosts within the Enterprise Deployment option:

PSE Deployment 4

The vRealize Installation Wizard New “Prerequisite Checker” identifies Windows IaaS Server Hosts that may not have “Some prerequisites are not met” notification. The wizard has a “Fix” button that enables this cool new tool too automatically fix each IaaS Host with a simple click of a button.

PSE Prerequisite Checker 1
The cool new “
Prerequisite Checker” will notify you when all Windows IaaS Machines have had all prerequisites installed configured. Guess what? If for some reason a Windows IaaS Machine goes offline during the process, simply wait for the machine to come back online and click “Run” or “Fix” a second time for where you last left off. Pretty cool stuff huh?

PSE Prerequisite Checker 2

 

PSE Prerequisite Checker 3

  1. Wow! That is pretty cool. After the “Prerequisite Checker” is done completing installation tasks, what other cool automated and fancy things can vRealize Automation 7.0 do? What about authoring infrastructure or applications? Has anything changed to enable an easier and more streamlined method for developing infrastructure and applications?Response: Check out the new (and unified) blueprint design canvas for authoring infrastructure virtual machines and applications with Machine Types and Software Components which now include Application Services as standard service. The new blueprint designer is probably the coolest, and most significant, new feature that has been implemented that allows for building simple virtual machines to complex application based blueprints all within a single design canvas.

New Unified Blueprint Design Canvas for Authoring Infrastructure and Applications

PSE Unified Blueprint Design

  1. Now that the first question has been addressed for new unified blueprints, tell me how Application services works with the new service authoring model.Response: Here is an overview of how the new Application Services works compared to previous versions of vRealize Automation Application Services in the 6.x versions:Application Services formerly Application Director used to be an optional application blueprint authoring feature that was a separate, external virtual appliance that had to be manually deployed, configured, and integrated with vRealize Automation 6.x environments. Following the former deployment methods in older Application Services versions, application blueprints had to be manually created as a separate component from single and multi-machine blueprints in vRealize Automation 6.x. Now in vRealize Automation 7.0, Application Services is a standard feature that is offered as part of the overall deployment and is available within the unified blueprint. Application services is no longer a separate virtual appliance or external component. Application Services, which now includes Software Components, have integrated authoring capabilities in the vRealize Automation 7.0. Application Services and runs as a service on each vRealize Automation 7.0 appliances, scaling as appliances are added into the overall scalable architecture.

New Capabilities to Create Applications and Software Components in the Unified Blueprint

PSE Unified Blueprint 2

VMware’s customers will be very impressed that they can now create multi-tier blueprints with combined infrastructure and application dependencies to author software components.

Create a Software Component such as an Apache Web Server Service

PSE Unified Blueprint 3

  1. Wow that is very cool, I can now create infrastructure virtual machines, create Software Components and then add my applications by dragging and dropping my applications onto the design canvas? How can I add networking or security policies to my unified blueprints?Response: In addition, another super cool new feature and capability with the unified blueprint is the option to integrate NSX On-Demand Networking and Security components into these blueprints. This is a radical new networking and security enhancement within the blueprint design canvas that allows authoring of services all in one single unified designer within vRealize Automation 7.0 that can include NSX features and Network Components to include:
  • On-Demand Private Networks
  • On-Demand NAT Networks
  • On-Demand Routed Networks

Security Components:

  • On-Demand Security Groups
  • Existing Security Groups
  • Security Tags

New Blueprint with NSX On-Demand Networking and Security “Drag & Drop” Authoring Functionality

PSE Unified Blueprint 4


Cory AllenCory Allen has been in the IT world for over 18 years and is a Technical Solutions Architect for VMware. He has been with VMware since June of 2015 working on the PSE Cloud Automation Team. Before coming to VMware, he was with Parker Kannifin where he was the Hybrid Cloud Architect where his main task was to Design and Build a Private Internal Cloud that was fully automated and able to scale to the whole organization worldwide.

RK DasariRadhaKrishna (RK) Dasari is a Technical Solutions Architect for the Professional Services Engineering team. He specializes in developing architecture designs and service kits for vRealize Automation and vCloud Air. Prior to VMware, RK had a career spanning thirteen years at Dell as a software developer, software architect and pre-sales solutions architect.

Shannon WilberShannon Wilber is a Technical Solution Architect at VMware with eighteen years of information technology experience with architecture design, implementations and infrastructure management for commercial and enterprise scale IT solutions for Software Defined Data Centers and Hybrid Cloud environments. Proven team leadership and technical experience to guide complex IT projects through the planning, design, implementation, migration and optimization stages for diverse IT solutions for customers globally. Shannon is also a VMware Certified Professional (VCP5-DCV), EMC Proven Professional and EMC Certified Cloud Infrastructure Specialist. 

VMware vRealize Operations Python Adapter – A Hidden Treasure

Jeremy WheelerBy Jeremy Wheeler

Even more power comes out of VMware vRealize Operations when enabling the vRealize Operations Python Adapter, adding additional intelligent monitoring and action capabilities.

To do this, execute the following steps:

Image 1:

JWheeler Image 1

  1. Select ‘Solutions’
  2. Select ‘VMware vSphere’
  3. Select ‘vCenter Python Adapter’

Add your vCenters, and match what you configured under the ‘vCenter Adapter’ section above #3 in image 1.

What Does This Do for Me?

When viewing the default dashboard ‘Recommendations’ you might see something such as the following in your ‘Top Risk Alerts For Descendants’

Image 2:

JWheeler Image 2

By selecting the alert, you will be presented with another dialog to dig into, which is an object we should inspect:

Image 3:

JWheeler Image 3

After I select ‘View Details’ it will present me with the object details of the virtual machine ‘av_prov1’.

Image 4:

JWheeler Image 4

Without Python Adapters configured you will not see the ‘Set Memory for VM’ button; with it configured it will be visible under the ‘Recommendations’ section.

Image 5:

JWheeler Image 5

After selecting ‘Set Memory for VM’ you will be presented with a new dialog (Image 5). Here we can see what the new memory recommendation would be and adjust or apply it. Additionally, if you want the changes to happen now, you can select Power-Off/Snapshot. Without powering off the virtual machine, vRealize Operations will attempt to hot-add the additional memory if the OS will support it.

Image 6:

JWheeler Image 6

Once you select ‘Begin Action’ you will see the dialog in Image 6.


Jeremy Wheeler is an experienced senior consultant and architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013