Important information for VMware vSphere 7.0 - Attempting to upgrade ESXi to version 7.0 using some OEM/partner images, bundles or addons may fail. Fresh/clean installs of ESXi 7.0 are supported when OEM/partner images are used. For this and other important deployment information prior to upgrading VMware vSphere 7.0, see.

Passwords are the things people tend to forget. Well, ESXi root passwords are not an exception either! Without the root password, you lose control over your hosts, so it’s good to know how to reset it. Well, resetting an ESXi host password is the thing I gonna talk about in this article.

Esxi 4

• To install VMware ESXi with this downloaded.ISO file using CD-ROM method, you need a CD-R or CD-RW and appropriate software to create a CD. Follow your CD writing software vendor's instructions to create a CD.
• For VMware ESXi 3.5 Update 2 and later'. So I suppose it's also valid for ESXI 4.0. I would like to register my ESXi 4 installed software and vSphere Client. From the vSphere Client Menu I chose: Help -> VMware on the web -> Register Now. The site ask me for 'Serial Number/License Activation Code' so i typed license key.
• Feb 04, 2012 Enjoying ESXi 4.0.0, but found your license key has expired? In two minutes, you can extend your license for another 60 days! Do remember, that why this is helpful for trial purposes, you are still lacking access to critical updates (such as patches that allow vSphere Client to operate in the presence of the latest version of Microsoft.NET). So enjoy, but don’t expect this little hack to.

Want to know why I wrote this article? I want to help other VMware admins. You see, when things like that happen, the first thing you do you look through some official documentation, right? Unfortunately, the only thing VMware advices to reset passwords is re-installing the OS. No fun! What if I don’t want to (or cannot) do that? In this article, I’m looking for a better way to reset the password.

For this article, I use ESXi 6.7.0, 8169922, but everything I write here works good for ESXi 6.x or 5.x versions. Some methods to reset the passwords may be pretty risky. So, don’t blame me in case you mess things up.

Esxi Vs Vsphere

Some theoretical findings

After thinking through some cases of how you guys lose passwords, I realized that these two scenarios are pretty common: you forgot the password, but you still can access the hosts via vCenter, and you lost the standalone host password from the standalone ESXi host and there’s no way to access it.

Well, the last one looks really tough. But, I’ll teach you today how to restore the password in both cases.

Changing the pass with vCenter

Let’s start with some bright scenario: you forgot the ESXi root password but there’s vCenter installed. I’d say that’s a pretty common issue. Admins manage the host through vCenter, but one day, they lose the password. Fortunately, that’s not a big deal to restore the password.

First, let’s look at how to change the password via the flash vCenter Webclient. Note that things I write here do not work in the html one! Also note that you need your ESXi edition to be not lower than Enterprise Plus.

In order to reset the password, you need to extract, edit, and upload Host Profile. Here’s how you do that.

Go to vCenter, and extract the host profile exactly how I do in the screenshot below.

While extracting, specify the host name and add some description if needed.

Check the entered information and press Finish.

In vCenter, navigate to the Home tab and go to Host Profiles there.

Right-click the Host Profile and edit its settings.

There, you can specify the new name and description if needed.

Once you are done with changing Name and host description, go to the Edit host profile tab itself. Actually, you can change a bunch of settings there, but let’s stick to the initial plan and change only root password, ok? To accomplish this task, type the new password and confirm it in the self-titled fields.

Congratulations, you have changed the password! Let’s add the the host to the cluster now and apply the settings.

In the Attach/Detach Hosts and Clusters menu, select the host where you have changed the password. At this point, I’d like to mention that you can apply the changes to multiple hosts.

Right after adding the host, you can play around with the network settings, if you need it. Well, you can just click Finish to have the settings applied.

Next, you need to put the node in the maintenance mode, otherwise you won’t be able to apply any settings at all!

Confirm putting the selected host (or hosts, whatever) in maintenance mode. Note that you need to migrate your VMs unless you can shut down them for a while. In my case, there are no mission critical VMs on the host, so I’ve just powered them off beforehand.

Now, go back to the Objects tab and, finally, implement the host settings. Right-click the Host Profile and press Remediate.

Select the required host.

Verify all the settings and check whether you can apply the changes at all. Press Finish.

After the host reboots, exit the maintenance mode.

Now, let’s check whether the password reset has run smoothly. For that purpose, log in at the ESXi node via the Web Console, or the terminal using the new password.

Resetting the root password using Active Directory and vCenter

You can also change the password in vCenter using the Active Directory. You see, if you can add the ESXi host to the domain, you are able to use the domain credentials to access the node and reset the root password. Here’s how you do that.

Go to the AD Users and Computers on the domain controller and create a new Security Group – ESX Admins. Make sure to use exactly that name for the workgroup. Add to that group a new user which you will use later to reset the password. Well, it actually can be any user, but I decided to create a new one – TestUser.

Add the host with the forgotten password to the domain.

