View and Modify Delete On Termination Setting on AWS EBS Volume

When launching an AWS EC2 instance, you can specify whether a EBS volume will be deleted when the instance is terminated. The setting is “Delete On Termination” and it’s on by default.

Once the instance is launched, viewing or modifying this “Delete On Termination” setting is not obvious. This post is to document how I do it.

View “Delete On Termination” Setting on AWS EBS Volume

There are two ways:

• Use EC2 management console
• Click on Instances and select the instance
• Under Description tab,scroll down to “Block devices"
• Click on the device name to show the “Delete on termination” setting on the pop-up window

• Use AWS CLI
  • Get the instance ID
    • $ aws ec2 describe-instances --query 'Reservations[*].Instances[*].InstanceId' --output text
  • Query the setting
    • aws ec2 describe-instances --filter "Name=instance-id,Values=i-0d0a326ab6691cf24" --query 'Reservations[*].Instances[*].BlockDeviceMappings[*].Ebs.DeleteOnTermination'

Modify “Delete On Termination” Setting on AWS EBS Volume

I cannot find a way to modify this setting on EC2 management console. It looks AWS CLI is the only way. Here is the CLI.

aws ec2 modify-instance-attribute --instance-id i-0d0a326ab6691cf24 --block-device-mappings file://./change.DeleteOnTermination.json

The json file format is below. Update the DeviceName to match the EBS volume that you wan to modify

[
{
"DeviceName": "/dev/xvda",
"Ebs": {
"DeleteOnTermination": false
}
}
]

After executing the CLI, refresh the management console and click on the volume name under the instance description to verify the setting has been modified.

Using growpart to extend a Linux non-LVM partition

This post is about using growpart to extend a non-LVM Linux partition. For extending a LVM volume, see my other posts - Extend a Linux LVM Volume on a VM part1, part2, and part3.

When increasing the size of a Linux parition, it normally requries the following procedures:

1. Increase the size of the physical or virtual hard drive
2. Extend the partition to added drive space
3. Resize the file system to extended partition

Among these steps, step #2 usually sounds risky. It requires to delete the existing partition and recreating it with the new size. Most people are not confortable to do that, and they end up with adding a new bigger drive, creating a new bigger partition, formatting the new partition, and copying the files from the old partition to the new bigger. This not only is time comsuming, but only requires more physical or vritual disk space.

Recently I learned about growpart that makes step #2 much simpler and error free. Growpart may not be installed by default, but it should be available on your distro. The following is the commands to increase a Linux partition (/dev/sdb1) on CentOS.

• sudo yum install cloud-utils-growpart
• increase the disk size (e.g. /dev/sdb) and reboot
• sudo growpart /dev/sdb 1 ### there is a space between sdb and 1. 1 is the partition number
• sudo resize2fs /dev/sdb1

See growpart man page for more info.

Installing vSphere Client fails with the error “VMInstallHcmon - Failed to install hcmon driver”

When installing the latest vSphere Client 6.0 on my Windows 10 computer, I got the following error “VMInstallHcmon – Failed to install hcmon driver”

Troubleshooting

• Try KB2006486. But I don’t see Non-Plug and Play Drivers and VMware hcmon on my Windows 10 computer
• Try renaming the C:\Windows\System32\drivers\hcmon.sys file. Still get the same error

Solution

• On my laptop, vSphere Client 5.5 and 6.0 (older build), and their respective Update Manager plug-in are installed
• Remove these older clients and plug-ins
• vSphere Client 6.0 installation completes successfully

vSphere Client 6.0 could not connect to vCenter server error “The client did not receive a complete response from the server”

