A little bit about vpxuser

general information

Here's what everyone knows: vpxuser is the account that vCenter uses to manage ESXi hosts (polling the hypervisor, sending the task), which are included in it. Those. The root (ESXi) account is not related to the vCenter-ESXi connection (except for the nuance that is needed to enable ESXi in vCenter).

Vpxuser has ESXi admin rights. Thus, the vCenter administrator can perform almost all the same host manipulations as root (ESXi), except for creating / deleting / changing local users and groups of the host ESXi itself .
You cannot manage the vpxuser account using the AD directory service.

The vpxuser password is stored in encrypted form on both ESXi and vCenter (logical, isn't it?), And for each ESXi this password is unique.
')

Connect to ESXi using VPXUSER

In some sources I saw statements like this: “Knowing the password from vpxuser will give you nothing, using this combination to connect to the host and any other purposes is impossible.” However, knowing the vpxuser password, you can connect to and manage ESXi (tested on Standalone ESXi 5.5 u1 and on ESXi 5.5 u1 running vCenter 5.5, and not only on them).


On the other hand, you cannot find out the vpxuser password (at least I haven’t found a way), so you can only connect in this way by changing the vpxuser password, and you don’t need to do this (read on).

VPXUSER password change

In the documentation you can find a warning, which in the free (my) translation looks like this:

ATTENTION: manipulate the vpxuser account at your own peril and risk, this may lead to a communication failure vCenter - ESXi. When lockdown mode is enabled on the host, host control may be lost forever.

It really is. Having tested it in the laboratory, I can say that after changing the vpxuser password to ESXi, vCenter loses connection with it. But not immediately. In my case it happened in 18-20 hours. The most interesting thing is that after changing the vpxuser password to ESXi, I immediately rebooted the vCenter Service (but not the machine on which this service was deployed), i.e. the established session was supposed to be dropped, and the credenchials that were hypothetically in the cache (or maybe not the former, or maybe not in the cache) should have been cleared. But that did not happen. Those. VMware support did not comment on this behavior, saying that it does not answer questions on the architectural features of the platform.

Another thing is interesting: later in this article there is information about the password policy vpxuser, and by default the length of its password is 32 characters. If you change its password manually on ESXi, for example with the help of “passwd”, you can set the password much shorter. Apparently, this is due to the fact that the password policy is supported by vCenter, and since the vpxuser password is also changed by vCenter, then, as the saying goes, “I use my funny face and amuse myself”. Those. You can change the password, and you can set it with inappropriate policies, but the connection with ESXi will eventually be lost.

Loss of communication is quite logical, because with a manual change of the vpxuser password, its password in the vCenter ʻa database does not change.

Conclusion: do not change the password on vpxuser yourself, let vCenter do it. If you change the vpxuser password with your hands, then with a probability of 99%, sooner or later, vCenter will lose touch with ESXi. 1% I leave for magical intervention.

Troubleshooting

If, however, changes were made to vpxuser (for example, the password was changed) and this resulted in the inaccessibility of ESXi from vCenter (usually accompanied by an error: " Call" ServiceInstance.RetrieveContent "for object" ServiceInstance "on Server" ip_address "failed "), you can proceed as follows (if lockdown mode is not enabled and there is access to the host via SSH):

For releases 3.x and 4.x - kb.vmware.com/kb/1005759 . In short:

1. PCM on the host in vSphere Client, disconnect (unless, of course, the host is already in this state). DO NOT REMOVE the host from vCenter.
2. Connect via SSH to the host and run: “ userdel vpxuser ”.
3. RMB on the host and select “Connect”. Ignore all possible authentication errors.
4. Enter the required root username and password. The vpxuser account will be recreated.

For releases 5.x and 6.x, the procedure is the same except for item 2 (i.e., you do not need to delete vpxuser).

Here you should pay attention to the phrase "if lockdown mode is not enabled." If the vpxuser password was changed and vCenter lost contact with ESXi and lockdown mode is enabled, i.e. access to the ESXi host is denied to everyone except vCenter, then the official position of VMware on this account is unequivocal: “reinstall ESXi”.

Password policy for vpxuser

Password duration

By default, the vpxuser password is updated every 30 days, but this can be changed:

1. In vSphere Client → Administration.
2. vCenter Server Settings ... → Advanced Settings.
3. Select the VirtualCenter.VimPasswordExpirationInDays parameter, set the desired value.
4. Restart the vCenter service.


VMware does not recommend changing this setting. VMware doesn’t recommend doing a lot of things, living is bad, dying of it.

Password complexity

The vpxuser password consists of 32 characters, and contains at least 1 character from groups: special characters ({~ @ - {}, etc.), numbers (1-9), capital letters (Latin) and lower case letters (Latin).
The documentation indicates that to change the length of the vpxuser password, you can change the value of the vpxd.hostPasswordLength parameter in the configuration file on vCenter:

• Linux (VCSA) - /etc/vmware-vpx/vpxd.cfg;
• Windows - C: \ ProgramData \ VMware \ VMware VirtualCenter \ vpxd.cfg;

The vpxd.hostPasswordLength parameter in the config is missing, it needs to be added there. Here is a piece of the config with this parameter, where you can see the place where to insert it:

< vmacore > ........ < vpxd > < filterOverheadLimitIssues >true< /filterOverheadLimitIssues > < hostPasswordLength >32< /hostPasswordLength > < network > < rollback >true< /rollback > < /network > ........ < /vpxd> 

Those. inside vpxd, but not inside any other nested tag.

Conclusion: why change the password policy for vpxuser at all? Yes, no need, VMware does not recommend doing such nonsense.

In different releases

Here's what's interesting: in the early vSphere releases, the vpxuser user on Standalone ESXi did not exist (before the host was included in vCenter). This is evidenced by the article kb.vmware.com/kb/1005759 : an ESX host is added. Do not manipulate this account. Also checked by hand - on the Standalone ESXi 4.1 it really is not. It was suspected that this user in 4.1 is called vimuser (because the vpxuser password is controlled by the VirtualCenter parameter. Vim PasswordExpirationInDays), and vimuser in ESXi 4.1 is predetermined, but when you turn on ESXi 4.1 in vCenter, vpxuser is really created on the host and NOT deleted after removing the host from vCenter. However, kb1005759 is intended for releases 4.x and earlier. In the latest releases (in 5.5 and 6 exactly), vpxuser exists immediately after the ESXi deployment. Apparently, this account is not used until the host is included in the vCenter. I could not find any specific information about this nuance, but the user ap (Guru, vExpert) also believes that this account is not used . In addition, I changed the password for vpxuser to Standalone ESXi, and did not notice any consequences (for example, loss of access via SSH, vSphere Client).

There must be some conclusion

The conclusion about vpxuser is extremely simple - this is one of those things that should not be tyunted under almost any circumstances. The post is intended only to tell a little more about this account, about its presence in various releases and about myths, such as the fact that it cannot be used to directly connect to ESXi.