Tag Archives: VCSA

The All New vSphere 6.5

vmworldHighlights

  1. A new version of VMware vSphere, 6.5, will be released shortly
  2. Migration/Upgrade tools from previous versions (including Windows vCenter) to new VCSA.
  3. VCSA Native High Availability
  4. VCSA Integrated VMware Update Manager
  5. Native vCenter Backup and Restore
  6. Improved Appliance Management
  7. vSphere Clients
  8. Encryption

New vSphere coming soon

VMware has bucked the trend in versioning adopted by other major software companies and decided not to call it’s new vSphere version “10” and opted for the more traditional “vSphere 6.5” to succeed version 6.0 which was originally released back in March 2015. Announced at VMworld Europe 2016 with GA to follow, vSphere 6.5 is a continuation of the product which forms the core of the Software Defined Datacentre chunk of VMware’s “Any Cloud” Cross-Cloud Architecture portfolio. A lot of work has been put into making the experience of installing and operating a vSphere virtualised environment easier; Ignoring any improvements under the hood, and just looking at what’s on the surface there’s a whole bunch of features designed to make life run smoother for the IT Professional, some of which are highlighted in this post.

The new vCenter Server Appliance is a core part to this simplicity, and VMware have answered the requirements of anyone currently sticking to the Windows-based vCenter. If you can get more features and more reliability for less cost and less effort then it’s definitely the way forwards in my opinion. Some of the features discussed here- notably Native HA and Backup/Restore- will only be available in the appliance version of vCenter.

VCSA Upgrade and Migration

 

image Again out to both simplify the life of IT Professionals and encourage vCenter Appliance adoption, VMware has put a lot of effort into creating straightforward, and comprehensive, upgrade and migration tools. As more and more operations and data are handled by vCenter it becomes more and more important that the system can be smoothly navigated from version to version with minimal human effort.

Migrations are possible from Windows vCenters running version 5.5 or 6.0, and both the embedded and external database topologies are supported. Additionally, the new vCenter will assume the identity of the old Windows vCenter so any external interfaces, scripts, and automation should continue to work post-migration.

VCSA Native High Availability

VCSA 6.5 offers a built-in high availability deployment taking away the need for any 3rd party clustering or database solutions. The appliance deploys as an active/passive pair (plus witness) which automatically sets up replication of the integrated database and required vCenter files. The basic setup option also places these nodes intelligently using DRS and SDRS technology and automatically creates the necessary affinity rules and private IP comms, keeping everything simple. For infrastructures with unique and challenging topologies, there’s still an advanced workflow that can be used.

image

Integrated VMware Update Manager

Prior to 6.5 using VUM to manage the patching of a vSphere infrastructure based on the vCenter Appliance has been, how can we put it?, “annoying”. After deploying the slick appliance it was then necessary to spin up (and license) a separate Windows VM just to handle the update system. This requirement has been removed in the new version- VUM is now integrated into the VCSA, enabled by default, and shares the same database instance. The new VUM integration also leverages the VCSA High Availability and Backup functionality.

Native vCenter Backup and Restore

Also new to the vCenter Server Appliance is integrated backup and restore functionality. A great step forward in the simplification of deploying a system this provides a built in solution to backup vCenter to an external location (SCP, SFTP, HTTPS locations for example) and then be able to recover by deploying a clean OVA and choosing the Restore option. image

 

Improved Appliance Management and Monitoring

The vCenter Server Appliance Management Interface- VAMI – has also had a makeover, with many features being added. The 6.0 version had an interface limited to changing IP and NTP settings, rebooting the appliance, and little else. 6.5 adds in built in monitoring of Network, CPU, Memory and the vPostgres database. There is also the option to configure Syslog for deeper external monitoring of the vCenter infrastructure- this allows fully verbose logs to be kept for auditing and troubleshooting processes.

image

vCenter Server Appliance 6.0 Management Interface

image

vCenter Server Appliance 6.5 Management Interface

vSphere Client(s)

Work continues to focus on delivering a fully functioned HTML5 client, but in the interim vCenter 6.5 will come shipped with a new (limited) HTML5 based “vSphere Client”- evolved from the current fling – as well as an improved flash based “vSphere Web Client”. Expect the “vSphere Client” to see continuous improvement and feature addition through the lifetime of the platform –driven through the Fling programme.

Encryption

As with the other topics here encryption in the new vSphere could easily be a post in itself (or a whole series), but to summarise the new features in this area, vSphere is now offering built-in VM encryption. The encryption happens between the VM and the storage so is invisible to the guest.

Local keys are generated within vSphere, and encrypted using keys held in an external (third-party) KMS- this would usually be managed by the IT Security team. Back in vCenter encryption is implemented through Storage Policies, so a VM can be encrypted simply by assigning the correct policy to it. Through the GUI (or API/PowerCLI) it’s possible to set  encryption covering  the Disks, the VMX/Swap files, or the whole lot on a per-VM basis. Through the API/PowerCLI it’s also possible to arrange encryption on a per-VHD level, potentially encrypting different disks on a VM with different keys.

