WilliamLam.com

Hope to see you at the Nordic VMUG UserCon in Dec!

by // Leave a Comment

In case you missed it, a couple of weeks back, Liselotte Foverskov one of the leaders for the Nordic VMUG had announced some of the speakers for the upcoming Nordic VMUG UserCon taking place on Dec 1st at the Scandic Hotel in Copenhagen.

I was very fortunate to have been invited out to speak at the event. As you can see from the tweet above, I will also be joined by several of my colleagues from VMware like Paul Strong, Duncan Epping, Cormac Hogan, Paudie O'Riordan and Joerg Lew who will be covering a variety of topics, so there should be something for everyone. This will be my first time visiting Denmark and I am looking forward to meeting everyone and I hope that you can make it out. I also hear Liselotte has an amazing keynote speaker lined up that you will not want to miss! For more details about the event, be sure to visit Nordic VMUG site here.

Below is the topic that I will be presenting on but feel free to find me at the event if you are interested in talking about other topics that you may have on your mind.

Session Title: 

Harnessing the power of the vSphere API for the everyday Admin 

Session Abstract: 

In this session, you will get a brief introduction to the vSphere API and learn how to use and navigate it without needing to become a developer. Building on this foundation, we will then explore some of the different methods and tools that are available to a variety of audiences (vSphere Administrators, Developers, etc) when Automating against the vSphere API. Finally, we will take a look at some practical examples that demonstrates the vSphere API in action which you can then take back with you when you leave the session. 

New method of enabling Multiwriter VMDK flag in vSphere 6.0 Update 1 (UI + API)

by // 22 Comments

Prior to vSphere 6.0, in order for multiple Virtual Machines to share a VMFS-backed VMDK, the Multiwriter VMDK flag must be enabled, which is accomplished by adding a specific VM Advanced Setting as shown in this VMware KB 1034165. For customers who were accustomed to this old method, you may have found that this option no longer works. This was true regardless if you had used the vSphere Web/C# Client or the vSphere API to apply the configuration.

To provide for a better user experience, this behavior was changed in vSphere 6.0 and a new API was introduced for enabling and disabling the Multiwriter VMDK flag. In vSphere 6.0, there is now a new sharing attribute on the Virtual Disk backing property which accepts one of two values: sharingMultiWriter or sharingNone for specifying the Multiwriter flag. In my opinion, this is a positive change as we too often rely on the VM Advanced Setting as a generic "catch all" for enabling or configuring various settings versus adding proper APIs to a VM.

Although there is now a proper API which will can help enable new Automation use cases, one thing that was still lacking was an easy way to enable the Multiwriter VMDK flag using the UI. In vSphere 6.0 Update 1, we have now introduced a new UI dropdown option called "sharing" in the vSphere Web Client for configuring the Multiwriter VMDK flag which can be found in the Virtual Disk section when editing a VM as shown in the screenshot below.

Screen Shot 2015-10-16 at 10.19.05 AM
Note: The new Sharing property is only available in the vSphere Web Client UI and is not available in the vSphere C# Client. If you need to configure the Multiwriter VMDK flag and do not have access to the vSphere Web Client, you can use the vSphere API to help automate this configuration change.

UPDATE (06/27/16) - Created two scripts which now cover scenarios where VM is online and/or offline.

For those interested in Automating the Multiwriter VMDK flag, I have created two PowerCLI scripts called: configureMultiwriterVMDK.ps1 (offline VM configuration) and addMultiwriterVMDK.ps1 (online VM configuration) which demonstrates this new vSphere API.

The first script configureMultiwriterVMDK.ps1 allows you enable the Multiwriter Flag for an existing VMDK that has already been added to a VM. This operation must be done while the VM is powered off and to use the script you will need to specify the name of the VM as well as the label of the VMDK in which you wish to enable the Multiwriter VMDK flag (e.g. Hard disk 2). Below is an example of running the script.

Screen Shot 2015-10-16 at 8.24.46 PM
The second script addMultiwriterVMDK.ps1 allows you to hot-add a new VMDK and enables the Multiwriter Flag to a VM. This operation is done while the VM is powered on which is a common workflow for customers needing to hot-add storage to an existing Cluster solution such as Oracle RAC for example all while the system is running. To use the script, there are a few variables you will need to edit:

  • vmName - The name of the VM you wish to perform th operation on
  • vmdkFileNamePath - This is the full datastore path to the name of the underlying VMDK. See the script for more information but the syntax will look like "[datastore-name] vm-home-dir/vmdk-name.vmdk"
  • diskSizeGB - The capacity of the VMDK to add (GB)
  • diskControllerNumber - The SCSI controller number (0-3)
  • diskUnitNumber - The Unit number (0-16)

