I'm troubleshooting an issue we have with one of our ESXi 5.1 hosts, and have run into a minor technical issue. I was monitoring the vmkernel.log file, by tailing it in a direct shell sesssion. I'm now trying to quit tail, with a control-c, and I'm getting an unknown escape sequence error from esxi. Is there a different escape sequence I need to use?
This might be to do something with the dcui session you are using. Check the keyboard controls section on the dcui interface.
Good idea, but unfortunately for me that' doesn't appear to be the issue. The keyboard mapping is set correct. I'm am connecting through through ILO, so my other thought was that perhaps ILO is intercepting ctrl-c. Thanks though,
What version of the firmware is installed on your iLO? Which type of iLO also? iLO 2, 3, 4?
I'm running ILO 3, version 1.5 (sept 2012)
Okay, and the iLO 3 firmware in the SPP 2012.10 release is still 1.5, so you're pretty current there. Don't know what's in SPP 2012.12 though.
What ProLiant server model? Guess only thing I can think of at this point is to try power cycling the iLO itself (i.e. remove all power to the server for about 30 seconds then reconnect power or rerack the blade), as I've never seen this kind of issue. I just tried to reproduce your issue on a an BL460c G7 with an iLO 3 which also has firmware 1.5 and couldn't produce that error.
Did you by chance do a "tail -f /var/log/... &" (with the ampersand at the end) to put it in the background?
It's a proliant bl685 g7. It's been having network connectivity issues with it's flex fabric that I've been dealing with, so overall it's not a very happy server. I'm chalking it up as just another odd defect with the blade (one of many unfortunately). I have a scheduled outage tonight so I can reboot it.
For the tail I did, there was no &, it's just a vanilla "tail -f /var/log/vmkernel.log"
I can confirm the behavior on another brand of server (Supermicro). Are you able to connect via SSH? If so you could just kill the process for tail.
Unfortunately no, the mgmt interface had lost connectivity. We've been experiencing issue's with nic's loosing connectivity in vsphere, though virtual connect shows them as up. It appears to be an issue with the emulex drive & firmware on some BL685G7's. I have an open case with HP regarding it, but thats a whole different story.
Thanks
NC553i FlexFabric adapter? Which firmware/driver pairing are you using?
Make sure the entire stack aligns with HP recommendations. I've also experienced odd issues when I deviated from the stack and people started trying to set the vmnic adapters to "auto negotiate" on BL680c G7 and BL460c G7 blades:
http://h20272.www2.hp.com/pages/spock2Html.aspx?htmlFile=hw_virtual_connect.html&lang=en&cc=US&hpapp... (you'll need a HP Passport ID to login and view the PDF, but it's very helpful to see the current recommended driver/firmware pairing for the FlexFabric adapter as well as what firmware versions to use for the OA and VC.)
Since the VCs control the vmnic adapter speed, I don't recommend setting any vmnic adapters to auto negotiate. You can see if any have been explicitly modified in this way by checking the /etc/vmware/esx.conf file:
Example for vmnic0:
You can remove the "auto" lines and reboot the host. Not sure if this will help with your issue, but worth a shot.
I thought I was getting this same issue. I'm using a non-HP systme (no ILO) and don't see an "unkown escape sequence error".
I found that by quickly typing control-c several times (about 10-20) it eventually works.
Hello kpcongdon
You may try ctrl+z then kill the tail process, if it not working on same session you may login to SSH and then check if it running by running command "bg" then kill the process.
I’m familiar with opening ‘virtual terminal’/alternate TTY sessions with ALT-F3 etc on Linux, but on the ESXi 5.1 host, the only options I seem to have are to use ALT-F1 for the esxi shell, or ALT-F2 for the dcui. ALT-F3 etc don't seem to do anything.
Is there something I have to configure to get more TTY sessions ? (I can SSH in and check/kill processes like you suggest, but alternate TTY sessions on the host would be preferred)