RHELAH support on vSphere

Hi everyone, I’m happy to announce support for Red Hat Enterprise Linux Atomic Host (RHELAH) running on ESXi. This enables vSphere admins to offer RHELAH as a supported container host OS to developers either experimenting with or creating container-based applications.

Similar to our existing support for RHEL 7.x, open-vm-tools is included as a standard part of RHELAH. And over the past couple of months, the team from Redhat and VMWare have also refactored open-vm-tools to run in its own system container while maintaining traditional Tools functionality. Updates to open-vm-tools will be made available as new host OS images are refreshed and published.

Support for RHELAH begins with the recently released v7.4. ESXi support is available from v6.0 to v6.5. Installation instructions are available and additional information regarding on running the vm can be found here –

http://partnerweb.vmware.com/GOSIG/RHEL_Atomic_Host.html

The post RHELAH support on vSphere appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog

Key Manager Concepts and Topology Basics for VM and vSAN Encryption

At VMworld 2017 VM and vSAN Encryption and security of vSphere in general became VERY popular topics. And in those discussions the topic of Key Managers came up and specifically “How many key managers should I have?” was a recurring question.

This blog article will give you two examples of key manager topologies and will introduce you to some management concepts. Because every environment comes with unique configurations and requirements, the intent is not to “boil the ocean” but to just get you thinking and help you understand the underlying pieces so you can make more informed decisions.

Availability

The biggest requirement of key management is availability. The analog I use when talking about this is DNS. Nobody runs with a single DNS server in their environment. (I hope!) You have multiple replicating DNS servers “just in case” something goes wrong. Maybe in your single site you’ll have at least two and maybe three or four. Maybe you even have a DNS server or two  running in a cloud or have servers at another site, again, “just in case”. Why? Because if DNS is down then everything is essentially dead in the water. All roads lead to DNS, all roads can end if there’s no DNS.
The same holds true for key management. If the key management infrastructure is down, you can’t encrypt new VM’s or re-key existing VM’s! Even more importantly, you DON’T want that single point of failure. If you have just one KMS and something bad happens to it and you can’t recover the keys then you have some serious issues to attend to! There are no back doors to decrypt a VM. If you lose the keys, you’ve lost the data unless you’ve backed it up. See “Resources” below where James Doyle from our GSS organization did a talk on this at VMworld. A much watch!

Business Critical Infrastructure

This is why Key Management will become the next (critical) datacenter infrastructure requirement, just like DNS and NTP have become. This isn’t a “I need a KMS for vCenter” discussion as much as it is a “I need a KMS for the business” discussion.
After all, you don’t install DNS to make it easier to run just the datacenter. You run DNS because without it the business won’t run. Today you may only need a KMS for vSphere but going forward the business may need it for a whole host of things. Encrypted VM’s might be your first need for a KMS but it won’t be your last.
Note how I didn’t list other requirements like HSM’s (Hardware Security Modules). vSphere is just a KMIP client. These functions are handled by the Key Manager you choose. If you want HSM’s then the Key Manager will talk to them and vSphere will talk to the KMS. Honestly, this lessens complexity while providing you the best choice to meet your needs.

Key Manager Basics

There are a few things to set up in vCenter that are covered in the documentation but first, let’s go over some of the concepts and terms.
KMIP = Key Management Interoperability Protocol. This is the standard where any KMIP client can speak to a KMIP KMS and it should just work. Extensive testing is done each year at the RSA Conference. You can learn more at Wikipedia which actually has a great writeup on the whole process.
DEK = Data Encryption Key. This is the key that the ESXi host generates when you encrypt a VM. This is used to encrypt the data and is stored, encrypted, in the VMX/VM Advanced settings.
KEK = Key Encryption Key. This is the key from the KMS that encrypted the DEK. I pointer to the KMS Cluster and the KEK key ID are in the VMX/VM Advanced settings.
Key Manager Cluster/Alias = In vSphere this is a collection of the FQDN/IP addresses of replicating key managers. The name of the cluster is stored, along with the key ID of the KEK, with each VM. When a VM is powered on, this is what vCenter uses to retrieve the correct KEK to unlock the VM. Don’t get too wrapped up in the term “cluster”. It’s really a collection of FQDN’s and/or IP addresses that represent a group of replicating Key Managers. That’s it. 
VM or vSAN encryption, it’s all the same libraries. Note: Whether you are using VM Encryption or vSAN Encryption the configuration (and libraries and crypto) are all the same. The use the same interfaces to connect to the KMS and the same crypto libraries to encrypt or decrypt.
More great information is located in our vSphere 6.5 documentation. I encourage you to read it and watch the videos!

Key Manager Cluster/Alias

Key Managers today are usually set up in a way that they replicate keys to one another. If I have three instances of a key manager, KMS-A, KMS-B and KMS-C, they replicate the keys between them. If I create a key on KMS-A it will show up in KMS-B & KMS-C at some point. You’ll have to check with your key manager product to see how quickly the replication happens.
Using the example above, in vCenter I would create a key manager cluster/alias. In my example I’ll call it “KMSCluster” and add KMS-A, KMS-B and KMS-C into that KMS Cluster. I would then establish a trust with each of the key managers. There are multiple ways to establish trust and I would suggest you consult the documentation for your key manager on how best to do this.
Because vSphere currently uses a Key Management Operability Protocol 1.1 compliant library, any KMIP 1.1 key manager should work. For more information on which solutions have been certified go to VMware’s Hardware Compatibility List and search for the category of “kms”. 

