AKA - Another reason to stop using the vSphere C# Client....
I created an OVF template from my vSphere 6.5 environment. When trying to import the template using the vSphere C# Client, I received the following error:
The following manifest file entry (line 1) is invalid: SHA256
vSphere 6.5 started using SHA256 as the default hashing algorithm when exporting OVF templates. Unfortunately, the vSphere Fat/C# Client only supports SHA1.
There a several ways to resolve this issue:
Option 1- Use the Web or HTML 5 client to import the OVF. Both support SHA256.
Option 2. Use the OVFTool to convert the Cryptographic Hash Algorithm from SHA256 to SHA1. This free tool can be downloaded here:
https://www.vmware.com/support/developer/ovf/
Option 3. (Not recommended) If you trust the source of the OVA, you can delete the optional .mf file (manifest file) and just use the .ovf and .vmdk files to import the VM.. The .mf file contains the SHA256 info
I'm a Sr. Systems Engineer at a Global Environmental Engineering company. I've been in IT since 1999 and from 2005, my focus has been VMware datacenter products. More recently, my attention has been for Microsoft Azure services. As the Global Service Owner for VMware Datacenter products, I've had the pleasure of having in-depth and hands-on experience with not only VMware products, but server, storage and networking technologies.
Tuesday, May 15, 2018
ESXi 6 - How to Unlock Your SSH Account.
ESXi Account lockout info:
1. Accounts are locked after 10 failed attempts through SSH and the vSphere Web Services SDK.
2. The Direct Console Interface (DCUI) and ESXi shell do not support the account lockout feature.
3. The account automatically unlocks after 120 seconds by default.
4. ESXi leverages the Linux Pluggable Authentication Modules (PAM)
If you are unable to wait for the account to unlock, you can reset the account by doing the following:
1. Console into your server by using your DRAC/iLO/UCS Manager etc.
2. log in as root, and run the following command to unlock the account. In the example below, you can see there was 11 failed attempts:
pam_tally2 --user root --reset
1. Accounts are locked after 10 failed attempts through SSH and the vSphere Web Services SDK.
2. The Direct Console Interface (DCUI) and ESXi shell do not support the account lockout feature.
3. The account automatically unlocks after 120 seconds by default.
4. ESXi leverages the Linux Pluggable Authentication Modules (PAM)
If you are unable to wait for the account to unlock, you can reset the account by doing the following:
1. Console into your server by using your DRAC/iLO/UCS Manager etc.
2. log in as root, and run the following command to unlock the account. In the example below, you can see there was 11 failed attempts:
pam_tally2 --user root --reset
Wednesday, April 25, 2018
vSphere 6 - SSL Certificates - Overview and Best Practices
As corporate security becomes a higher priority, I just wanted to give a quick rundown on SSL Certificates in vSphere 6 since it has changed drastically from previous versions.
The VMware Certificate Service is part of the
Platform Services Controller (PSC)
Key Terms:
VMWare Certificate Authority (VMCA) – Certificate authority for vSphere components only. A single point of contact for vSphere Certificate needs. Issues certificates for VMware solution users, machine
certificates for machines on which services are running and ESXi host
certificates. Operates in the PSC. Certificates are managed by the certificate-manager utility.
VMware Endpoint Certificate Store (VECS) –
Serves as a local repository for certificates, private keys and other
certificate information. Runs in vCenter
Server Node.
Types Of Certificates Used by vSphere
- Machine Certificates- For Secure connections. This is what causes the web browser certificate warning if the certificate used is self signed. (ex. vSphere Web Client - vCenter server and external PSC have them)
- Solution user certificates - authentication of services to vCenter SSO. (ex vcenter service (vpxd))
- ESXi certificates – provisioned when the host is added to vCenter. Stored locally on ESXi host.
Certificate Deployment Types:
- VMCA Default – By default, the VMCA uses a self-signed root certificate. The VMCA is then the CA for all VMware components.
- VMCA Enterprise - The VMCA is used as a subordinate/Intermediate CA and is issued a subordinate CA signing certificate. It can now issue certificates that trust up to the enterprise CA’s root certificate. Not accepted by most security groups, since this poses a security risk.
- Custom Certificates – The VMCA is bypassed. Need to issue a enterprise/3rd party cert for every component. Must replace each certificate explicitly. Administrative nightmare!
- Hybrid - The VMCA supplies some of the certificates, but also uses custom certificates for other parts of the VMware infrastructure. As of the time of this writing, this is the RECOMMENDED approach.
In a vast majority of environments, the following hybrid deployment is the best fit.
Trusted Certificates are used for the Machine Certificates of the vCenter server and external PSC. The management interfaces are using a 3rd party/Corporate trusted CA. These are the most important certificates and is the only user-exposed certificates.
VMCA certificates are the used for the Solution user and ESXi certificates.
Added bonus, no more "Not Secure" warnings in your browser!
VMware KB regarding replacing machine certificates:
Fantastic VMWare Walkthrough for SSL cert replacement on your vCenter server and External PSC:
Saturday, March 17, 2018
How to mount an ISO to an ESXi Host
I was recently working on and issue in an environment that required me to mount an ISO to an ESXi host.
To access the contents of a CD or ISO within your ESXi Host perform the following:
1. Mount the ISO using iDRAC / iLO etc.
2. Console into the ESXi host and run the following to load iso9660:
vmkload_mod iso9660
3. To find the path to the CD ROM drive run the following:
esxcfg-mpath -l | grep -i cd-rom
4. Run the following to mount the CD-ROM drive:
To access the contents of a CD or ISO within your ESXi Host perform the following:
1. Mount the ISO using iDRAC / iLO etc.
2. Console into the ESXi host and run the following to load iso9660:
vmkload_mod iso9660
3. To find the path to the CD ROM drive run the following:
esxcfg-mpath -l | grep -i cd-rom
4. Run the following to mount the CD-ROM drive:
vsish -e set
/vmkModules/iso9660/mount <devicename>
5. You will now be able to see the contents of the CD- Rom in /vmfs/volumes/. In my case, the ISO I mounted was named "20180215":
6. Once you're done unmount the CD/ISO with the following:
vsish -e set
/vmkModules/iso9660/umount <devicename>
7. To unload the iso9660 module":
vmkload_mod -u iso9660
On a similar note, I've had a lot of success using the following application to create ISOs from files/folders:
VMWare Update Manager - interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader
After logging into the vSphere Web Client, I found the following error in the Update Manager section:
interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader
I started off by restarting the VMWare vSphere Update Manager Service for the affected vCSA:
1. Log into vCenter using the administrator@vsphere.local account.
2. Home - System Configuration - Services - Restart
This did not resolve my issue... Unfortunately, I had to resort to something a bit more drastic and disruptive. Since I did not know which service(s) needed to be restarted I restarted all of them.
SSH/Console into the affected server and run the following commands:
service-control --stop --all
service-control --start --all
This resolved the issue and I was able to see the proper output under the Update Manager tab.
interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader
I started off by restarting the VMWare vSphere Update Manager Service for the affected vCSA:
1. Log into vCenter using the administrator@vsphere.local account.
2. Home - System Configuration - Services - Restart
This did not resolve my issue... Unfortunately, I had to resort to something a bit more drastic and disruptive. Since I did not know which service(s) needed to be restarted I restarted all of them.
SSH/Console into the affected server and run the following commands:
service-control --stop --all
service-control --start --all
This resolved the issue and I was able to see the proper output under the Update Manager tab.
vSphere 6 - Fix - Cannot complete operation due to concurrent modification by another operation.
Add more resources to a VM, not a problem right? Well, not this time. When attempting to add memory to a VM, I received the following error:
"Cannot complete operation due to concurrent modification by another operation."
I confirmed there were no other operations/modifications occurring on the VM at the same time. In the past, I would just SSH/Console into the vCSA and restart the services with the following commands. (Warning - This process is disruptive):
service-control
--stop –all
service-control
–start –all
In this case, the services restart did not resolve the issue. On a whim, I created and deleted a snapshot on the VM. This action "freed" up the VM and allowed me to add the additional resources.
In the future, I'm going start off with the "snapshot" route since it's less disruptive.
Hope this helps!
Friday, March 16, 2018
Subscribe to:
Posts (Atom)

