Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0

In vSphere 6.0, the mobility options for a Virtual Machine is truly limitless. This has all been possible with a new set of vMotion capabilities introduced in vSphere 6.0 which you can learn more about them here and here. In the past, one area of concern when migrating a VM from one vCenter Server to another is the possibility that a migrated VM's MAC Address might be re-provisioned by the source vCenter Server resulting in a MAC Address conflict. In fact, this is actually a topic I have covered before in my considerations when migrating VMs between vCenter Servers article. I highly encourage you check out that article before proceeding further as it provides some additional and necessary context.

When looking to leverage the new Cross vCenter Server vMotion (xVC-vMotion) capability in vSphere 6.0, are MAC Address conflicts still a concern? To answer that question, lets take a look at an example. Below I have a diagram depicting two different vSphere 6.0 deployments. The first is comprised of three vCenter Servers who are joined to the same SSO Domain called vghetto.local and VM1 is currently being managed by VC1. The second is a single vCenter Server connected to a completely different SSO Domain called vmware.local. I will also assume we are being a good VI Admin and we have deployed each vCenter Server using a unique ID (more details here on why having different VC ID matters).

mac-address-xvc-vmotion-00
Lets say we now migrate VM1 from VC1 to VC2. In previous releases of vSphere, this potentially could lead to VC1 re-provisioning the MAC Address that VM1 was associated with because that MAC Address was no longer being managed by VC1 and from its point of view, it is now available. Though this type of a scenario is probably rare in most customer environments, in a high churn continuous integration or continuous delivery environment, this can be a real issue. So has anything been improved in vSphere 6.0? The answer is yes, of course :)

In vSphere 6.0, vCenter Server now maintains a VM MAC Address Blacklist which upon a successful xVC-vMotion will update this blacklist with the MAC Addresses associated with the migrated VM. This ensures that the source vCenter Server will not re-provisioned these MAC Addresses to newly created VMs and these MAC Addresses are basically "blacklisted" from being used again as shown in the diagram below.

mac-address-xvc-vmotion-1
If we decide to migrate VM1 from VC2 back to VC1, the blacklist is automatically updated and "blacklisted" MAC Addresses will be removed. If we decide to migrate VM1 to a completely different vCenter Server which is not part of the same SSO Domain, then the MAC Address could potentially be re-used, but it will depend on your environment if VC4 is on a completely different L2 segment, then a MAC Address conflict would not occur.

As of right now, there is no automatic way of reclaiming blacklisted MAC Addresses, it is a manual process that must be initiated through a private vSphere API. I am hoping we will be able to get this documented in an official VMware KB, so that in case this is required, you can easily follow the simple steps to execute the necessary APIs. Automatic reclamation is being looked at by Engineering and hopefully we will see this in a future patch/update in vSphere. Overall, this should should not really be a concern given that vCenter Server can uniquely generate about 65,000 unique MAC Addresses and you would have to perform quite a few xVC-vMotions before ever needing to reclaim from the blacklist.

One thing to be aware of when performing xVC-vMotion or ExVC-vMotion is that there are currently no pre-flight checks for MAC Address conflicts at the destination vCenter Server (something Engineering is looking update in a future patch/update release). Having said that, there are two additional measures you can implement in you environment to prevent MAC Address conflicts:

  1. Create vCenter Server alarm which can detect and notify you of a duplicate MAC Address in you environment (also applicable to vSphere 5.5)
  2. Pro-actively check to see if the existing MAC Addresses of your VM is currently in use prior to performing a xVC-vMotion, this is especially useful when performing ExVC-vMotion.

To help with with number 2, I have created a simple PowerCLI script called check-vm-mac-conflict.ps1 which accepts both your source and destination vCenter Server as well as the name of the VM in the source VC to be migrated. It will check the VM's MAC Addresses in the destination VC and ensure that there are no conflicts. If there is a conflict, it will output the name of the destination VM and the MAC Address that is in conflict as seen in the screenshot below.

mac-address-xvc-vmotion-2
Hopefully with these additional measures, you can easily prevent MAC Address conflicts when performing xVC-vMotions in your vSphere environment which can be a pain to troubleshoot.

Home Labs made easier with VSAN 6.0 + USB Disks

