Posted by Brian on Jul 29, 2010 in CLI, vCenter Server, VMware, vSphere | 0 comments
Now that vSphere 4.1 has been out for a couple of weeks you’ve probably had some time to play with it in a lab. I’m sure you have also spent some time reading the release notes getting up to speed on the large list of new features that were released. After spending time myself getting familiar with many of the new options I wanted to dig in and see what was new with the Command Line Interface in 4.1. Since this is going to play a big part in how you will be managing ESXi hosts once you move your environment over to the platform of the future.
I have grabbed a list of the new commands added to vCLI 4.1, these command will help narrow the gap that had existed between what you could run on the ESX console (COS) and what you could do via the vCLI with an ESXi host. Notice the part at the end where it lists some of the commands that cannot be executed against a vCenter server for a host in lock down mode.
vicfg-hostops – Allows you to examine, stop, and reboot hosts and to instruct hosts to enter and exit maintenance mode.vicfg-authconfig – Allows you to add an ESX/ESXi host to an Active Directory domain, remove the host, and list Active Directory domain information.vicfg-ipsec – Supports IPsec setup.
vSphere CLI 4.1 also includes the following new functionality:
- The following options have been added to
esxcli:
esxcli swiscsi session – Manage iSCSI sessions.esxcli swiscsi nic – Manage iSCSI network interfaces.esxcli swiscsi vmknic – List VMkernel network interfaces available for binding to particular iSCSI adapter.esxcli swiscsi vmnic – List available uplink adapters for use with a specified iSCSI adapter.esxcli vaai device – Display information about devices claimed by the VMware VAAI (vStorage APIs for Array Integration) Filter Plugin.esxcli corestorage – List devices or plugins. Used in conjunction with hardware acceleration.esxcli network – List active connections or list active ARP table entries.esxcli vms – List and forcibly stop virtual machines that do not respond to normal stop operations.
- Some of the parity issues between vSphere CLI and the ESX service console have been resolved.
- You can now run vCLI commands using SSPI (
--passthroughauth) against both vCenter Server and ESX/ESXi systems.
- Lockdown mode allows vSphere administrators to block direct access to ESXi systems. With lockdown mode enabled, all operations must go through a vCenter Server system. The following commands cannot run against vCenter Server systems and can therefore not be used in lockdown mode:
vicfg-snmpvifsvicfg-uservicfg-cfgbackupvihostupdatevmkfstoolsesxclivicfg-ipsec
If you want to run these commands against an ESXi system, turn off lockdown mode using the vSphere Client.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (170)
Posted by Brian on Jul 29, 2010 in VMware, vSphere | 2 comments
Sure this nothing earth shattering but it’s just something simple that can make your life easier. With a web browser and some links that I will provide below you can view some of the vSphere configuration files and messages from logs. This is probably the fastest way to get a view into your host with out having to SSH into the server or use another method. This method works for both vSphere 4.0 and 4.1 hosts and it works on both ESX and ESXi hosts.
You can view the VMware vSphere Configuration files from a browser using a link formatted like the following. https://hostname/host From that link you will need to authenticate to your host and then will be able to view a list of files from the host. In the list of files presented with be configuration files and some logs.
There is another page viewable with a web browser that will show you log messages from your ESX or ESXi host. Use the following syntax for the link. https://hostname/host/messages
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (170)
Posted by Brian on Jul 28, 2010 in VMUG | 2 comments
I would like to say a Big Thanks to everyone that attended today and a special thanks to our sponsor Compellent. Compellent gave a nice presentation about their technology and what they have accomplished in their 5 years since they released the first product. I will give a short break down of the different presentations today and if we are able to get the slide decks from the presenters we will publish them over on the Chicago VMUG blog.
In our first presentation of the day Chris Fox of VMware was in and gave an overview of the new features of vSphere 4.1. There were discussions about SIOC (Storage IO Control), NIOC (Network IO Control), VAAI the API’s for array integration were some of the most talked about features. It was also discussed that VMware ESX 4.1 classic will be the last release of the ESX flavor of Hypervisor. Sometime in 2011 there is expected to be the next major release of vSphere and it will only be available in ESXi flavor.
In the second session of the day Russ Taddiken of Compellent talked to us about their storage virtualization technology. Russ gave a presentation that explained many of the features that make Compellent a strong competitor in the storage market. He spoke about Storage Auto Tiering that has been a feature in their product for about 5 years. Some of the other points that stood out to me was CoPilot their support organization and the Portable Volume feature. With portable volume it allows for the initial data replication to be placed on an encrypted USB disk that can be shipped to a remote site that might have a slow link. You will then only have to replicate the changes rather then the entire amount. Russ also mentioned that Compellent will be in the 2nd round of Vendors that will be supporting VMware VAAI API for storage functions.
In the last session of the day Mark from VMware spent time to talk about migrating your ESX infrastructure to ESXi. He covered the different ways to convert your hosts over to VMware ESXi. There was discussion around some of the reasons for the VMware’s decision to move in the ESXi direction. An estimated 80% of patches that VMware released for the ESX classic version were related to the console (COS) due to it’s Linux base that it was built on. With ESXi the COS was removed and the amount of patching required is greatly reduced. VMware is also working in the direction of building the ability to have a stateless hypervisor. Mark spent some time showing some of the commands that are the vCLI versions of the console commands that many are used to using.
We had a pretty nice showing for this meeting and hope that our community continues to grow. We had a couple of higher profile members from the VMware community show up to the meeting. David Davis from Train Signal was in attendance at the meeting. David has created a large number for training videos from Train Signal as well as for his blog VMwareVideos.com. Thanks again to David and the Train Signal team for providing several copies of their VMware vSphere training videos that we were able to give away to our members. Also in attendance today was Justin Lauer of EMC and a vSpecialist from Chad Sakac’s vArmy Team. I’ve knowing Justin for a bit now and it’s always great to chat with him, his involvement in our VMUG community will help many.
Update: We have posted a few of the slide decks from the presentations today here.
Took a couple of quick photos with an iPhone today as I forgot my camera but will do a better job in the future.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (170)
Posted by Brian on Jul 14, 2010 in VMware, vSphere | 3 comments
For anyone that has been running or played with ESXi in the previous versions you should have a good idea of what Tech Support Mode is. The Tech Support Mode or TSM is a sort of simple version of the system console that was available on the classic versions of ESX. Except that the TSM mode is not Linux based and does not have all the capabilities that the old COS had. But you can now access Tech Support Mode locally or via SSH if you follow the instructions below to enable them. I have become very comfortable with the old console access and that’s probably my biggest complaint about having to use ESXi. I’ve been playing around with the vMA or virtual management appliance that can be used to remotely manage ESXi hosts in the lab but its just not the same. I guess it will become second nature the more that I use it since classic ESX will no longer be offered in ESX 5.0 when it is released in the future.
To enable local or remote TSM from the Direct Console User Interface (DCUI):
- At the DCUI of the ESXi host, press F2 and provide credentials when prompted.
- Scroll to Troubleshooting Options, and press Enter.
- If you want to enable local TSM, select Local Tech Support and press Enter once. This allows users to login on the virtual console of the ESXi host.
If you want to enable remote TSM, select Remote Tech Support (SSH) and press Enter once. This allows users to login via SSH on the virtual console of the ESXi host.
- Optionally, if you want to configure the timeout for TSM:
-
- Select Modify Tech Support timeout and press Enter.
- Enter the desired timeout value in minutes and press Enter.
- Press Esc three times to return to the main DCUI screen.
To enable local or remote TSM from the vSphere Client:
- Select the host and click the Configuration tab.
- Click Security profile > Properties.
- Click Local Tech Support or Remote Tech Support (SSH) and click Options.
- Choose the desired startup policy and click Start, then click OK.
- Verify that the daemon selected in step 3 shows as running in the Services Properties window.
To configure the TSM timeout value using the vSphere Client:
- Select the host and click the Configuration tab.
- Click Advanced Settings.
- Change the UserVars.TSMTimeOut field to the desired value in minutes.
- Click OK.
To access the local TSM:
- At the main DCUI screen, press ALT+F1 simultaneously. This opens a virtual console window to the host.
- Provide credentials when prompted.
Note: When typing the password, characters are not displayed on the console.
To access the remote TSM:
- Open an SSH client.
- Specify the IP address or domain name of the ESX host.
Notes:
-
- Directions may vary depending on what SSH client you are using. For more information, consult vendor documentation and support.
- By default, SSH works on TCP port 22.
- Provide credentials when prompted.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (170)
Posted by Brian on Jun 2, 2010 in Troubleshooting, VMware | 0 comments
Whether your tracking down an issue on your own or collection data to submit a support request to VMware your gonna need to round up the necessary log files. I have collected and listed some of the main log locations from VMware and also linked to KB articles covering a full list of log file locations.
VMware ESX log files
- From the Service Console
- From the vSphere Client connected directly to the ESX host (click Home > Administration > System Logs)
- From the VMware Infrastructure Client connected directly to the ESX host (click Administration > System Logs)
The vmkernel logs (which log everything related to the kernel/core of the ESX) are located at /var/log/vmkernel.
The vmkwarning logs (which log warnings from the vmkernel) are located at /var/log/vmkwarning.
The vmksummary logs (which provide a summary of system activities such as uptime, downtime, reasons for downtime) are located at /var/log/vmksummary.
The hostd log (which is the log of the ESX management service of the ESX) are located at /var/log/vmware/hostd.log.
The messages log (which log activity on the Service Console operating system) is located at /var/log/messages.
The VirtualCenter Agent log is located at /var/log/vmware/vmware/vpx/vpxa.log.
The Automatic Availability Manager (AAM) logs are located at /var/log/vmware/aam/vmware_<hostname>-xxx.log.
The SW iSCSI logs are located at /var/log/vmkiscsid.log.
The System boot log is located at /var/log/boot-logs/sysboot.log.
The vmkernel, vmkwarning, and hostd logs are located at /var/log/messages.
The Host Management service (hostd = Host daemon) log is located at /var/log/vmware/hostd.log\.
The VirtualCenter Agent log is located at /var/log/vmware/vmware/vpx/vpxa.log.
The System boot log is located at /var/log/sysboot.log.
The Automatic Availability Manager (AAM) logs are located at /var/log/vmware/aam/vmware_<hostname>-xxx.log.
vCenter log files – (KB Article)
The SRM configuration files are located at:
- C:\Program Files\VMware\VMware Site Recovery Manager\config\extension.xml
- C:\Program Files\VMware\VMware Site Recovery Manager\config\vmware-dr.xmlOr
- C:\Program Files\VMware\VMware vCenter Site Recovery Manager\config\extension.xml
- C:\Program Files\VMware\VMware vCenter Site Recovery Manager\config\vmware-dr.xml
The SRM Logs (on vCenter Server for connection with SRM and on SRM for SRM workflow) are located at:
- %ALLUSERSPROFILE%\VMware\VMware Site Recovery Manager\Logs, which translates by default to C:\Documents and Settings\All Users\Application Data\VMware\VMware Site Recovery Manager\LogsOr
- %ALLUSERSPROFILE%\VMware\VMware vCenter Site Recovery Manager\Logs, which translates by default to C:\Documents and Settings\All Users\Application Data\VMware\VMware vCenter Site Recovery Manager\Logs
The SRM Installation Logs (on the SRM Server, which may not be the vCenter Server) are located at C:\Documents and Settings\Administrator\Local Settings\Temp\1.
The location of the SRA Logs (on the SRM server) depends on the SRA type and vendor. They may be located in:
- C:\Program Files\VMware\VMware vCenter Site Recovery Manager\scripts\SAN\*\logOr
- C:\Program Files\<SRA Vendor or Name>\
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (170)
