Yellow Bricks

by Duncan Epping

VMware

Command-line upgrade of vCenter fails with Test transaction failed to update packages error

· ·

I have various test environments, and one of my environments I was testing the command-line upgrade of vCenter Server. Now, most of my environments we tend to use for destructive testing and strange update/upgrade scenarios, so we hit some strange issues every now and then. While I was doing the command-line based upgrade of vCenter Server (see this post for how to do that), I hit an error. The error was the following:

Test transaction failed to update packages

I looked at the log called “/var/log/vmware/applmgmt/software-packages.log”, and I noticed the following entry:

eventlog is obsoleted by (installed) syslog-ng-3.17.2-1.ph3.x86_64

I removed the package manually as follows:

rpm -e syslog-ng-3.17.2-1.ph3.x86_64

I then retried the update and it worked, as shown in the screenshot below!

Updating VCSA and hitting the error Test RPM transaction failed

· ·

I was updating my environment to vCenter Server 7.0 U2c, while going through the process I got this error that says “Test RPM transaction failed”. Below is the screenshot of the error. if you click “resume” you then, unfortunately, get stuck in an infinite loop. The only way to get out of the loop is by removing a file via SSH on vCSA called “/etc/applmgmt/appliance/software_update_state.conf”.

So now what if you want to update? We resolved it as follows, and let me include the deletion of the state file as well:

rm /etc/applmgmt/appliance/software_update_state.conf

Then we rebooted the VCSA:

reboot

Then we went into the appliance shell via SSH and ran the installer from the appliance:

appliancesh
software-packages install --url --acceptEulas

After which the installation was completed correctly.

vSAN Storage Rules policy capability allows to set dedupe per VM?

· ·

There was a question posted on the VMware Community Forums, and as this is something I have been asked regularly, I figured I would do a quick blog post about it. Although I have covered this before, it doesn’t hurt to repeat, as it appears to be somewhat confusing for people. When you create a VM Storage Policy, starting with vSAN 7.0 U2 you have the ability to specify if a VM needs to be Encrypted, have Dedupe and Compression enabled, have Compression-Only enabled, and/or needs to be stored on all-flash vSAN or Hybrid. Never noticed it? Look at the screenshot below.

In the screenshot, you see that you have the ability to specify which data service needs to be enabled. I guess this is where the confusion comes into play, as this functionality is not about enabling the data service for the VM to which you assign the policy. This is about which data service needs to be enabled on the datastore to which the VM can be provisioned. Huh, what? Okay, let’s explain.

If you are using vSAN as your storage platform, and you are sharing vSAN Datastores between clusters leveraging the HCI Mesh feature, then you could find yourself in a situation where some clusters are hybrid and some are all-flash. Some may have data services enabled like Encryption or Deduplication, some may not. In that scenario you want to be able to specify which features need to be enabled for the datastore the VM is provisioned to. So what this “storage rules” feature does is that it ensure that the datastore which is shown as “compatible” actually has the specified capabilities enabled! In other words, if you tick “data-at-rest encryption” in a policy and assign the policy to a VM, then only the datastores which have “data-at-rest encryption” enabled will be shown as compatible with your VM!

So again, “storage rules” apply to the data services that should be enabled on the vSAN Datastore, and do not enable data services on a per VM/VMDK basis.

<Update for vSAN 8.0 ESA>

With vSAN 8.0 ESA the above has changed. With vSAN 8.0 ESA you can set compression per VM, and you actually do that using the policy storage rules. I discussed this in this blog post.

iSCSI IQN may have changed after upgrade to 7.0 U2

· ·

Last week I noticed some folks reporting that they had an issue with upgrades to 7.0 U2 from 7.0 U1. The issue they experienced was not being able to access their iSCSI Datastores any longer. I did some digging internally and found out there was a change in how we store the iSCSI IQN when the IQN is randomly created. Now note, this problem only exists for randomly created IQNs, so if you have a custom-named iSCSI IQN then you can stop reading here. If you have a random IQN and also have access control defined for your initiators, then you will want to read this if you are planning on upgrading.

Basically what happens if you upgrade from 7.0 U1 to 7.0U2 and you use a randomly generated IQN is that we regenerate the IQN after a reboot. What does that look like, well on VMTN user Nebb2k8 posted this:

7U1d = iqn.1998-01.com.vmware:labesx06-4ff17c83

7U2a = iqn.1998-01.com.vmware:labesx07:38717532:64

As you can see, the format also changed.

So if you lose (or lost) access after the upgrade, you simply copy the newly generated IQN and add it to the access control list of your storage system for the LUNs it applies to. Make sure to remove the old IQNs. Another option of course is to configure the randomly generated IQN as a custom IQN, this is pretty straightforward as shown below for “vmhba67”. You could create new IQNs, or you could re-use the randomly generated old IQNs if you want to keep them the same.

$ esxcli iscsi adapter get -A vmhba67

 vmhba67
&nbsp; &nbsp;Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

If you would like to know more about this issue, make sure to read this KB article, or read this article by Jason Massae which also provides some PowerCLI code to get/set the IQN.

Which vSAN Maintenance Mode option was used on a host?

· ·

Last week there was a question on VMTN around maintenance mode, this customer wanted to find out which vSAN Maintenance Mode option was used while the host was placed in maintenance mode. The person who placed the host into maintenance wasn’t around, and I guess the customer wanted to know if data was moved from the host or not. They looked at the events and tasks, but unfortunately it wasn’t obvious from that vCenter section, next up were the logs. I also looked at the logs, and you would expect this info to be stored in hostd.log, but it wasn’t, so where is it? Well it actually is a configuration item, and you can dig it up here:

Pre ESXi 7.0 the info is stored in the “esx.conf” file, just grep for “hostDecommission”. Let me show you:

$ grep "/vsan/hostDecommission" /etc/vmware/esx.conf
/vsan/hostDecommissionVersion = "10"
/vsan/hostDecommissionState = "decom-state-decommissioned"
/vsan/hostDecommissionMode = "decom-mode-ensure-object-accessibility"

If the ESX is at 7.0 or later, just run the below config store command:

$ configstorecli config current get -c vsan -g system -k host_state
{
   "decom_mode": "ENSUREOBJECT_ACCESSIBILITY",
   "decom_state": "DECOMMISSIONED",
   "decom_version": 0
}

I hope that helps others who have a similar question!