Key Manager connection retry

Using the example above, if KMS-A is unavailable then vCenter will try KMS-B (next KMS in order). If KMS-A is up but the KMS service, for some reason, doesn’t respond, then vCenter will wait 60 seconds for a response. If after that 60 seconds there is no response, vCenter will try KMS-B. If KMS-A doesn’t respond (e.g. no IP connection at all) then vCenter won’t wait the 60 seconds and will try KMS-B immediately.
The maximum vCenter will wait for a KMS to respond is 60 seconds. This is not something that can be configured.

Separation of duties (when you can)

Ideally, you would want to have a separation of duties when it comes to key management. Large organizations that have a security team may want to control the keys and the IT admin would just use the key manager as a service.
Understandably, not every organization has that ability so for those IT admins that are also the network/storage/security/chief cook/bottle washer types, what you want to consider doing is ensuring only your most trusted admins can administer the key managers and that you have sufficient controls in place to ensure isolation from other network traffic if possible. If you have a management cluster they this might be a good place to run your KMS VM’s, if that’s what you are using. The goal is that only a select few administrators should be able to affect any change on these systems. Off the top of my head, I can’t think of a good business reason for a junior administrator to have any access.
Note about running some of your KMS’s on a management cluster: One thing to keep in mind is to avoid the Catch-22/Chicken&Egg scenario. What I mean by that is that especially with Single Site configurations, you really should have a separate infrastructure for your key management. For example, running all your key manager VM’s solely on an encrypted vSAN isn’t ideal. With vSAN Encryption you configure vCenter and then the hosts communicate with the KMS. If you think about it, do you really want the box that holds your key locked in a box that can only be opened by the key inside the inner box? Nope. Will it work? Yup. Is it a good practice? Probably not. A possible solution would be to have at least one of your key managers running in a cloud. Remember, availability, availability, availability.
The same is true for vCenter and PSC’s in a VM Encryption scenario. You shouldn’t encrypt them using VM Encryption because they would then need to boot up to get their encryption key to boot up. It’s best to run them in a separate management cluster. THOSE VM’s you COULD run on vSAN encryption and that is supported. (because the hosts themselves communicate with the KMS in a vSAN Encryption model)

Topologies

Single Site

As mentioned above, if you have a single site then you probably want to have, at minimum, two replicating key managers. Ideally, you probably want at least three so that at no time are you relying on a single key manager instance. In some cases, as I pointed out above, you may want to run one of your replicating key managers in a cloud service. Some of the certified key managers we work with allow for that type of capability.

What we’re looking for here it the avoidance of a single point of failure within your site. For example, don’t allow all your KMS VM’s (if that’s what you’re using) to run on the same host. Use Host Affinity Rules to keep them separate, ensuring that someone tripping over the power cord doesn’t cause an outage. Think through the scenarios for your environment. Come up with disasters that “could” happen and plan accordingly.

Multi Site

For multi-site, things get more interesting. You want all the KMS servers running and replicating across the sites. Within vCenter, you’ve created your KMS Cluster/Alias and you start adding your FQDN’s or IP’s.

KMS Order

But there’s something to take into consideration. And that’s the order in which you add those KMS. vCenter will try the first KMS on the list.
In the scenario below I have two sites, Site-A and Site-B. In Site-A I have KMS-A, KMS-B and KMS-C. In Site-B I have KMS-D, KMS-E and KMS-F.
In Site-A I want the order to go A,B,C,D,E,F
In Site-B I want the order to go D,E,F,A,B,C
Why? As mentioned, if vCenter doesn’t reach that KMS for 60 seconds it will try the next KMS on the list. What you don’t want to set up is a situation whereby vCenter is going to a remote KMS before exhausting all of the local KMS’s.
I don’t want either site to have to get a key from the remote site unless absolutely necessary. In my example I haven’t added in any additional latencies or other network configurations that may effect the transit of the key from one to the other.

What if?

At VMworld, one of our GSS guys, James Doyle, has really jumped on the encryption bandwagon and did a fantastic presentation on encryption from a Day 2 / disaster strikes standpoint.
As you can imagine, GSS gets a lot of customers calling up that might be in a the middle of an IT disaster. With those scenarios in mind, James added a “What if they were using VM Encryption?” to the mix.
Imagine the scenario where you DO have just one KMS system and a bunch of encrypted VM’s and Murphy strikes and you’re left with a bunch of running encrypted VM’s but no KMS and no way to every get those keys back.
Don’t panic. Whatever you do, do NOT shut things down!
James will go in to detail on how you can recover from many of these situations. I can’t recommend this high enough.

Wrap-Up

I hope this has helped give you a better understanding of KMS topologies and the needs and caveats when configuring them and vCenter. This is not meant to be the be-all/end-all for this topic. You should absolutely discuss this with your KMS vendor any specific recommendations they have and incorporate it into your design.
mike

