AWS Public Sector Summit 2019

AWSsummit2019_keynote

I attended the AWS Public Sector Summit in Washington, DC last week. This was actually the first conference I have been to since the 2017 Summit. The event has grown quite a bit. Mentioned at the keynote that there was 18,000 people registered. Would be interesting to see how many people actually attended. The event has grown a lot with only about 7,500 attendees on the first day of the event in 2017.

AWSsummit2017c_SilentFail

The silent disco for presentations has to be one of the worst ideas ever for a tech conference. Though, I think it’s a neat idea for a dancing party. The ballroom for the silent disco could be partitioned into three rooms and there were plenty of other event space to be used. I am not sure why Amazon chose to do a silent disco. The audience might as well have been at home since no one could even ask questions during the presentations. Some speakers were naturally loud so I could hear them when I was sitting at the adjacent stage’s audience. Then the sound was often crackling and the staff running the silent disco could not fix it. I still thought the content of the presentations were great.

AWSsummit2017_DeepRacer

There was a lot of great companies on the vendor floor. AWS had a DeepRacer track and a huge prize for the person with the best time; an all paid expense trip to re:Invent. The AWS certification lounge was a nice touch. They made it easy to verify a certification and get back in. The lounge had some extra snacks, swag, an open bar, and entertainment. I was very lucky and won an Amazon Echo Show from Dynatrace.

I enjoyed the event overall. Though, I hope the silent disco style of presentations does not catch on to other conferences. Next year may be even bigger considering what Andy Jassy, AWS CEO, said during his fireside chat on the second day. He said he thinks the public sector adaption of the cloud is still in the early days.

Integration between vRealize products and vCenter Server

There is very useful integration between vRealize Operations, Log Insight, and vCenter Server. The products can be tied to each other to make them more seamless and easier to navigate. A few roles are required to be created to restrict permissions. I have the broad steps and links to the VMware articles below that detail the specific permissions and documentation. Go through the steps and then you will be able to launch in context.

As defined by VMware; launch in context is a feature in vROps that lets you launch an external application via URL in a specific context. The context is defined by the active UI element and object selection. Launch in context lets the Log Insight adapter add menu items to a number of different views within the Custom user interface and the vSphere user interface of Operations Manager.

vROps_LI_Intergration

vSAN Deployment Issues with Cluster Quickstart

I ran into some gotchas when deploying a vSAN 6.7 U1 cluster. The cluster quickstart should save time when deploying a vSAN cluster. However, there are a couple steps to take to avoid issues.

Do not use the vSphere Flash client for any step on the deployment. Only use the vSphere HTML5 client. There are odd issues that can occur. For example, I created the cluster in the Flash client. I then wanted to run quickstart in the HTML5 client. However, the options were grayed out under cluster basics so I could not select anything or go to add hosts. I deleted the cluster and created it in the HTML5 client. Then quickstart worked fine. I later had another new deployment. I tried out the same scenario and had the same problem.

quickstart1

Quickstart has the option of creating a vDS. The vDS will be created at version 6.5. There is no option to select a specific version of the vDS when deployed through quickstart. This is fine depending on the other versions of vDSs in your environment and if maintaining vMotion compatibility is a requirement.  For example, if another cluster has a vDS on version 6.0, then VMs in that cluster cannot be live migrated to the vSAN cluster on vDS version 6.5 since different vDS versions. Only option is to power off the VM to allow it to be migrated. To get around this, create a vDS on version 6.0 before starting quickstart. Then select the option to ‘USE EXISTING’ on the distributed switches section of quickstart.

quickstart2

Quickstart is definitely very useful and can save a lot of time if not hitting these gotchas. The ability to auto-fill sequential IP addresses for management and vMotion, and ESXi root login credentials are convenient. Hopefully, fault tolerance will eventually be added to quickstart. Also, having a guided workflow makes the vSAN deployment relativity easy.

VMware vSAN 2017 Specialist Badge

vmware-vsan-2017-specialist

I recently earned the VMware vSAN 2017 Specialist Badge. Despite the name, I did in fact pass the exam in 2019 with a score of 411. This is the latest version of the exam. I do not like how VMware is naming the exams after the year the exam was released. Makes sense for Microsoft to put a year in the exam title because the version of their software obviously has the year in it. I hope VMware goes back to naming the exams after the version of the product.

The latest version of vSAN is 6.7 U2, but the exam objectives are based on vSAN 6.6. The exam was fairly easy so I guess that is why it is for a badge and not a certification. The exam didn’t really have any surprises. It closely followed the exam objectives. I recommend to review the material in the two links below and know it very well. I had plenty of time to finish the exam.

https://xiaoxiaoke.wordpress.com/2016/02/20/how-to-understand-and-calculate-space-requirements-for-raid-1-with-vsan/

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-3863B640-3449-46A2-84E0-AC07E5A604FD.html

