WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

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

01.11.2017 by William Lam // 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 🙂

Categories // Automation, ESXi, OVFTool, VCSA Tags // ovftool, vm storage policy, vm storage profile, VSAN

How to install PowerCLI Core on Debian Linux?

01.04.2017 by William Lam // 6 Comments

PowerCLI Core has been tried on two Linux distributions: VMware's Photon OS and Ubuntu 14.04, however that is not to say it would not work on other distros. In fact, .Net Core (which PowerCLI Core consumes) supports a variety of Linux distributions which can be found here. I recently needed to run PowerCLI Core on a Debian 8 system which required a few minor tweaks to get working. I figure I might as well document the steps in case this might help others wanting to use PowerCLI Core which now includes PowerNSX on a Debian system.

Step 1 - Append the following repo source to /etc/apt/sources.list configuration file:

deb http://ftp.de.debian.org/debian sid main

Step 2 - Run the following command to update the repo

apt-get update

Step 3 - Download .deb package for latest Powershell release and run the following command which will generate list of required dependencies:

wget https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.14/powershell_6.0.0-alpha.14-1ubuntu1.16.04.1_amd64.deb
dpkg -i powershell_6.0.0-alpha.14-1ubuntu1.16.04.1_amd64.deb

Step 4 - Run the following command to install powershell along with its dependencies:

apt-get -f install

Step 5 - The next series of commands will download and setup PowerCLI Core:

mkdir -p /powershell
wget https://download3.vmware.com/software/vmw-tools/powerclicore/PowerCLI_Core.zip -O /powershell/PowerCLI.ViCore.zip
apt-get -y install unzip
unzip /powershell/PowerCLI.ViCore.zip -d /powershell
mkdir -p /root/.config/powershell/
mkdir -p ~/.local/share/powershell/Modules
unzip /powershell/PowerCLI.ViCore.zip -d ~/.local/share/powershell/Modules
unzip /powershell/PowerCLI.Vds.zip -d ~/.local/share/powershell/Modules
mv /powershell/Start-PowerCLI.ps1 /root/.config/powershell/Microsoft.PowerShell_profile.ps1

Step 6 (Optional) - Install PowerNSX module:

wget https://github.com/vmware/powernsx/archive/master.zip -O /powershell/master.zip
unzip /powershell/master.zip -d /powershell/
mkdir ~/.local/share/powershell/Modules/PowerNSX
cp /powershell/powernsx-master/PowerNSX.ps*1 ~/.local/share/powershell/Modules/PowerNSX/

If everything installed successfully, you should be able to now launch PowerCLI Core by simply typing "powershell"

Categories // Automation, PowerCLI Tags // debian, linux, PowerCLICore

'System.Management.Automation.ConfigPropertyAccessor' exception when launching PowerCLI Core in Linux firstboot script

01.03.2017 by William Lam // Leave a Comment

Happy New Years everyone!

I just got back into the swing of things after taking some much needed time off over the holiday break. While catching up on my email, I also re-visited one of my pet projects I had been working on right before the break. I needed to launch a specific PowerCLI script upon firstboot from a Linux system, specifically PhotonOS leveraging PowerCLICore. My first few attempts had failed and in troubleshooting the issue further, I found the following cryptic error message in the system logs:

The shell cannot be started. A failure occurred during initialization:
The type initializer for 'System.Management.Automation.ConfigPropertyAccessor' threw an exception.

After a bit of Googling, I found the following Github PR which seems to indicate that the HOME environmental variable may not properly configured or readable by Powershell. The quick fix was to simply define the HOME directory within the shell script that starts up the PowerCLI script.

Below is a snippet of what I needed to add to /etc/rc.d/rc.local to automatically run my PowerCLI script:

export HOME=/root

/usr/bin/powershell -File /root/MyPowerCLI-Script.ps1

The following command was also useful in troubleshooting and verifying that my PowerCLI script had properly executed since there was no output in my script log:

journalctl --no-pager | grep rc.local

Categories // Automation, PowerCLI Tags // linux, Photon, PowerCLICore

  • « Previous Page
  • 1
  • …
  • 151
  • 152
  • 153
  • 154
  • 155
  • …
  • 224
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...