The post Key Manager Concepts and Topology Basics for VM and vSAN Encryption appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog

Three Key Reasons for Joining Modernize Data Centers Track at vForum Online

As digital transformation increases across the business world, the era of costly, complex legacy infrastructures is coming to an end. But what will it take to modernize infrastructures in such a way that IT gets the agility and flexibility it needs to operate, innovate, and scale to meet the demands of today’s competitive business climate?

To get answers from experts in the IT community, join us on October 18th for the Modernize Data Centers track at vForum Online Fall 2017. During this free half-day event — which also happens to be our largest virtual IT conference — you’ll receive the guidance and information you need to successfully evolve to a modernized infrastructure. Best of all, you get to attend from the comfort and convenience of your own desk.

To give you a better idea of what makes this a must-attend event for any IT professional, we’ve put together a list of three key reasons to join. Have a look.

  1. Attend Breakout Sessions
    Want to find out how you can transform your infrastructure to make delivery simple for any application on any platform? Perhaps you’re interested in something more specific, like upgrading your virtualization platform with VMware vSphere 6.5, getting to know storage virtualization with VMware vSAN better, accelerating the hybrid cloud with VMware Cloud on AWS, or taking a deep dive into VMware Cloud FoundationTM architecture?
    You’ll find all of this and more during our expert-led Modernize Infrastructure breakout sessions in the Modernize Data Centers track. Pick the ones you want to attend, investigate VMware solutions more deeply, and get the direction you need for building out a modern infrastructure that supports your business needs. 
  2. Chat with Experts and Get Your Questions Answered
    Have questions about the Software-Defined Data Center (SDDC)? Or maybe you’ve heard the buzz around VMware Cloud on AWS and just want to know more. At vForum Online, you get to talk these things through with the people who know them best: the experts.
    During our “Chat with the Software-Defined Data Center Experts” session, VMware pros will be live on video, answering your questions about everything from hyper-converged infrastructure and the SDDC to virtualization, containers, OpenStack, and more.
    In the  “What’s New with VMware Cloud” chat session, the experts will give the scoop on VMware Cloud on AWS. Our cloud pros will be ready to discuss the VMware cloud strategy, requirements for a modern infrastructure, and how to create successful planning roadmaps in preparation for digital transformation to the hybrid cloud.
  3. Practice With the Products in Hands-On Labs
    Theory is great, but nothing beats practical experience. And that’s what you’ll get with our hands-on labs. During these sessions, you’ll learn how to work with a modernized infrastructure by building your own SDDC and discovering for yourself what’s new with vSphere 6.5. Discover, make mistakes, and explore in real time what it takes to create a modern infrastructure.

vForum Online Fall 2017 is fast approaching. Don’t miss this chance to learn about the modern infrastructure with your peers and experts in the IT community. Register for the event today, and mark your calendar. We hope to see you there.

 

 

The post Three Key Reasons for Joining Modernize Data Centers Track at vForum Online appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog

Understanding the Impacts of Mixed-Version vCenter Server Deployments

There are a few questions that come up quite often regarding vCenter Server upgrades and mixed-versions that we would like to address. In this blog post we will discuss and attempt to clarify the guidance in the vSphere Documentation for Upgrade or Migration Order and Mixed-Version Transitional Behavior for Multiple vCenter Server Instance Deployments. This doc breaks down what happens during the vCenter Server upgrade process and describes the impacts of having components – vCenter Server and Platform Services Controller (PSC), running at different versions during the upgrade window. For example, once you get some vCenter Server instances upgraded, say to 6.5 Update 1, you won’t be able to manage those upgraded instances from any 5.5 instances. While most of the functionality limitations manifest themselves when upgrading from 5.5 to 6.x, there could also be some quirks in environments running a mix of 6.0 and 6.5. There are a couple of additional questions that seem to arise from this doc so let’s see if we can address them.

The Upgrade Process

I’m not going to go through the entire process here, but it is important to understand the basics of how a vCenter Server upgrade works. Remember that there are two components to vCenter Server – the Platform Services Controller (PSC) which runs the vSphere (SSO) Domain and vCenter Server itself. For a vCenter Server upgrade, the vSphere Domain and all PSCs within it, must be upgraded first. Once that is complete, then the vCenter Servers can be upgraded. Obviously, if you have a standalone vCenter Server with an embedded PSC, this is a much simpler proposition. But, for those requiring external PSCs because of other requirements such as Enhanced Linked Mode, just remember the PSCs need to be upgraded first.

Mixed-Version Upgrade Phases

The other important point to make here is that upgrading by site is not supported. Looking at the above example, you can see there are two sites each with an external PSC and a vCenter Server. It is a common that a customer would like to upgrade an entire site, test, and then move onto the next site. Unfortunately, this is not supported and all PSCs within the vSphere Domain across all sites must be upgraded first.

Mixed-Version Support

Now, on to the questions mentioned earlier. The first question is, “Can I run vCenter Servers and Platform Services Controllers (PSCs) of different versions in my vSphere Domain?”  The answer here is yes, but only during the time of an upgrade. VMware does not support running different versions of these components under normal operations within a vSphere Domain. The exact verbiage from the article is, “Mixed-version environments are not supported for production. Use these environments only during the period when an environment is in transition between vCenter Server versions.” So, do not plan on running different versions of vCenter Server and PSC in production on an ongoing basis.