As you can see from the image below, the badge path is for VCP6 holders. The drop down also has expired VCP and no VCP. My VCP is active, but on 5.5. I have kept it active with taking VCAP exams during the past few years. Then it would have become active anyway since VMware changed their rules for certification expiration.

vSANSpecialistRequirements2

Anyway, there are actually many more certifications that meet the requirements for this badge. The screen shot below, from VMware’s certification manager, shows a long list that has VCAP 6, VCDX 6, and newer VCP exams. I earned the badge since I previously passed the VCAP6-DCV Design exam. I am not sure why it says vRealize Operations 2017 for 1.2. I am guessing it’s a mistake and should list the vSAN exam.

vSANSpecialistRequirements

 

 

Migrate resources to a new vCenter Server – Unregister old vCenter Servers (Part 4)

Now that all resources have been migrated, verify that nothing was forgotten at the source vCenter Server. Refer back to part 1. Make sure all permissions have been set on the destination resources in case you need to go back to the source to double check. Would not be fun to roll back once the single command to unregister a vCenter Server is ran.

KB2106736 has the steps for the appliance and Windows versions to unregister a vCenter Server from a PSC. In the addition to the KB article, I have two suggestions. Take a snapshot of all PSCs before running the command just to be safe.  I did run into a small issue at first, but nothing negative happened because of it. The vCenter name in the cmsso-util unregister command is case sensitive. “Could not find a host id which maps to NAME INPUTTED in Component Manager, Failed!!!” was the error message I received. If the vCenter Server is not found when running the command, I suggest you instead use the IP address of the vCenter Server.

CaseError1

The unregister command went well for me after I entered the vCenter Server in the correct case. It took a few minutes to run before I received the success output.

CaseError2

That completed the major steps in my migrations. I spent time afterwards to put datastores back in datastores clusters, import host profiles, etc. Documentation is important to assist in making your clusters look how they did before.

Migrate Resources to a New vCenter Server (Part 1)
Migrate resources to a new vCenter Server – Methods for Migrations (Part 2)
Migrate resources to a new vCenter Server – Cross vCenter vMotion Utility (Part 3)
Migrate resources to a new vCenter Server – Unregister old vCenter Servers (Part 4)

 

Migrate resources to a new vCenter Server – Cross vCenter vMotion Utility (Part 3)

I used a different method of migration for a cluster that was migrating to a new vCenter Server on a new SSO domain. The destination vCenter Server was using the vDS so I had the same limitation as the previous migration. Though, I had a different idea for this one. I had enough resources in one of the clusters to first bring over half of hosts to the destination vCenter Server. Having this configuration made the process of live migrating my VMs easy by using the Cross vCenter Workload Migration Utility.

vMotion is not bound by a SSO domain and vMotion does not even know the concept of an SSO domain. I heard this discussed on the Virtually Speaking Podcast with William Lam describing his work on the Cross vCenter Workload Migration Utility. vMotion appears to only be within the same SSO domain because of the limitation in the GUI. However, there are APIs to migrate a VM to a different SSO domain. The utility is a technically a fling, but I see no problem with using it in a production environment.  After all, the APIs are there and the utility is just giving an easy to use interface.

Here’s the process I went though for this migration.

  1. Export the vDS from the source vCenter Server
  2. Import the vDS on the destination vCenter Server
  3. Place host in maintenance mode
  4. Document and then remove VMkernel ports
    1. Of course, migrate the management VMkernel to a standard port if it is on the vDS.
    2. VMkernel ports need to be removed before a host can be removed from a vDS.
  5. Remove host from vDS
  6. Disconnect host and then remove host from source vCenter Server
  7. Add host to vCenter Server
  8. Add host to vDS
  9. Create and/or migrate  VMkernel ports that were previously deleted
  10. Exit maintenance mode
  11. Repeat steps 3-10 for additional hosts
  12. Use the Cross vCenter Workload Migration Utility to vMotion VMs

Migrate Resources to a New vCenter Server (Part 1)
Migrate resources to a new vCenter Server – Methods for Migrations (Part 2)
Migrate resources to a new vCenter Server – Cross vCenter vMotion Utility (Part 3)
Migrate resources to a new vCenter Server – Unregister old vCenter Servers (Part 4)

Migrate resources to a new vCenter Server – Methods for Migrations (Part 2)

My first walk through is for a cluster migrating to a different vCenter Server. This is the traditional vDS to standard switch to vDS. The reason for this way is to maintain up time for  my VMs and supportability. Moving a host to a new vCenter Server without first going to a standard switch is not supported. I will go over each step. In my case case, management and vMotion VMkernel ports are already on dedicated standard switches. Though, there is also a method to migrate the VMkernel ports with no downtime that is very similar. Only VM network traffic is on my vDS.

Each host needs to already have at least two physical NICs to avoid downtime for VMs and VM traffic. If you keep a continuous ping on a few VMs during this process, you will only see one ping drop during each major step. Make sure you verify the root password before removing hosts from vCenter.