VSAN encryption is on the way- there’s currently an ongoing beta – but will not be available in the 6.5 release. Based on the recent cadence I’d expect to see something in Spring 2017, but that’s just my speculation.

Summary

In summary, there’s lots to look for in the new vSphere release and in particular the vCenter Server Applicance. This week’s VMworld should reveal a lot more in depth into these advances.

Setting EVC Level on a Cluster with a VCSA and no shared storage

Problem

A second host has been added to a one-node vSphere cluster which has no shared storage and EVC cannot be enabled. Details as follows:

  • A vSphere environment consists of an existing cluster containing a single host running ESXi 6. On this host is (amongst other things) the vCenter Server Appliance VM.
  • A second ESXi6 host is added and joined it to the vCenter. This host has older hardware with an older EVC level (rather than the usual situation where the newer box has newer hardware).
  • EVC cannot be enabled on the cluster because the old host does not have the capabilities of the new host. The old host has VMs running which may be using the enhanced capabilities of the higher EVC level, one of these is the vCSA.

    “The host cannot be admitted to the cluster’s current Enhanced vMotion Compatibility mode. Powered-on or suspended virtual machines on the host may be using CPU features hidden by that mode.”

    Therefore the EVC level on the existing cluster cannot be lowered by powering off all the VMs because it cannot be changed without using vCenter.

  • The vCSA cannot be vMotioned to the old host because this requires EVC to be enabled.

    “The virtual machine requires hardware features that are unsupported or disabled on the target host”

  • There is no Shared Storage. VMs are stored on local datastores. The Knowledgebase article “How to enable EVC in vCenter Server (1013111)” has a solution but this doesn’t (as far as I can tell) work without shared storage. Without storage visible from both hosts the VM cannot be disabled in one host and brought back up in a second which is in a new cluster.

Possible Solutions

The problem boils down to needing to cold migrate a VM between ESXi hosts without using shared storage or vCenter. The following solutions came to mind.

  1. Create some shared storage (possibly using an NFS share on a laptop temporarily) and follow the procedure shown in KB1013111
  2. Power down the vCSA, use the host web client to move the files from the datastore to a laptop, then back up to the less-able host. Power it on and set EVC on the cluster.
  3. Dump the vCSA and setup a replacement instance on the less-able host. Reconfigure everything. The “Start Again” option.
  4. Use SCP to do a host-host local datastore transfer of the powered down and unregistered vCSA Virtual Machine files

My Chosen Solution

This is what I tried and tested and it worked in my environment, along with step-by-step instructions if anyone else finds themselves in this predicament (usual disclaimer applies).

Option 4:  Use SCP to do a host-host local datastore transfer of the powered down and unregistered vCSA Virtual Machine files.

Rough steps – “First Host” is the existing box with newer hardware, “Second Host” is the box with older hardware being added:

  1. Using vCSA setup a new cluster containing just the second host (the one with older hardware) and turn on EVC appropriately.
  2. Enable Secure Shell access on both hosts
  3. Shutdown all VMs including the vCSA on the first host
  4. Remove vCSA from inventory (Unregister) using web client on first host
  5. SSH into second host
  6. Enable SCP through the firewall with
    esxcli network firewall ruleset set -e true -r sshClient
    -thanks http://jim-zimmerman.com/?p=723 for that snippet
  7. Use SCP to copy VM files from local datastore on first host to local datastore on second host.
    For example- in SSH session on second host, something like this:
    mkdir /vmfs/volumes/datastore1/LABVC1
    scp ‘[email protected]:/vmfs/volumes/Datastore2/LABVC1/*.*’ /vmfs/volumes/datastore1/LABVC1/
  8. Connect to web client on second host and register the copy of the VMX file to inventory
  9. Turn on the vCSA VM. When prompted say “I moved it”
  10. Wait for vCSA to spin up then move the first host into the cluster with the second host.
  11. Tidy up: -Remember to go back and delete the old copy of the VCSA from the datastore on the first host and disable SSH on both hosts if it’s not required. The vCSA can be Storage-vMotioned to rethin disks if they inflated during the SCP operation.

“Error Fetching Datastores” when installing VCSA

Symptoms
When installing VCSA onto an existing vCenter environment (as a VM, not as an in-place upgrade of that environment), on Step-9 “Select Datastore” the installer shows the message “Error Fetching Datastores” and no datastores are listed so installation cannot continue.

Error Fetching Datastores

Error Fetching Datastores

Workaround
Go back through the installer and select an ESXi host rather than the vCenter server in Step 2 “Connect to target server”. Remember to use the host credentials which may differ from the vCenter credentials. The Datastores are then discovered correctly and installation can continue.