The second question is then, “How long can I run in this mixed-version mode?” This question is a bit tougher to answer. There is no magic date or time bomb when things will just stop working. This is really more of a question of understanding the risks and knowing how problems may affect the environment should something go wrong while in this mixed-version state.

The Risks

An example of one such risk would be if you were upgrading to vSphere 6.5 from 5.5. Let’s say you had your vSphere Domain (i.e. PSCs) and one vCenter Server already upgraded leaving you with 1 or more vCenter Server 5.5 instances. Imagine that something happens leaving a vCenter Server 5.5 completely wiped out. You could restore that vCenter Server 5.5 instance and be back in production as long as you have a good, current backup. If the backup you need to restore from was taken prior to the start of the vSphere Domain upgrade, you would not be able to use it to restore. The reason for this is that the vCenter Server instance that you would be restoring is expecting a 5.5 vSphere Domain and the communication between that restored vCenter Server instance and the 6.5 PSC would not work. An alternative to this would be to rollback the entire vSphere Domain and any other vCenter Servers that were upgraded.

Another risk would be if we are unable to restore that instance because the backups were bad (it does happen) or you couldn’t accept the outcome of losing the data since that backup was taken.  The result here is that you would be forced to rebuild that vCenter Server instance and re-attach all the hosts. This may not be desirable because this new vCenter Server instance would have a new UUID and all of the hosts, VMs, and other objects would also have new moref IDs. This means that any backup tools or monitoring software would see these as all net new objects and you would lose continuity of backups or monitoring. You also would have to rebuild the vCenter Server instance as 6.5 which also may not be desirable because you may have an application or other constraint that requires a specific version of vCenter Server. If you rebuild the instance as 6.5 you may break that application.

Finally, let’s consider the possibility of having a PSC failure instead of losing a vCenter Server. What happens?  Normally, you could easily repoint a vCenter Server instance to another external PSC within the same SSO Site. However, this would not be possible if the vCenter Server is not running the same version as the PSC you are attempting to repoint to. For example, if you had a vCenter Server 5.5 or 6.0 and they were pointing to a 6.5 PSC (because it has already been upgraded), if that PSC failed you would not be able to repoint that vCenter Server to another PSC. Remember that all PSCs must be upgraded first so all PSCs should be running 6.5 already. The only way to recover from this scenario is to restore or redeploy the failed PSC which may take longer than repointing.

Recommendations

So, give the above scenarios, what do we tell a customer who asks, “My upgrade plan spans multiple sites over multiple months. How should I plan my upgrade?” Here are our recommendations:

  1. Minimize the upgrade window
  2. Follow the upgrade documentation
  3. Take full backups before, during, and after the upgrade
  4. Check the interop matrices and test the upgrade first

The first recommendation is to minimize the upgrade window as much as possible.  We understand that there’s only so much you can do here, but it is important to reduce the amount of time you’ll be running different versions of vCenter Server (and PSC) in the same vSphere Domain. The second recommendation is to, no matter how tempting to do otherwise, upgrade the entire vSphere Domain (SSO Instances and PSCs) first as is called out in the vSphere Documentation. It is not supported to upgrade everything in one site and then move onto the next. You must upgrade all SSO Instances and PSCs in the vSphere Domain, across ALL sites and locations, first. Third, make sure you have good backups every step of the way. While snapshots can be a path to a quick rollback, when dealing with SSO, PSCs, and vCenter Server they don’t always work. Taking a full backup ensures the ability to restore to a known clean state. Last, and certainly not least, do your interoperability testing and test the upgrade in a lab environment that represents your production environment as much as possible.

Emad has a great 3-part series on upgrades (Part 1, Part 2, Part 3) so be sure to check it out prior to testing and beginning your upgrade. Also know and understand the risks and impacts of problems during the upgrade process. Finally, know how the upgrade process is going to affect all of the yet-to-be-upgraded parts of your environment and have good rollback and mitigation plans if any issues come up.

The post Understanding the Impacts of Mixed-Version vCenter Server Deployments appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog

Monthly Security Patch Program for the vCenter Server Appliance

The vCenter Server Appliance (VCSA) has become the recommended deployment type starting with vSphere 6.5. The three main components of the VCSA – operating system, database, and application – now all fall under VMware’s umbrella. The VCSA now uses Photon OS which is a custom operating system built from the ground up for virtualization and removes the dependency on third party support. This not only provides one central place for support, but also allows for quicker releases of security patches.

VMware is now introducing a new Monthly Security Patch Program for the VCSA. The program will deliver important OS vulnerability patches on a monthly release cycle. VMware will monitor and fix any newly discovered OS vulnerabilities. As detailed in the VMware Security Response Policy, the response time to vulnerabilities depends on the severity. When there’s a Critical vulnerability, VMware will immediately start working on a fix or corrective action and provide it to customers in the shortest commercially reasonable amount of time. For Important through Low categorized vulnerabilities, VMware will deliver a fix with the next planned maintenance or update release of the product and where relevant. There’s no change to the existing policy. To better serve customers, we are adding this new Monthly Security Patch Program designed for VCSA.