Source vCenter Server

  1. Export the vDS configuration
    1. Go to the vDS -> Right click the vDS
    2. Export Configuration
    3. Select the Export the distributed switch configuration and all port groups option
  2. Create a Standard Switch and the virtual machine port groups
    1. No physical uplinks on every host at this moment
    2. A new port group that matches every port group that’s on the vDS
  3. Remove one of the physical NICs from all hosts
    1. Go to the vDS -> Manage Hosts
    2. Select all of the hosts
    3. Remove one of the two physical NICs
    4. Next -> Next -> Finish
  4. Add the physical NIC that was removed to the new standard switch on each host
  5. Migrate VMs in bulk in each port group
    1. Go to the vDS -> Migrate Virtual Machine Networking
    2. Select the source vDS port group
    3. Select the destination standard switch port group
    4. Select all VMs
    5. Finish
    6. Repeat these steps for each port group
  6. Remove the last physical NIC on the vDS
    1. Ensure no VM is connected to the vDS
    2. Go to the vDS -> Manage Hosts
    3. Select all of the hosts
    4. Remove the last physical NICs
    5. Next -> Next -> Finish
  7. Remove the hosts from the vDS
    1. Go to the vDS -> Click the host tab
    2. Right click each host and click remove
  8. Remove the hosts from the vCenter Server
    1. Right click a host -> Disconnect
    2. Right click a host -> Remove
    3. Repeat for each host

Destination vCenter Server

  1. Create a new cluster
  2. Add hosts to the new cluster
    1. Right click on the cluster
    2. Add host -> next through wizard
    3. Repeat for each host
  3. Import the vDS configuration at the destination vCenter Server
    1. Do not preserve the original vDS and port group identifiers
    2. Preserving the vDS and port group identifiers is used when restoring the vDS within the same vCenter Server
  4. Remove one physical NIC from the standard switch on each host
  5. Add the hosts to the vDS
    1. Go to the vDS -> Manage Hosts
    2. Select all of the hosts
    3. Add the physical NIC that was previously disconnected
    4. Next -> Next -> Finish
  6. Migrate VMs back to the vDS
    1. Go to the vDS -> Migrate Virtual Machine Networking
    2. Select the destination standard switch port group
    3. Select the source vDS port group
    4. Select all VMs
    5. Finish
    6. Repeat these steps for each port group
  7. Ensure no VMs are on the standard switches
  8. Remove one physical NIC from the standard switch on each host
  9. Add the last physical NICs to the vDS
    1. Go to the vDS -> Manage Hosts
    2. Select all of the hosts
    3. Add the physical NIC that was previously disconnected
    4. Next -> Next -> Finish
  10. Delete the unused standard switches

Now all VMs are running in the new vCenter Server on the vDS with no downtime. I will go over another method in my next article that I used for a different cluster.

Migrate Resources to a New vCenter Server (Part 1)
Migrate resources to a new vCenter Server – Methods for Migrations (Part 2)
Migrate resources to a new vCenter Server – Cross vCenter vMotion Utility (Part 3)
Migrate resources to a new vCenter Server – Unregister old vCenter Servers (Part 4)

Migrate Resources to a New vCenter Server (Part 1)

I recently had to move all resources under two vCenter Servers to two different vCenter Servers.  Then retire the source vCenter Servers. Both source vCenter Servers were in the same SSO domain. Fortunately, the source did not have many hosts and VMs and I wanted to bring over as much as I could.

I wanted to do my best not to leave anything behind at the destination vCenter Server. Most are obvious in my list below, but some may be easily forgotten if not used often. Below is a list of what I moved over and other settings to note in case moving to a completely new vCenter Server. A few have export/import wizards in vCenter and can of course be scripted for several others.

  • vDS – export/import
  • Host profiles – export/import
  • Customization specification – export/import
  • Custom attributes – output in RVTools
  • Folders – output in RVTools
  • Permissions
  • Roles
  • vCenter Settings – SMTP, database retention policy, etc
  • Alarms – custom/edited alarms
  • vCenter Server License
  • Cluster settings – HA, DRS, and EVC
  • Datastore clusters
  • Tags
  • Content libraries
  • Scheduled tasks

There are some third party apps to keep in mind. Make sure to reconfigure backups to point to the new vCenter Server. Third party plug-ins will need to be registered to the new vCenter Server.

Here are somethings not to worry about since they pertain to the hosts and remain with or without a vCenter Server.

  • Standard switches
  • Access to fiber channel storage
  • VM settings and notes

Events and tasks for a VM will persist when the VM is in the new vCenter Server. However, performance data for VMs is lost. Also, performance data, events, and tasks for hosts will be lost when a host is added to a new vCenter Server.

The next articles will focus on two different ways I migrated the hosts to the new vCenter Servers.

Migrate Resources to a New vCenter Server (Part 1)
Migrate resources to a new vCenter Server – Methods for Migrations (Part 2)
Migrate resources to a new vCenter Server – Cross vCenter vMotion Utility (Part 3)
Migrate resources to a new vCenter Server – Unregister old vCenter Servers (Part 4)