Next, try logging in the ESXi host with the TestUser credentials. Here’s how you are to specify the user name: [email protected] or DomainUser.

Once you log in the host, go to the Security & users tab to reset the root password.

From now on, you can use the new root password! Don’t forget to leave from the domain if you do not need the host to be in the domain anymore.

To apply the changes, reboot the host.

Note that changing the password with vCenter is pretty easy, but VMware does not recommend it for some reason after all.

Resetting root password on the standalone ESXi hosts

Now, as we know how to reset the password with vCenter, let’s look at some tough cases. Let’s say, you don’t have vCenter installed on the host. Once again, I do not want to re-install the server OS as VMware says. Seriously, that’s not fun! Let’s look at something more interesting instead. Well, let’s say, what about changing the password right on the node itself?

Before I start, I’d like to mention that you won’t be able to trick ESXi security and change the root password on the node without shutting it down. This means that you, like it or not, do need to shut down each VM from the inside! If you screw things up, you won’t be able to start VMs without ESXi re-installation.

Also, you need the boot the CD image. I used Ubuntu GNOME in this article. Find out how to create a boot CD and download Ubuntu GNOME here. You also need Rufus to write the boot CD image on the flash drive.

So, you need to boot from the flash disk, mount the required ESXi datastore, unpack the archive, and edit the file with passwords. Next, you upload the file back into the initial directory, and, after rebooting the host, you can access the it without the password.

Editing the “shadow” file

What’s “shadow” is?

For safety concerns, ESXi keeps passwords encrypted in some file… whatever, here’s how you still can reset the password. According to some unofficial sources, this file is called “shadow”. You can find it in one of those booting volumes in the /etc directory. Before the host boots, /etc is in the local.tgz archive. Here’s the path: /etc => local.tgz => state.tgz. You can find it in one of those booting volumes in the /etc directory. Before the host boots, /etc is in the local.tgz archive. Here’s the path: state.tgz => local.tgz => /etc.

Here’s how the disk is formatted in ESXi 6.0 or higher:

Among of all those volumes, we need only the /bootbank one as it keeps the ESXi archive. In this way, “shadow” should be somewhere there.

Chasing the “shadow”

So, let’s boot the host from the flash disk first and start the terminal.

Run the following cmdlet to acquire root privileges:

# sudo su

See through the disk names and find the one you need.

# fdisk –l | grep /dev/sda

Well, it seems that we need that 250 MB /dev/sda5 directory. Create the mnt directory.

# mkdir /mnt/sda5

Create the directory for the temporary files now.

# mkdir /temp

And, mount the /dev/sda5 directory using the cmdlet below.

# mount /dev/sda5 /mnt/sda5

Now, look for that state.tgz archive I was talking above.

# ls -l /mnt/sda5/state.tgz

Extract both state.tgz and local.tgz. Here are the commands you can use for that purpose:

# tar -xf /mnt/sda5/state.tgz –C /temp/

# tar -xf /temp/local.tgz –C /temp/

Once you are done with unpacking, get rid of those old archives with the cmdlet below:

# rm /temp/*.tgz

Now, you are ready to do some magic with “shadow”. Open the file, edit it, and close it. As simple as it! To double-check the changes, open the file one more time.

# vi /temp/etc/shadow

Actually, here’s how “shadow” looks like inside. See, it contains all users’ passwords.

To reset the password, just delete everything between the double colons. Remember, everything is encrypted? That’s why passwords look that weird.

# vi /temp/etc/shadow

Next, go to the work directory.

# cd /temp

Now, add the “shadow” back to the archive.

# tar -czf local.tgz etc

# tar -czf state.tgz local.tgz

Move the new archive to the initial directory.

# mv state.tgz /mnt/sda5/

Unmount the /sda5 disk with the cmdlet below:

# umount /mnt/sda5

And, eventually reboot the host.

# reboot

Well, to make the stuff I’ve just written above more reader-friendly, here’re all commands you need to deploy step-by-step.

Well, you are almost there. Reboot the server now, and try accessing the host without any password. Well, check out what I’ve got.

Now, select Configure Password, and type a new password in the self-titled field.

Ok, this time, please write the root password, or just try no to forget it!

Replace one “shadow” with another

There’s another way to reset the ESXi root password using “shadow”. Actually, that’s nothing more than a variation of the method I described above.

So, another thing you can do to reset the ESXi password is just using another host “shadow” file! Yes, you can just copy the “shadow” file from another ESXi host with the known root password to the one more flash disk. To get the file with passwords from another host, you need WinSCP. The utility is available here. The nice thing is that you can retrieve that file from the host with the known ESXi root password without even shutting it down.

Next, call the terminal with the Ubuntu GNOME and reset the password.

Update user privileges to root first. You can run the following command for that purpose:

# sudo su

Now, let’s see what you have on the disk.

# fdisk –l | grep sd

Create two temporary volumes afterward.

# mkdir /mnt/sda5

# mkdir /mnt/sdb1

Mount the ESXi disk and flash disk where the “shadow” resides using the following cmdlet.