The Monthly Patch will be cumulative and allow customers to have a choice of which patches to apply without having to apply all of them. If there’s no security patch content in a given month, we will skip the release of that month. If there’s an update or a scheduled patch, the monthly patch will be added to it. The monthly patches can be found on the My VMware patch portal (My VMware login required). Customers can sign up to receive security alerts on the VMware Security page and see a list of all VMware security advisories.

To learn more about VCSA patching and to provide feedback or ask questions, please see this article on the VMware Security Blog.

The post Monthly Security Patch Program for the vCenter Server Appliance appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog

Get your vSphere questions answered at VMworld Europe 2017

After an action packed week at VMworld US in Las Vegas, the Cloud Platform Business unit has assembled in Barcelona for VMworld Europe 2017. We’re excited to talk to our European friends about the products our group supports: vSphere (and especially vSphere 6.5), and now VMware Cloud on AWS.

This post is an attempt to pull all of the activities our group has planned for the Barcelona show into one place. We’ll see you soon!

Sessions

  • The master list of our sessions, broken up by category, has its own page on the vSphere blog.
  • Here are our last-minute session suggestions for you:
    • Wednesday, 12:30 PM: What’s Next for vSphere? [SER3154SE]. Find out from the VP of Product about the future of vSphere. She’s bringing a customer along for the discussion, it should be good.
    • Thursday, 10:30 AM: Real World IT Gurus Share Their Perspective on Operations Management for the Multicloud Era [MGT1218PE]. Come here from customers about their experiences of creating an operational model where they act more like service providers.

Come visit with us in the booth!

We’ll have experts in our booth to talk about all things vSphere. Have a question? Here are the times we’ll be in the booth:

  • Tuesday: 10:30 – 7:30
  • Wednesday: 10:30 – 7: 00
  • Thursday: 10:30 – 2:30

Here are some of the things we’ll be talking about:

  • Simplified vSphere Administration
    • vCenter Server Appliance and HA
    • vSphere Lifecycle Management
    • REST-based APIs
    • HTML 5 vSphere Client
    • vSphere Upgrades
  • Comprehensive vSphere Security at Scale
    • At-Rest and In-Motion Encryption
    • Secure Chain of Trust
    • Audit Quality Loggig
  • Proactive Data Center Management
    • Proactive HA
    • DRS / Intelligent Workload Placement
    • Predictive DRS
  • New Workloads
    • vSphere Scale-Out
    • Tech Preview: Persistent Memory
    • Tech Preview: vGPU
    • Tech Preview: RDMA

Our experts want to help you resolve your hardest questions

Our experts will be in the Meet the Expert area. If you have a particularly hard question, make sure to plan to visit them.

Day Pod Time Session Expert
Tues 1 11:15- 12:00 Emad Younis MTE4729-SER
Tues 4 11:15 – 12:00 Frank Denneman MTE4720-SER
Tues 4 12:15 – 1:00 Mike Foley MTE4716-SER
Tues 4 3:15 – 4:00 Dennis Lu MTE4724-SER
Tues 4 4:15 – 5:00 William Lam MTE4724-SER
Wed 4 11:15 – 12:00 Alan Renouf MTE4723-SER
Wed 4 12:15 – 1:00 Kyle Ruddy MTE4722-SER
Wed 4 1:15 – 2:00 Eric Grey MTE4718-SER
Wed 4 4:15 – 5:00 Adam Eckerle MTE4719-SER
Thurs 4 9:15 – 10:00 Mike Foley MTE4716-SER
Thurs 1 10:15 – 11:00 Emad Younis MTE5729-SER
Thurs 4 10:15 – 11:00 Frank Denneman MTE4720-SER
Thurs 4 11:15-12:00 Ravi Soundararajan MTE4725-SER
Thurs 4 12:15 – 1:00 Kyle Ruddy MTE4721-SER

Get your hands dirty in a Hands-On Lab

Try out the new features of vSphere 6.5 in a hands-on lab. Here are the HOLs that are specific to vSphere:

  • HOL-1804-01-SDC: [vSphere 6.5] Performance Diagnostics and Benchmarking
  • HOL-1804-02-CHG: [vSphere 6.5] Challenge Lab
  • HOL-1811-01-SDC: [vSphere v6.5] What’s New
  • HOL-1811-02-SDC: [vSphere with Operations Management] Getting Started
  • HOL-1811-03-SDC: [vSphere with Operations Management] Advanced Topics
  • HOL-1811-04-SDC: [vSphere Security] Getting Started
  • HOL-1811-05-SDC: [vSphere Automation] PowerCLI
  • HOL-1811-06-SDC: [vSphere Automation and Development] API and SDK
  • HOL-1811-07-SDC: [vSphere HTML Client SDK] Build a Plugin
  • HOL-1830-01-CAN: [PhotonOS and Container Basics] Getting Started
  • HOL-1830-02-CAN: [vSphere Integrated Containers] Getting Started
  • HOL-1831-01-CAN: [vSphere Integrated Containers Kubernetes] Advanced Topics
  • HOL-1810-01-SDC: Virtualization 101

 

 

 

 