VSAN 6.0 includes a large number of new enhancements and capabilities that I am sure many of you are excited to try out in your lab. One of the challenges with running VSAN in a home lab environment (non-Nested ESXi) is trying to find a platform that is both functional and cost effective. Some of the most popular platforms that I have seen customers use for running VSAN in their home labs are the Intel NUC and the Apple Mac Mini. Putting aside the memory constraints in these platforms, the number of internal disk slots for a disk drive is usually limited to two. This would give you just enough to meet the minimal requirement for VSAN by having at least a single SSD and MD.

If you wanted to scale up and add additional drives for either capacity purposes or testing out a new configurations, you are pretty much out of luck, right? Well, not necessary. During the development of VSAN 6.0, I came across a cool little nugget from one of the VSAN Engineers where USB-based disks could be claimed by VSAN which could be quite helpful for testing in a lab environment, especially using the hardware platforms that I mentioned earlier.

For a VSAN home lab, using cheap consumer USB-based disks which you can purchase several TB's for less than a hundred dollars or so and along with USB 3.0 connectivity is a pretty cost effective way to enhance hardware platforms like the Apple Mac Mini and Intel NUCs.

Disclaimer: This is not officially supported by VMware and should not be used in Production or evaluation of VSAN, especially when it comes to performance or expected behavior as this is now how the product works. Please use supported hardware found on the VMware VSAN HCL for official testing or evaluations.

Below are the instructions on how to enable USB-based disks to be claimable by VSAN.

Step 1 - Disable the USB Arbitrator service so that USB devices can been seen by the ESXi host by running the following two commands in the ESXi Shell:

/etc/init.d/usbarbitrator stop
chkconfig usbarbitrator off

vsan-usb-disk-1
Step 2 - Enable the following ESXi Advanced Setting (/VSAN/AllowUsbDisks) to allow USB disks to be claimed by VSAN by running the following command in the ESXi Shell:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

vsan-usb-disk-2
Step 3 - Connect your USB-based disks to your ESXi host (this can actually be done prior) and you can verify that they are seen by running the following command in the ESXi Shell:

vdq -q

vsan-usb-disk-3
Step 4 - If you are bootstrapping vCenter Server onto the VSAN Datastore, then you can create a VSAN Cluster by running "esxcli vsan cluster new" and then contribute the storage by adding the SSD device and the respective USB-based disks using the information from the previous step in the ESXi Shell:

esxcli vsan storage add -s t10.ATA_____Corsair_Force_GT________________________12136500000013420576 -d mpx.vmhba32:C0:T0:L0 -d mpx.vmhba33:C0:T0:L0 -d mpx.vmhba34:C0:T0:L0 -d mpx.vmhba40:C0:T0:L0

vsan-usb-disk-4
If we take a look a the VSAN configurations in the vSphere Web Client, we can see that we now have 4 USB-based disks contributing storage to the VSAN Disk Group. In this particular configuration, I was using my Mac Mini which has 4 x USB 3.0 devices that are connected and providing the "MD" disks and one of the internal drives that has an SSD. Ideally, you would probably want to boot ESXi from a USB device and then claim one of the internal drives along with 3 other USB devices for the most optimal configuration.

vsan-usb-disk-5
As a bonus, there is one other nugget that I discovered while testing out the USB-based disks for VSAN 6.0 which is another hidden option to support iSCSI based disks with VSAN. You will need to enable the option called /VSAN/AllowISCSIDisks using the same method as enabling USB-based disk option. This is not something I have personally tested, so YMMV but I suspect it will allow VSAN to claim an iSCSI device that has been connected to an ESXi host and allow it to contribute to a VSAN Disk Group as another way of providing additional capacity to VSAN with platforms that have restricted number of disk slots. Remember, neither of these solutions should be used beyond home labs and they are not officially supported by VMware, so do not bother trying to do anything fancy or running performance tests, you are just going to let your self down and not see the full potential of VSAN :)

Ultimate automation guide to deploying VCSA 6.0 Part 3: Replicated Platform Service Controller Node

In this article, I will share alternative methods of deploying replicated Platform Services Controller Node (PSCs) using the VCSA 6.0 appliance. Take a look at the various deployment methods below and their respective instructions for more details.
platform-service-controllers
Disclaimer: Though these alternative deployment options work, they are however not officially supported by VMware. Please use at your own risk.

Deploying to an existing vCenter Server using ovftool (shell script)