# mount /dev/sda5 /mnt/sda5

# mount /dev/sdb1 /mnt/sdb1

Now, create the temporary volume for further work with archives.

# mkdir /temp

Create the volume where you are going to keep the state.tgz copy just in case something goes wrong.

# mkdir /mnt/sdb1/save

Find the necessary file in the archive.

# ls -l /mnt/sda5/state.tgz

Copy the archive.

# cp /mnt/sda5/state.tgz /mnt/sdb1/save

Run the following command to double-check whether the file has been copied:

# ls -l /mnt/sdb1/save

Extract state.tgz using the cmdlet below:

# tar -xf /mnt/sda5/state.tgz –C /temp/

Find the temp file.

# ls –l /temp

Extract local.tgz.

# tar -xf /temp/local.tgz –C /temp/

Make sure that you extracted the /etc directory.

# ls –l /temp

Now, delete the local.tgz volume to ensure that it won’t be included into the new archive by accident.

# rm /temp/local.tgz

Find “shadow” in the /etc directory.

# ls -l /temp/etc

Replace the original “shadow” with the one from the host with known root password. Type the following cmdlet:

# cp /mnt/sdb1/shadow /temp/etc

Now, deploy the following command to open the file and look through the saved credentials.

# vi /temp/etc/shadow

If you do not want some users to access the host, go ahead and just remove them from the listing! Here, I removed Test from the users that can access the host. Wait, why did I delete only Test? At this point, I’d like to warn you against deleting any users you are not familiar with. In my case, all users except Test are system ones. If you delete any of those guys, you may destabilize the OS!

Here’s how the “shadow”: file looks like once the unnecessary user.

Check whether all changes have been applied.

# vi /temp/etc/shadow

Type the following line to navigate to the /temp directory.

# cd /temp

Archive the /etc directory.

# tar -czf local.tgz etc

Check whether archiving has run smoothly.

# ls -l /temp/

Now, create the state.tgz volume.

# tar -czf state.tgz local.tgz

Again, check whether the volume has been created.

# ls -l /temp/

Move the archive to the working ESXi directory.

# mv state.tgz /mnt/sda5/

Check the result one more time.

# ls -l /mnt/sda5/

Unmount the sda5 directory.

# umount /mnt/sda5

Eventually, reboot the host.

# reboot

Enjoy! If everything is done right, you can access the host with the known password. Well, to make everything more or less convenient here’s the entire set of commands I used for this method.

If the host starts acting weird after reboot, there’s still a copy of the initial state.tgz. Well, it should be. You can mount both /sda5 and /sdb1 and retrieve the original state.tgz using the following cmdlet… and try again!

# cp /mnt/sdb1/save/state.tgz /mnt/sda5/

Conclusion

Today, I discussed four ways to reset an ESXi host root password. The first method is the easiest one and works wonderful if you have vCenter installed. If there’s no vCenter, you still can reset the password, but the thing is that the last two methods described here are a bit risky. Especially, you should be really careful with the last one. If any of system users is deleted, you gonna screw up the OS. So, be smart and don’t delete users you don’t recognize.

Virtual serial ports in ESX 4.0

I’ve been trying to figure out how to get serial ports as named pipes to work out of a guest os in VMWare for a while and finally discovered the magic incantation.

Search around on the web and you’ll find all sorts examples that show you how to configure a serial port as a named pipe and then instruct you to reference the named pipe from the host’s operating system. However, despite what I tried, and despite what the official VMWare documentation said on the subject, the pipe refused to appear in the host’s filesystem.

The cause: Between ESX 3.5 and ESX 4.0 VMWare changed how the serial ports are configured and neglected to document this change. All of the existing web pages that reference this subject deal with ESX 3.5 and before.

The first piece of the puzzle, use the vSphere client to configure a new serial port as a named pipe. Select Server for the near end, and a process for the far end. The name of the pipe must be fully qualified and it must reside in either /tmp or /var. It can not reside in /vmfs. Example: /tmp/serial1

The second piece of the puzzle lay in /etc/vmware/configrules. This file, completely undocumented at the time of this writing, restricts how you can configure your guest os. The default implementation prohibits the creation of pipes in /tmp or /var. Note that this makes it impossible for serial pipe configuration to work from the vSphere client alone. In order to relax this restriction you must do the following

Comment out

# reject regex_case “^/tmp/?”

In the

rule “No System Files”

section, and add

accept prefix_case “/tmp/”

to

rule “No Files Under /usr Except Virtual Media”
rule “Virtual Serial Port Device Backend”

sections.

Restart your guest OS and after the bios has booted you should see any named pipes you’ve configured. Note that these pipes will be bound in order to /dev/ttyS0, /dev/ttyS1, etc in the guest OS.

Example: From the guest OS:

[hostname:~]$ echo foo > /dev/ttyS0
results in the following appearing on the ESX host when binding socat to the named pipe:

[root@hostname tmp]# socat /tmp/serial1 –
foo