The post Get your vSphere questions answered at VMworld Europe 2017 appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog

Thinking of Big Data or HPC? vSphere Scale-Out Can Help.

Today, VMware is excited to introduce vSphere Scale-Out, a new addition to the vSphere product line.  vSphere Scale-Out is a solution that packages all the core vSphere features required for Big Data and High Performance Computing (HPC) workloads at an attractive price point.

vSphere Scale-Out will be licensed specially for Big Data and HPC workloads and sold in packs of 8 CPUs.  Key features included in the vSphere Scale-Out edition include ESXi Hypervisor, vMotion, Storage vMotion, Host Profiles, Auto Deploy, Distributed Switch and more.

By virtualizing Big Data and HPC workloads with vSphere Scale-Out, customers can benefit from:

Increased Flexibility and Agility

The line of business wants results fast.  However, physical environments don’t facilitate the desired flexibility or agility due to the slow nature of infrastructure procurement and setup, as well as the complexity of Day-2 operations.  It could take months to obtain the required servers, install and configure them, and setup the Big Data or HPC environments. And this is just the initial lab deployment.  When it comes time to start a new experiment or increase the environment size, the entire process needs to be repeated.

Contrast the physical environment with one that is virtualized.  IT can rapidly provision infrastructure for their line of business with the centralized management and configuration capabilities available with vSphere Scale-Out.  The line of business can get infrastructure on-demand via virtual machines from their IT department.  This is especially important as the IT department is serving an increasingly diverse set of internal customers who have differing software infrastructure requirements. Virtual environments provide the line of business both the flexibility and agility they need to get results faster.

Increased Operational Efficiency

vSphere Scale-Out enables business efficiency while reducing operational expenses for Big Data and HPC workloads. vSphere Scale-Out offers centralized configuration and management capabilities to minimize setup and configuration times.  vSphere Scale-Out also simplifies Day-2 operations. Ongoing provisioning and maintenance of infrastructure can be extremely time consuming.  Manually configuring a few servers may seem bearable, but doing so for hundreds or even thousands of servers is an overwhelming burden. With vSphere Host Profiles and Auto Deploy, administrators can create a host configuration file once and then use it for setup of multiple vSphere hosts, eliminating the need for specialized scripts or manual configuration. vSphere Distributed Switch offers similar centralized administration capabilities but for virtual networking environments.  With vSphere Distributed Switch, setting up hundreds of virtual switches can be done in the same amount of time as just a few virtual switches. All of these capabilities enable administrators to dramatically simplify the ongoing support for Big Data and HPC clusters.

Another area where operational efficiencies can be achieved is with workload mobility.  There are times when maintenance must be performed on physical servers.  In a physical environment, scheduled downtime would have to occur resulting in lost productivity.  In a virtual environment, planned downtime can be eliminated.  vSphere vMotion offers live migration capabilities that enable workloads to be moved from one host to another with zero downtime.  Users don’t even realize a migration of the workload is occurring.  This results in elimination of downtime and greater operational efficiencies.

 

Reduced Complexity for Big Data and HPC Environments

Another challenge of Big Data and HPC workloads is the complexity involved with setting up the environment itself.

vSphere Scale-Out offers a less complex approach for Big Data and HPC environments.  First, it utilizes the same vSphere tools that IT admins are already familiar with so there is no steep learning curve to overcome.  Furthermore, specific tasks on physical servers, such as workload migration, becomes extremely simple through live migration capabilities with vSphere Scale-Out.  The centralized server and network management capabilities in vSphere also dramatically reduce complexity, especially when scaling out a cluster.  Finally, vSphere is recognized as an extensively deployed virtualization platform across verticals and geographies. vSphere has a broad ecosystem of OEM partners, who offer a wide choice of server and systems hardware. VMware’s ISV partners bring value-added services such as backup, security analysis, firewall, and Day-2 operations management.  VMware also collaborates with technology partners to produce joint certification and reference architectures for Big Data workloads.

Increased Data Governance and Control of Sensitive Customer Information

vSphere Scale-Out provides security isolation that prevents VMs from seeing other VM’s data in the same cluster. Each VM is restricted to access only the virtual disk files that have been designated for it and no other. The result is that users from different groups are able to run jobs on the same cluster without fear that their data will be compromised.  In addition to VM security isolation, the ESXi hypervisor gives guests low privileges by default. It is designed not to trust any privileged operations that the guest tries to perform. This means that compromised VMs, even with root access, are extremely unlikely to do damage to other VMs in the cluster.  This results in increased VM and host security for your customers and their data.

Learn More at:

The post Thinking of Big Data or HPC? vSphere Scale-Out Can Help. appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog

Get answers to your vSphere questions at VMworld US 2017

The Cloud Platform Business Unit is making our final preparations for VMworld US 2017, and we are coming to Vegas with so much to share with you. We’re especially excited to talk with you about the importance of upgrading to vSphere 6.5, and the technical possibilities that are opened up with this version of vSphere.

This post is an attempt to pull together information about all the activities we have planned for VMworld US into one location. We’ll see you soon!