I have created a shell script called deploy_vcsa6_replicated_psc_to_vc.sh which requires using ovftool 4.1 (included in the VCSA ISO) to specify the appropriate OVF "guestinfo" properties for a replicated PSC deployment. You will need to edit the script and modify several variables based on your environment.

Here is an example of executing the script:

vcsa-6.0-replicated-platform-service-controller-node-deployment

Deploying to an ESXi host using ovftool (shell script)

I have created a shell script called deploy_vcsa6_replicated_psc_to_esxi.sh which requires using ovftool 4.0 or greater to specify the appropriate OVF "guestinfo" properties for a replicated PSC deployment. You will need to edit the script and modify several variables based on your environment. The behavior of this script is similar to the one above, except you are deploying directly to an ESXi host.

Deploying to an existing vCenter Server using ovftool (PowerCLI)

I have created a PowerCLI script called Deployment-PSC-Replication.ps1 which uses ovftool and specifies the appropriate OVF "guestinfo" properties for a replicated PSC deployment. You will need to edit the script and modify several variables based on your environment.

Deploying to VMware Fusion & Workstation

To properly deploy the new VCSA 6.0, the proper OVF properties MUST be set prior to the booting of the VM. Since VMware Fusion and Workstation do not support OVF properties, you will need to manually deploy the VCSA, but not power it on. Once the deployment has finished, you will need to add the following entries to the VCSA's VMX file and replace it with your environment settings. Once you have saved your changes, you can then power on the VM and the configurations will then be read into the VM for initial setup.

guestinfo.cis.deployment.node.type = "infrastructure"
guestinfo.cis.vmdir.domain-name = "vghetto.local"
guestinfo.cis.vmdir.site-name = "vghetto"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.vmdir.first-instance = "false"
guestinfo.cis.vmdir.replication-partner-hostname = "192.168.1.50"
guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.addr = "192.168.1.63"
guestinfo.cis.appliance.net.pnid = "192.168.1.63"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.dns.servers = "192.1681.1"
guestinfo.cis.appliance.net.gateway = "192.168.1.1"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.ssh.enabled = "true"

For more information, you can take a look at this article here.

Deploying using new supported scripted install (bonus)

As mentioned earlier, there is also a new scripted installer included inside of the VMware-VCSA ISO under /vcsa-cli-installer which supports Windows, Mac OS X and Linux, but must be connected directly to an ESXi host. There are several templates that are also included within the /vcsa-cli-installer/templates. I thought as a bonus I would also share the template I have been using to deploy replicated PSC instances using a static IP Address which some of you may find useful.

The use the scripted installer, you just need to change into the appropriate OS platform directory (win32,mac or lin64) and there should be a binary called vcsa-deploy. To use this template, you just need to save the JSON to a file and then specify that as the first argument to vcsa-deploy utility.

Here is an example of deploying a PSC using the vcsa-deploy scripted installer.

vcsa-6.0-replicated-platform-service-controller-scripted-install

Long awaited Fling, Windows vCenter Server to VCSA Converter Appliance is finally here!

vcs-migration-appliance-smallBack in VMworld 2013, the Office of CTO held its annual Fling Contest where customers can submit their ideas for cool new Flings that they would like to see. If selected, not only would the individual get a free pass to VMworld but VMware Engineers would also build and release the Fling, how cool is that!? There were over 200+ submissions that year and I was very fortunate to have been on the panel to help select the winner. The winning Fling for that year was the Windows vCenter Server (VCS) to VCSA Converter Appliance by Stephen Athanas.

The idea of a VCS to VCSA Converter really resonated with me as well as with many of our customers. In fact, everyone that I had spoken with who has used the VCSA just love the simplicity, ease of deployment and management it provides compared to its Windows counterpart. However, one of the biggest adoption barrier that I have seen from talking to customers is that is no simple way of migrating from a Windows based vCenter Server to the VCSA. You literally have to start fresh and this is pretty a show stopper for the majority of our customers and I do not disagree with them.

Customers want a migration path to be able to preserve all their vCenter Server configurations such as Folder structures, Permissions, Alarms, Tags, VM Storage Policies, etc. This is the idea behind the VCS to VCSA Converter Appliance which helps migrate a Windows vCenter Server running on an external Microsoft SQL Server Database to an embedded VCSA running a vPostgres Database. Today, I am very proud to announce the release of the VCS to VCSA Converter Appliance Fling.

