Yellow Bricks

by Duncan Epping

esxi

ESXi and SSH, what’s next

· ·

I get a lot of questions about ESXi and SSH. Most people manage to connect to their ESXi but don’t know what to do next because there’s no actual Service Console there. Well the answer is short and simple: vim-cmd.

A couple examples of stuff you can do with vim-cmd:
enter maintenance mode: vim-cmd /hostsvc/maintenance_mode_enter

List all registered vm’s: vim-cmd /vmsvc/getallvms

Install VMware Tools for VM with ID: vim-cmd /vmsvc/tools.install [vmid]

Power on a specific VM: vim-cmd /vmsvc/power.on [vmid]

So check out the link above and start trying out this poweful command

ESXi ssh and non-root users

· ·

I’ve never seen this before. I wrote an article about root SSH access to a ESXi system. Today I noticed a blog entry that describes how you can disable root access for SSH and create users which can use “su” to become root! Cool stuff.

Check the article here! Here’s the procedure:

Log in to the console,
edit the inetd.conf:

vi /etc/inetd.conf

search for the following line (type: “/ssh”) (This is the line you uncommented to enable SSH in the first place.)

ssh stream tcp nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i

add -w to the end of this line: (type: “i” for insert mode):

ssh stream tcp nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -w

Exit and save the file (press escape, type “: x”)
Create a /home directory

mkdir /home

Create a new unprivileged user:

useradd your_name

Change the password for this user:

passwd your_name

Reboot the server

reboot

Once rebooted,
Log in with SSH using your new unprivileged user
Use

su –

to change to the root user.
Tested on:
VMware ESXi 3.5.0_Update_2-103909

Starting VM’s problem with 3.5 U2

· ·

As everyone probably already knows by now there’s a problem with 3.5 U2.  VMware is working on a patch as we speak. There has been a KB article released, but it seems like everyone is clicking on the same link at the same moment cause it’s hard to get a decent respond.

The error message that appears:

This product has expired. Be sure that your host machine’s date and time are set correctly.
There is a more recent version available at the VMware web site: http://www.vmware.com/info?id=4.
————–
Module License Power on failed

In short, the workaround is simple just set the date back and you will be able to power on the VM’s again, it would be smart to set the time to correct value again as soon as you started the VM. As soon as I know more about the new 3.5 U2 update I’ll let you guys know!

And a nice work around from the VMTN forum:

Find the host where a VM is located
run ‘ vmware-cmd -l ‘ to list the vms.
issue the commands:
service ntpd stop
date -s 08/01/2008
vmware-cmd /vmfs/volumes/vm path/vmname.vmx start
service ntpd start

HOWTO: ESXi and SSH

· ·

I’ve noticed many of the hits on my blog are related to ESXi. One of the most asked questions is how can I SSH to an ESXi hosts? Looking at my wordpress stats, this is also one of the top searches.

By default this isn’t possible. But there’s a way to get this working, just do the following:

  1. Go to the ESXi console and press alt+F1
  2. Type: unsupported
  3. Enter the root password(No prompt, typing is blindly)
  4. At the prompt type “vi /etc/inetd.conf”
  5. Look for the line that starts with “#ssh” (you can search with pressing “/”)
  6. Remove the “#” (press the “x” if the cursor is on the character)
  7. Save “/etc/inetd.conf” by typing “:wq!”
  8. Restart the management service “/sbin/services.sh restart”

Done!

HA configuration and incompatible networks

· ·

There seems to be a lot of fuss about HA not being reconfigured when Update 2 is installed.

The error message that appears:

“HA Agent on <hostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Networks: Host has network(s) that don’t exist on cluster members: <ip address>: Cluster has network(s) missing on host: <ip address>: Consider using Advanced Cluster Settings das.allowNetwork to control network usage”

Pre-Update 2 environments would except incompatible networks between hosts in a cluster and just install/reconfigure. As of Update 2 this clearly isn’t the case any more, there are a couple of misunderstandings that I want to clear up:

If you have redundant service consoles set up they don’t need to be on the same subnet. (Better said, they should not be on the same subnet because of a bug described in this blog!) But they do need to be the same on every host. In other words you can’t mix up subnets, this will not work:

Host A – Service Console – 192.168.1.10
Host B – Service Console – 10.0.0.10

In this case you will need to change the IP-Address of Host B. Or add an additional Service Console named “Service Console HA” to both and filter out the first. You can filter out the first by setting the Service Console used for HA to a specific portgroup:

das.allowNetwork0 “Service Console HA”

For more info read this topic and especially the reply that msevigny posted. The knowledge base article Marc points out to in his post is an internal one, as soon as it’s officially released I will let you guys know.