Sessions at VMworld US 2017

  • The master list of our sessions, broken up by category, has its own page on the vSphere blog.
  • Here are our last-minute session suggestions for you:
    • Tuesday, 1:00 PM:
      • Session number: SER1361BU
      • Title: Security Operations for VMware vSphere with VMware vRealize Log Insight
      • Presenters: Mike Foley, Edward Haletky
      • Why attend? You need to understand configuration drift, service and user access. See how vSphere 6.5 logging helps make this possible.
    • Tuesday, 2:30 PM:
      • Session number: SER2413BU
      • Title: NVMe: What Is It? An Interface? A Protocol? A New Drive Technology? An Industry Revolution?
      • Presenters: Sudhanshu (Suds) Jain, Sudhanshu Jain, Adrian Marinescu
      • Why attend? You need to understand NVMe, and what VMware has been doing from the beginning to help you take advantage of it in your environment.
    • Tuesday, 5:30 PM
      • Session number: SER1912BU
      • Title: VMware Open-Source SDKs: From Getting Started to Web App in One Hour
      • Presenters: Alan Renouf, Steve Trefethen
      • Why attend? You want to know more about VMware software development kits (SDKs), and want to walk out of the session knowing how to use SDKs to build a web app!

Kick off VMworld with an upgrade to 6.5 technical workshop

On Sunday, August 27, we are offering two 3-hour deep dive workshops to help answer your questions about upgrading to vSphere 6.5. The first session is from 9AM – 12PM. Bring your upgrade scenario, and Emad Younis and Adam Eckerle will walk you through the recommended upgrade path that you should take.

The second session is from 1PM – 4PM. VMware Solutions Architects and System Engineers will answer your questions about upgrading to vSphere 6.5.

You must register to attend, and there is still space left! Sign up here.

Come see us in the VMworld US 2017 booth!

We’ll have experts in our booth to talk about all things vSphere. Have a question? Here are the times we’ll be in the booth:

  • Sun Aug 27: 5:00PM – 7:30PM
  • Mon Aug 28: 11:00AM – 6:00PM
  • Tue Aug 29: 11:00AM – 6:00PM
  • Wed Aug 30: 10:00AM – 5:00PM

Here are some of the things we’ll be talking about:

  • Simplified vSphere Administration
    • vCenter Server Appliance and HA
    • vSphere Lifecycle Management
    • REST-based APIs
    • HTML 5 vSphere Client
    • vSphere Upgrades
  • Comprehensive vSphere Security at Scale
    • At-Rest and In-Motion Encryption
    • Secure Chain of Trust
    • Audit Quality Loggig
  • Proactive Data Center Management
    • Proactive HA
    • DRS / Intelligent Workload Placement
    • Predictive DRS
  • New Workloads
    • vSphere Scale-Out
    • Tech Preview: Persistent Memory
    • Tech Preview: vGPU
    • Tech Preview: RDMA
  • vSphere Upgrades
    • How to Upgrade
    • VCSA Migration Tool
    • Topology Planning Tool

Help us design the VMware Cloud on AWS experience

Have you ever wanted to help VMware design how a product works? You can do that at VMworld! The VMware Cloud on AWS User Experience team is looking for design partner. Get the chance to have your voice heard on how this new product works. You’ll be required to sign an NDA. Details and sign-up information in this blog post.

Get a free evaluation of your environment in the SDDC lounge

Need personalized guidance about your VMware implantation? We’ve brought back the SDDC Lounge for VMworld US 2017. Head over to the lounge and our experts will help you analyze your environment to understand what steps you can take to make it even better. The lounge will be in the Four Seasons Hotel, Desert Willow Room. It will be open Sunday from 1 -5, and Monday and Tuesday from 11 – 5.

SDDC Lounge VMworld

Bring your hardest questions to our experts

Our experts will be in the Meet the Expert area. If you have a particularly hard question, make sure to plan to visit them.

Day Table Time Session Expert
Sun 4 1:00 – 2:00 MTE4728-SER Abhijith Prabhudev
Sun 4 2:00 – 3:00 MTE4717-SER Mark Achtemichuk
Sun 4 3:00 -4:00 MTE4719-SER Adam Eckerle
Mon 4 11:15 – 12:00 MTE4717-SER Mark Achtemichuk
Mon 4 12:15 – 1:00 MTE4720-SER Frank Denneman
Mon 4 1:15 – 2:00 MTE4729-SER Emad Younis
Mon 4 2:15 – 3:00 MTE4724-SER William Lam
Mon 4 3:15 – 4:00 MTE4716-SER Mike Foley
Mon 7 3:15 – 4:00 MTE4726-SER Vishwa Srikaanth
Mon 4 4:15 – 4:00 MTE4718-SER Eric Gray
Mon 4 5:15 – 6:00 MTE4722-SER Kyle Ruddy
Tues 4 11:15 – 12:00 MTE4716-SER Mike Foley
Tues 4 12:15 – 1:00 MTE4721-SER Kyle Ruddy
Tues 4 1:15 – 2:00 MTE4718-SER Eric Gray
Tues 4 2:15 – 3:00 MTE4723-SER Alan Renouf
Tues 4 3:15 – 4:00 MTE4719-SER Adam Eckerle
Wed 7 9:15 – 4:00 MTE4729-SER Emad Younis
Wed 4 9:15 – 10:00 MTE4719-SER Adam Eckerle
Wed 4 10:15 – 11:00 MTE4720-SER Frank Denneman
Wed 4 11:15 – 12:00 MTE4724-SER William Lam
Wed 4 12:15 – 1:00 MTE4725-SER Ravi Soundararajan
Wed 4 1:15 – 2:00 MTE4723-SER Alan Renouf
Wed 4 2:15 – 3:00 MTE4721-SER Kyle Ruddy
Wed 4 3:15 – 4:00 MTE4727-SER Dennis Lu
Wed 4 4:15 – 4:00 MTE4716-SER Mike Foley
Thurs 7 10:45 – 11:30 MTE4729-SER Emad Younis
Thurs 4 10:45 – 11:30 MTE4718-SER Eric Gray
Thurs 4 11:45 – 12:30 MTE4721-SER Kyle Ruddy
Thurs 4 12:45 – 1:30 MTE4720-SER Frank Denneman
Thurs 4 1:45 – 2:30 MTE4723-SER Alan Renouf

 

