WilliamLam.com

Workaround to deploy vSphere Integrated Containers 1.1 OVA using PowerCLI (SHA256 not supported)

by // 2 Comments

Last week I had noticed several folks were having issues deploying the latest vSphere Integrated Containers (vIC) 1.1 OVA using PowerCLI. The following error message was observed when using the Get-OvfConfiguration cmdlet which is needed before importing an OVF/OVA:

PowerCLI doesn't support SHA256 hash codes in OVF manifest

As you probably have guessed, the issue is that PowerCLI currently does not support the SHA256 hashing algorithm, which the latest vIC OVA was generated with. I suspect this is probably related to the change with OVFTool 4.2 which now defaults to SHA256 which also has some implications on which vSphere UI you can use to import OVF/OVAs which I had written about here. As of today, PowerCLI currently only supports SHA1 and anything greater will not work. I have already reported this to Jake Robinson who is the PM for PowerCLI and hopefully this will get addressed in a future update.

In the meantime, you can deploy vIC using either the vSphere Web Client and/or ESXi Embedded Host Client, both support SHA256. If you wish to Automate the deployment of vIC, the only option right now is to convert the OVA from SHA256 to SHA1. You can easily do this by using OVFTool which is available on all OS platforms. If you already have downloaded the vCenter Server Appliance (VCSA) ISO, you can even make use of its bundled OVFTool in case you did not want to install OVFTool (You can find it under vcsa/ovftool in extracted ISO).

To convert the hashing algorithm, we just need to pass in our desire hash to the --shaAlgorithm parameter.

ovftool.exe --shaAlgorithm=SHA1 C:\Users\primp\Desktop\vic-v1.1.1_56a309fb.ova C:\Users\primp\Desktop\vic-v1.1.1_56a309fb-SHA1.ova

Once the conversion is done, you can delete the original vIC OVA and then use PowerCLI to import the new OVA just like you would with any other OVF/OVA!

New "raw" VM Storage Policy support in OVFTool 4.2 simplifies bootstrapping VMs onto VSAN

by // 2 Comments

Several weeks back I came across a handy little tidbit on an enhancement that was added to the latest version of OVFTool (4.2) that greatly simplifies the bootstrapping of a vCenter Server or any other VM for that matter onto a vSAN Datastore. This is generally used when setting up a pure greenfield environment where your vCenter Server may not be setup yet and you want to run it on top of vSAN which is fully supported configuration. The process of "bootstrapping" a VCSA onto a single node vSAN datastore is documented on my blog here. The high level steps are as follows:

  1. Temporarily change default ESXi VM Storage Policy to allow forced provisioning and FTT=0 (e.g. no protection)
  2. Claim disks for creating vSAN Diskgroup(s)
  3. Create vSAN Cluster
  4. Deploy VCSA
  5. Apply the default vSAN VM Storage Policy to VCSA VM
  6. Revert the temporarily change of default ESXi VM Storage Policy

With this new OVFTool enhancement, Step 1 and 6 is no longer needed from the standpoint of needing to change the default VM Storage Policy on the ESXi host using the ESXi Shell or using the vSphere API. Instead, you can now pass in a "raw" VM Storage Policy (SPBM) to apply to the specific OVF/OVA that is being deployed rather having to make a global change on the ESXi host. This also helps reduce the post-deployment steps as you only need to re-apply the default vSAN VM Storage Policy to the vCenter Server VM and not have to touch ESXi host settings once the vCenter Server is up and running.

To use this new raw VM Storage Policy feature in OVFTool, there is a new command-line option called --defaultStorageRawProfile which accepts the "raw" VM Storage Policy as you would normally provide to SPBM APIs such as "((\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i1))" for example.

The really cool thing about this feature is that you can take advantage of this directly with the new OVFTool argument passthrough feature that was introduced in the VCSA 6.5 CLI deployment utility. Combining these solutions together, you can easily simplify the "bootstrapping" of a VCSA onto a vSAN Datastore. Below is the snippet that you would include in the VCSA JSON configuration file used for deployment.

"ovftool.arguments" : {
"defaultStorageRawProfile" : "((\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i1))"
}

Although a tiny enhancement, I think this is a pretty neat capability, especially being able to make use of it natively within the VCSA configuration file. It is definitely great to see us continue to simplify how VMware management infrastructure is deployed and definitely stay tuned on what else we have cooking in the future for this particular area 🙂

VCSA 6.5 CLI Installer now supports new ovftool argument pass-through feature

by // 2 Comments

I had recently discovered a really cool new feature that has been added into the vCenter Server Appliance (VCSA) 6.5 CLI Installer while helping out a fellow colleague. For those of you who have not worked with the VCSA before, you can deploy it using one of two methods: 1) Guided UI Installer 2) Scripted CLI installer. The latter approach is great for Automation purposes as well as being able to quickly spin up a new VCSA as the UI wizard can get tedious once you have done it a few times. The VCSA CLI Installer reads in a JSON configuration file which defines what you will be deploying whether that is an Embedded, PSC or VC node and its respective configuration (networking, password, etc).

In VCSA 6.5, the CLI Installer introduces a new option in the JSON schema called ovftool.arguments. Here is the description of what this new option provides:

Use this subsection to add arbitrary arguments to the OVF Tool
command that the script generates. You do not need to fill it out in
most circumstances.

First of all, I just want to mention that this option should not be required for general deployments but it may come in handy for more advanced use cases. Behind the scenes, the CLI Installer takes the human readable JSON and translates that to a set of OVF properties that are then sent down to ovftool for deployment. Not every single option is implemented in the JSON and for good reason as those level of details should be abstracted away from the end users. However, there may be cases where you may need to invoke a specific configuration or trigger a specific ovftool option and this would allow you to provide what I am calling a "pass-through" to ovftool.

Let me give you one concrete example on how this could be useful and how we can take advantage of this new capability. Since the release of VCSA 6.0, when you enable SSH and you login, you will notice that you are not placed in a regular bash shell but rather a restricted appliancesh interface. From an Automation standpoint, it was some what painful if you wanted to change the default as this feature is not implemented within the JSON configuration file. This meant that if you wanted the bash shell to be the default, you had to either change it manually as part of a post-deployment or you would have to by-pass the native CLI Installer and manually reverse engineer the required set of OVF properties needed for the deployment which is also not ideal.

[Read more...]