Due to security concerns in the TLS v1.0, we start disabling it on the system. After disabling TLS v1.0 on a Windows machine, I got the following error when connecting to a vCenter Server 6.0 using the vSphere Client (legacy C# client).

Troubleshooting

• I am still able to login vCenter via the vSphere Web Client on the web browser
• Re-enabling TLS v1.0 on the machine, I am able to login vCenter via the vSphere Client again
• The vCenter server is a VCSA 6.0 Update 3e. TLS v1.1/v1.2 are enabled by default (KB2145796).

Solution

1. Download and install the latest vSphere Client 6.0. As of this writing, vSphere Client 6.0.0 build 6855219.
2. Navigate to the configuration file C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe.config
3. Edit the VpxClient.exe.config file by setting the parameters
   <add key = “EnableTLS12” value = “false” />
   as
   <add key = “EnableTLS12” value = “true” />

Additional notes

• An older build of the vSphere Client 6.0 may not have the “EnableTLS12” entry in the configuration file. Install the latest build from the link in step #1.
• Some Microsoft updates or .NET 4.6.2 may need to install on the machine. See KB2149000.

Set Visual Studio Code (VS Code) Default Language Mode When New File Opened

Visual Studio Code is my default PowerShell script editor. It is free and available in Windows, macOS, and Linux.

By default, it uses text as the script language when a new file is opened. To make it recognize the PowerShell cmdlet, I have to manually change the language mode (press F1, type Change Language Mode, then select PowerShell form the list of the language) or first save to the file to ps1. This becomes inconvenience overtime.

Luckily, a new setting “files.defaultLanguage” is added. I didn’t backtrack when this setting was added. It’s available in the current release 1.14.0 as of this writing.

To configure the default language setting,

• Open File, Preferences, Settings
• Add the following to set PowerShell as the default language mode
• “files.defaultLanguage": "powershell",
• Save the setting.json file

To set other supported languages as the default

• Delete “powershell” in the line
• Press Ctrl + Spacebar to select the option from the list

Use WinSCP to Transfer Files in vCSA 6.5

To use WinSCP to transfer files with vCSA, VMware KB2107727’s solution is temporarily changing the default shell from appliancesh to bash, then changing back after the transfer. This works in vCSA 6.0 and vCSA 6.5.

In vCSA 6.0, there is a tick to change the WinSCP’s Advanced, SFTP server setting to "shell /usr/lib64/ssh/sftp-server" (without the quotes) for file transfer without changing the default shell. See “Connect to vCSA using WinSCP”

VMware changed the OS from SLES to Photon in vCSA 6.5. The above setting doesn’t work anymore. There is no ssh directory under /usr/lib64/. However, a quick search and find the sftp-server is moved to /usr/libexec/. Using the setting “shell /usr/libexec/sftp-server” in vCSA 6.5 works fine.

Here is the detail instruction.

• Log in vCSA VAMI UI (https://vcsa-ip:5480)
• Under Access, enable SSH Login. (PS: enabling Bash Shell is not necessary)
• Open WinSCP, select File protocol: SFTP
• Enter the vCSA hostname, port number 22, root, and root’s password
• Click Advanced
• Under Environment, SFTP, Protocol options
• Set SFTP server to “shell /usr/libexec/sftp-server” (without the quotes)

PS: I tested the setting in WinSCP v5.9.6 build 7601 and vCSA v6.5.0.5600 build 4951144.

VCSA 6.5 “The appliance management service is not running” Fix

Scenario

In vSphere Web Client 6.5, under Home, Administration, Deployment/System Configuration, Nodes, the vCenter Server node shows an error message “The appliance management service is not running”. An error message “HTTP response with status code 503, 503 Service Unavailable (Failed to connect to endpoint: _serverNamespace = /vmonapi action =Allow _port = 8900" also appears in the web client.

Troubleshooting

• Login the VMware Appliance Management UI (https://psc:5480 or https://vc:5480). All the health status are good.
• SSH to VC appliance. Check service status (KB2109887)
• # service-control –list
• # service-control –status
• applmgmt (VMware Appliance Management Service) is running
• vmonapi (VMware Service Lifecycle Manager API) is not running

Solution

• Restart vmonapi service or restart all services
• # service-control --start vmonapi
• # service-control –start –all
• PS: if restarting all the services, it may take some time before all services turn back to Good (green) in the node’s Summary page. e.g. VMware Performance Charts service takes more than 30 minutes to change from Warning, Unknown, and then Good.