The Converter Appliance migrates the vCenter database, Roles, Permissions, Privileges, Certificates, Alarms and Inventory Service which contains Tags and VM Storage Policies. At the end of the migration, you will end up with a fully functional VCSA with the original hostname/IP Address fully intact and ready to use. As you can imagine, this was no easy task and we had some of the smartest VMware Engineers working on this project. Todd Valentine from the OCTO managed the overall program with Ravi Soundararajan as the Chief Architect working closely with Mike Stunes, Jignesh Shah, Raju Angani. Being a huge advocate and supporter of the VCSA, I also had the unique opportunity to be involved in this project and working closely with some amazing engineers to help design, test and validate the migration appliance.

We hope you give the VCS to VCSA Converter Appliance a try in your lab (Please carefully read through the documentation along with the requirements and caveats before getting started). Let us know what you think by either leaving a comment here on my blog or on the Flings webpage. This is our first release and we already have some ideas of features and capabilities we would love to add to future releases but if there are things that you feel that are currently missing or enhancements you wold like to see, please let us know!

New VOBs for creating vCenter Server alarms in vSphere 6.0

Here are some new VOBs in vSphere 6.0 that I recently came across which can be useful on getting notified on specific events such failed login attempts in ESXi or detecting a device has gone offline in VSAN as some examples. These VOBs can be used to create vCenter Server alarms to take various actions such as a simple UI notification in the vSphere Web/C# Client to sending an email or SNMP trap regarding the event. For more information on how create vCenter Server alarms using VOBs, please take a look at these two articles here and here which also includes a comprehensive list of past vSphere VOBs in vSphere 5.5 which are still applicable in vSphere 6.0.

General vSphere 6.0 VOBs

VOB ID VOB Description
esx.audit.account.locked Remote access for an ESXi local user account has been locked temporarilly due to multiple failed login attempts.
esx.audit.account.loginfailures Multiple remote login failures detected for an ESXi local user account.
esx.audit.esxcli.host.restart Rebooting host through esxcli
esx.audit.lockdownmode.exceptions.changed List of lockdown exception users has been changed.
esx.problem.coredump.copyspace The free space available in default coredump copy location is insufficient to copy new coredumps.
esx.problem.coredump.extraction.failed.nospace The given partition has insufficient amount of free space to extract the coredump.
esx.problem.dhclient.lease.offered.error No expiry time on offered DHCP lease.
esx.problem.pageretire.selectedbutnotretired.high Number of host physical memory pages that have been selected for retirement but could not yet be retired is high.
esx.problem.swap.systemSwap.isPDL.cannot.remove System swap at path {1} was affected by the PDL of its datastore and was removed. System swap has been reconfigured.
esx.problem.swap.systemSwap.isPDL.removed.reconfig.failure System swap at path {1} was affected by the PDL of its datastore. It was removed but the subsequent reconfiguration failed.
esx.problem.vmfs.ats.incompatibility.detected Multi-extent ATS-only VMFS Volume unable to use ATS
esx.problem.vmfs.lockmode.inconsistency.detected Inconsistent VMFS lockmode detected.
esx.problem.vmfs.spanned.lockmode.inconsistency.detected Inconsistent VMFS lockmode detected on spanned volume.
esx.problem.vmfs.spanstate.incompatibility.detected Incompatible VMFS span state detected.
esx.vFlash.VFlashResourceCapacityExtendedEvent vFlash resource capacity is extended
vprob.vmfs.heartbeat.corruptondisk VMFS Heartbeat Corruption Detected

VSAN 6.0 VOBs

VOB ID VOB Description
esx.audit.vsan.net.vnic.added Virtual SAN virtual NIC has been added.
esx.audit.vsan.net.vnic.deleted Virtual SAN network configuration has been removed.
esx.problem.vob.vsan.dom.lsefixed Virtual SAN detected and fixed a medium error on disk.
esx.problem.vob.vsan.dom.nospaceduringresync Resync encountered no space error
esx.problem.vob.vsan.lsom.disklimit2 Failed to add disk to disk group.
esx.problem.vsan.dom.init.failed.status Virtual SAN Distributed Object Manager failed to initialize
vprob.vob.vsan.pdl.offline Virtual SAN device has gone offline.