Handy tidbits & workarounds for the VCS to VCSA Migration Fling

by //

The VCS (Windows VC) to VCSA Migration Fling has been out for a little over 6 months and the response from customers thus far has simply been phenomenal. We have also received some great feedback (200+ comments) from customers who have tried out the Fling in either a Dev/Test environment and some even in their production environment for those that are a bit more on the adventurous side. I have also had the pleasure in talking to some of these customers who have been successful in migrating off of their Windows vCenter Server (both large and small) and onto the vCenter Server Appliance (VCSA) and sharing additional feedback they may have about the Fling and how we can further improve.

Given the popularity of this topic, I thought it would be useful to aggregate some of the learning's, tidbits and workarounds that have been discovered in the past 6months to help any new or even existing users who might be interested in trying out the Fling. We really do appreciate all the feedback that everyone has given in the various forms and in fact, several of the workarounds were ones provided by our customers. As you know, the Fling today is not currently officially supported, however the feedback has really helped our PM/Engineering team. In fact, you can even get a sneak peak at an early Tech Preview we did at VMworld here to give you an idea on how some of your feedback has influenced a feature that may or may not be out in the near future 😉

Tidbit 1 Microsoft Windows 2012 is currently not supported.
Additional Info There is a known winexe bug which is affects migrating from this specific OS platform.
Workaround Engineering has a fix for this and is currently in the process of testing the fix along with legal review. There is not an ETA due to the review but we hope to release an update to Fling that includes this fix very soon. Stay tuned!This has been resolved with v0.9.1 of the Migration Appliance and for more details please take a look here.
Tidbit 2 Use of non-default (custom) ports on Microsoft SQL Server Database is not supported
Additional Info The Fling currently assumes the SQL Server Database is running on port 1433
Workaround Engineering has a fix for this and is currently in the process of testing the fix along with legal review. There is not an ETA due to the review but we hope to release an update to Fling that includes this fix very soon. Stay tuned!
Tidbit 3 Use of an Embedded Microsoft SQL Server or Microsoft SQL Express Database on the vCenter Server is not supported
Additional Info Since the source Windows vCenter Server must be powered off during the database migration; running the database on the same source vCenter Server is not possible.
Workaround One option is to re-ip the source Windows vCenter Server and ensuring the vCenter Server service is completely disable which would allow the Migration Appliance to communicate with the database. This is not ideal as you are modifying the source Windows vCenter Server but has worked in our testing. Second option that several other customers have recommended instead is to export the vCenter Server Database to a single instance of a Microsoft SQL Server or Microsoft SQL Express and that has worked really well.
Tidbit 4 Clustered database such as Microsoft Clustering Services (MSCS) is not supported
Additional Info There have been issues from some customers when trying to connect to an instance of the vCenter Server Database behind an MSCS Cluster.
Workaround Exporting the vCenter Server Database to a single instance of a Microsoft SQL Server or Microsoft SQL Express and then using the Fling has worked for several customers.
Tidbit 5 Issues connecting to a non-default named instance (e.g. SERVERNAME\VCENTER) of the vCenter Server Database.
Additional Info Some customers have had issues with the connection string to a non-default named instance of the vCenter Server Database during the database migration portion of the Fling.
Workaround A solution that was identified by a customer used the following: http://stackoverflow.com/a/11921896/2668394
Tidbit 6 Upgrade to VCSA 6.0 after migrating from Windows vCenter Server 5.5 to VCSA 5.5 fails
Additional Info You see the following error "Extra sequences: vpx_host_cnx_seq;" in /var/log/vmware/upgrade/vcdb_req.err during the upgrade to VCSA 6.0. These sequences are only found and valid in a Microsoft SQL Server Database and are not relevant in an vPostgres Database and just simply need to be dropped as they are not used at all.
Workaround Login to the VCSA 6.0 appliance as root and run the following command: /opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB -c "drop sequence if exists vpx_host_cnx_seq cascade"

If you are running into issues while through the the migration, one thing you can do is login to the Migration Appliance and go to another virtual console (ALT+F2) and view the Migration logs  under /var/log/migrate.log SSH is currently not installed by default. If you wish to pull out the logs for additional support, you can install which will require internet access and you can do so by running the following commands:

sudo apt-get -y update
sudo apt-get -y install openssh-server
sudo /etc/init.d/ssh start

The credentials to the Migration Appliance is vmware/vmware

Lastly, if there are other tidbits or workarounds that you would like to share, feel free to leave a comment and I will get it added to the list.