ESX Tips – ESXi Console II

Accessing the ESXi console
Thanks to http://www.run-virtual.com/?p=223
updated 04 Sept 08

ESXi has a busybox console build into it for troubleshooting purpose.  To enable it, press Alt-F11(for update 2 press ALT-F1) at the welcome screen and type "unsupported" without the "".

Congratulations, you now have access to ESXi console.  But we’ll need to enable SSH for accessing the console remotely.  Here we’ll need to edit inetd.conf and removed the # infront and restart inetd.

—————————————————————————————————-
Tech Support Mode successfully accessed.
The time and date of this access have been sent to the system logs.

WARNING – Tech Support Mode is not supported unless used in
consultation with VMware Tech Support.

~ #vi /etc/inetd.conf
—————————————————————————————————-

Find this line below and remove the # in front.  Then save exit Vim editor.
#ssh     stream  tcp     nowait  root    /sbin/dropbearmulti     dropbear ++min=0,swap,group=shell -i <– This line remove the leading #

Find and kill inetd service and restart it.
~ # ps |grep inetd
1705 1705 busybox              inetd
#kill -9 1705
#inetd

ESXi server is now ready to accept remote connections.  Do bear in mind that there is no firewall settings in the VI console as such, if security is a concern to you, you’ll need to disable ssh after use via the physical console.


ESX Tips – ESXi Console I

Lesson of the Day 29th May 08

Lost access to your ESX Server?
Never place more then one vmkernel within the same subnet.  It will cause you to lose connection to your remote console at just one wrong click at the gateway setting. (applies to all ESX builds)

If that happens, restarting the server wouldn’t help and updating IP from Physical ESXi SP1 console would not bring it back either.

Solution
You’ll need to remember the IP address of the new vmkernel network which you’ve just created as VMware console has now binded to that new IP.  Try to connect to the console using that new IP; make sure you have access to that subnet its running on.


ESX Network Performance Journey Takes I

20th May 2008, Tues 10am

"Despite the VMware ESX features page claim that NIC teaming provides load balancing, basic NIC teaming only provides outbound load balancing. To get inbound load balancing with NIC teaming, however, you must go the extra step and configure VLAN trunking and the port channel on the Ethernet switch to which these VMware ESX Server physical adapters are connected"
David Davis
http://searchvmware.techtarget.com/tip/0,289483,sid179_gci1311518,00.html

Another one of the sales/marketing crap we as consumer face everyday.  They’ll have thousand and one reasons to convince you that their product is the best of breed just to get money out of your pocket.

What the heck since we’re already on the boat, lets start sailing.  Slowe had made a good start in this exploration with his hands on experience at his fantastic site below.
http://blog.scottlowe.org/2006/12/04/esx-server-nic-teaming-and-vlan-trunking/

I’m dealing with nearly the same situation over here but with ESX connected to two Cisco 4506 which are supposed to failover to each other.  With NO experience with load-balancing, I have totally no clue what I’m going to face during this recklessly planned mission to test it on production environment.

But performance is our mission, heros will have to take some risks to accomplish the task; without the lady in red.

Lets stir some water

#show etherchannel load-balance
EtherChannel Load-Balancing Operational State (src-dst-ip):
Non-IP: Source XOR Destination MAC address
  IPv4: Source XOR Destination IP address
  IPv6: Source XOR Destination IP address

Crap, don’t have a clue what that means.  Best guess is that there might be a chance ESX NIC load-balancing will work without adjusting load-balance method in the production Cisco switch.  That, we wouldn’t know until we’ve setup the ESX for testing.

Back to drawing board.  Me need to read up more before i proceed from here.   Till next time ….


How secure is your network I

I was just browsing through some security sites and accidentally ran into some hacking sites instead. Sometimes ignorance is just not bliss.

http://www.airscanner.com – has some very interesting articles on network vulnerabilities all the way from ARP poisoning to WIFI hacking.  I’m sure you wouldn’t want to have a free port open in your cisco switch after this.