Chicago VMware VMUG recap and notes

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.

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

Read More

Different ways to enable Tech Support Mode TSM on ESXi 4.1

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):
  1. At the DCUI of the ESXi host, press F2 and provide credentials when prompted.
  2. Scroll to Troubleshooting Options, and press Enter.
  3. 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.

  4. Optionally, if you want to configure the timeout for TSM:
    1. Select Modify Tech Support timeout and press Enter.
    2. Enter the desired timeout value in minutes and press Enter.
  5. Press Esc three times to return to the main DCUI screen.
To enable local or remote TSM from the vSphere Client:
  1. Select the host and click the Configuration tab.
  2. Click Security profile > Properties.
  3. Click Local Tech Support or Remote Tech Support (SSH) and click Options.
  4. Choose the desired startup policy and click Start, then click OK.
  5. 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:
  1. Select the host and click the Configuration tab.
  2. Click Advanced Settings.
  3. Change the UserVars.TSMTimeOut field to the desired value in minutes.
  4. Click OK.
To access the local TSM:
  1. At the main DCUI screen, press ALT+F1 simultaneously. This opens a virtual console window to the host.
  2. Provide credentials when prompted.

    Note: When typing the password, characters are not displayed on the console.

To access the remote TSM:
  1. Open an SSH client.
  2. 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.
  3. Provide credentials when prompted.

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

Read More

Location of VMware log files for ESX, ESXi, SRM and vCenter

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

You can see ESX logs:  (KB Link)
  • 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.
VMware ESXi log files – (KB Article)
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)
SRM log files – (KB Article)
The SRM configuration files are located at:
  • C:Program FilesVMwareVMware Site Recovery Managerconfigextension.xml
  • C:Program FilesVMwareVMware Site Recovery Managerconfigvmware-dr.xmlOr
  • C:Program FilesVMwareVMware vCenter Site Recovery Managerconfigextension.xml
  • C:Program FilesVMwareVMware vCenter Site Recovery Managerconfigvmware-dr.xml

The SRM Logs (on vCenter Server for connection with SRM and on SRM for SRM workflow) are located at:

  • %ALLUSERSPROFILE%VMwareVMware Site Recovery ManagerLogs, which translates by default to C:Documents and SettingsAll UsersApplication DataVMwareVMware Site Recovery ManagerLogsOr
  • %ALLUSERSPROFILE%VMwareVMware vCenter Site Recovery ManagerLogs, which translates by default to C:Documents and SettingsAll UsersApplication DataVMwareVMware vCenter Site Recovery ManagerLogs
The SRM Installation Logs (on the SRM Server, which may not be the vCenter Server) are located at C:Documents and SettingsAdministratorLocal SettingsTemp1.
The location of the SRA Logs (on the SRM server) depends on the SRA type and vendor. They may be located in:
  • C:Program FilesVMwareVMware vCenter Site Recovery ManagerscriptsSAN*logOr
  • C:Program Files<SRA Vendor or Name>

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

Read More
Page 4 of 41234