Get your hands dirty in a hands-on lab

Try out the new features of vSphere 6.5 in a hands-on lab. Here are the HOLs that are specific to vSphere:

  • HOL-1804-01-SDC: [vSphere 6.5] Performance Diagnostics and Benchmarking
  • HOL-1804-02-CHG: [vSphere 6.5] Challenge Lab
  • HOL-1811-01-SDC: [vSphere v6.5] What’s New
  • HOL-1811-02-SDC: [vSphere with Operations Management] Getting Started
  • HOL-1811-03-SDC: [vSphere with Operations Management] Advanced Topics
  • HOL-1811-04-SDC: [vSphere Security] Getting Started
  • HOL-1811-05-SDC: [vSphere Automation] PowerCLI
  • HOL-1811-06-SDC: [vSphere Automation and Development] API and SDK
  • HOL-1811-07-SDC: [vSphere HTML Client SDK] Build a Plugin
  • HOL-1830-01-CAN: [PhotonOS and Container Basics] Getting Started
  • HOL-1830-02-CAN: [vSphere Integrated Containers] Getting Started
  • HOL-1831-01-CAN: [vSphere Integrated Containers Kubernetes] Advanced Topics
  • HOL-1810-01-SDC: Virtualization 101

 

Be part of a hackathon

Hack with others to build new ways to use VMware solutions! This is available in Las Vegas and Barcelona, and you must sign up via the session builder. This blog post has all the details on signing up and preparing for the hackathon.

 

The post Get answers to your vSphere questions at VMworld US 2017 appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog

VMware plans to deprecate vmkLinux APIs and associated driver ecosystem

VMware plans to deprecate the vmkLinux APIs and associated driver ecosystem with the next numbered release (not an update release) of VMware vSphere.  The next version of vSphere will be the terminal release for which vmkLinux APIs and its associated driver ecosystem will be available.

VMware vSphere leverages a vast vSphere driver ecosystem to run various I/O stacks like networking and storage on server platforms.  This ecosystem is built out with technologies from many I/O partners. To better address the need to build software-defined infrastructure (SDI) based on vSphere, VMware introduced the vSphere kernel native API and associated native I/O driver ecosystem back in vSphere 5.5. Since then VMware has consistently worked with a broad set of OEM and I/O partners to build best of breed solutions on the new interface. For example, in vSphere 6.5 we introduced additional support for many devices and drivers, and we plan to continue that work in future releases of vSphere.

Top 5 Benefits of Native Driver Model:

  1. Reduced time spent at interrupt level (to an absolute minimum); reduces processing when accessing shared resources. Less time spent in waiting for the resources.
  2. Ability to leverage the scheduler to move as many cycles as possible into the scheduler’s realm. e.g. task completion handling is moved to a high priority kernel under scheduler’s control.
  3. The native driver model has been designed to be compatible with kernel preemption.
  4. Better support, management and debugging capabilities
    • Enables long term binary compatibility.
    • A single point-device manager manages the hierarchical device objects inside kernel for a given physical device.
    • The native driver API enables the flexibility to develop debugging tools for ESXi more naturally and effectively.
  5. Improved performance and CPU savings.

VMware’s “native” vSphere driver ecosystem has already been adapted by the majority of I/O vendors and used in a vast number of customer deployments from vSphere 6.0 onwards. VMware plans to continue to broaden its ecosystem based on the native driver model to address market needs. After the deprecation of vmkLinux, the vSphere kernel native API will be the only interface to integrate drivers with vSphere. Most customers won’t need to do anything as they adapt to the vSphere release after deprecation since most of the current and all future hardware will be compatible with the “native” vSphere driver ecosystem. For a small percentage of hardware, which are based on very old I/O technologies, it is possible that future vSphere releases may not be compatible after deprecation.

Additional Resources

The post VMware plans to deprecate vmkLinux APIs and associated driver ecosystem appeared first on VMware vSphere Blog.

Source: VMware vSphere Blog