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-snmp
  • vifs
  • vicfg-user
  • vicfg-cfgbackup
  • vihostupdate
  • vmkfstools
  • esxcli
  • vicfg-ipsec

If you want to run these commands against an ESXi system, turn off lockdown mode using the vSphere Client.

About Brian

Brian is a Technical Architect for a VMware partner 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 for 2012 & 2011. VCP3, VCP5, VCA-DT, VCP5-DT, Cisco UCS Design

• Mail
|
• Web
|
• Twitter
|
• LinkedIn
|
• More Posts (189)

The release also adds support for mixed chargeback models. VKernel Chargeback 2.0 now supports both allocated and actual resource consumption models. By reporting on both measures, infrastructure teams can chargeback for actual resource consumption, allocated resources, or simply show application teams the difference in real dollars between their allocated capacity and actual usage. This cost visibility is critical to capacity management, reducing VM spral and supporting private cloud initiatives.

About Brian

Brian is a Technical Architect for a VMware partner 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 for 2012 & 2011. VCP3, VCP5, VCA-DT, VCP5-DT, Cisco UCS Design

• Mail
|
• Web
|
• Twitter
|
• LinkedIn
|
• More Posts (189)

With this weeks release of vSphere 4.1 from VMware the operating system requirements have been raised to 64 bit. What this means is that all management consoles and related tools have moved or will be moving soon to 64 bit only systems. Most importantly is that vCenter server 4.1 is now dependent on a 64 bit OS to run. This means that before you rush to upgrade you will need to make sure if your running on a physical server that it is 64 bit capable. If not then you will require a new server or you could elect to move it to a 64 bit virtual machine.

Currently only the operating systems listed below are the only 64 bit options support by the new vCenter 4.1 server.

Something new with this release is the vCenter Server Data Migration Tool. This new tool will help to migrate some of your data and settings over to a new server depending on what your configuration was. There are some very rigid rules on what it will and wont move across. The list below is the only options that it will migrate. Judging from that list every production setup I’ve ever seen is going to require the usual manual steps to be done. Since I don’t think anyone out there is using SQL express as their DB in anything other than maybe a small lab environment. Your gonna need to configure 64 bit DSN’s for your vCenter and Update Manger Databases on the new server yourself.

You can use the vCenter Data Migration Tool to automatically migrate the following to a new server:

• vCenter Server Software and its configuration
• vCenter Update Manager Software and its configuration
• VMware Orchestrator Software and its configuration
• The default SQL Express 2005 database that comes installed with vCenter Server.

To see the full details from VMware on this process refer to this article.

About Brian

Brian is a Technical Architect for a VMware partner 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 for 2012 & 2011. VCP3, VCP5, VCA-DT, VCP5-DT, Cisco UCS Design

• Mail
|
• Web
|
• Twitter
|
• LinkedIn
|
• More Posts (189)

With the release updates last night its clear that VMware continues to move its management applications into the 64bit area. With vCenter 4.1 and SRM 4.1 updates now requiring 64bit operating systems its clear that VMware is moving in this direction for everything. While this is a good move for the enterprise there are going to be a lot of Home Labs that will need to be upgraded before they can run these new releases. I know that its time for me to get some upgraded servers for my home lab as most will run vSphere but do not allow me to run 64bit virtual machines.

A quote from the SRM 4.1 release notes

SRM 4.1 server software can be installed only on 64-bit host platforms. The SRM 4.1 server is incompatible with 32-bit hosts. The SRM 4.1 client plug-in remains compatible with 32-bit hosts. Regardless of the database server you are using, you must install a 32-bit database client (ODBC driver) on the SRM server host. The SRM server is not compatible with 64-bit database clients.

About Brian

Brian is a Technical Architect for a VMware partner 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 for 2012 & 2011. VCP3, VCP5, VCA-DT, VCP5-DT, Cisco UCS Design

• Mail
|
• Web
|
• Twitter
|
• LinkedIn
|
• More Posts (189)

With the Big news that broke late last night and early this morning that vSphere 4.1 was released and available for down. Many of my fellow bloggers have written articles about the great new features that are included with this release. I am going to just offer a summary of some of the high points of the release that I find as the biggest impact. I was not part of the Beta testing for this release so I am just not getting to play with this version. The group of Beta testers have been enjoying and playing with the latest features for sometime now and thats why there has been a sudden explosion of articles that people have been holding until the official realease of the product.

• Scripted Install for ESXi. Scripted installation of ESXi to local and remote disks allows rapid deployment of ESXi to many machines. You can start the scripted installation with a CD-ROM drive or over the network by using PXE booting. You cannot use scripted installation to install ESXi to a USB device.
• vSphere Client Removal from ESX/ESXi Builds. For ESX and ESXi, the vSphere Client is available for download from the VMware Web site. It is no longer packaged with builds of ESX and ESXi. After installing ESX and ESXi, users are directed to the download page on the VMware Web site to get the compatible vSphere Client for that release. The vSphere Client is still packaged with builds of vCenter Server.

• Boot from SAN. vSphere 4.1 enables ESXi boot from SAN (BFN). iSCSI, FCoE, and Fibre Channel boot are supported. Refer to the Hardware Compatibility Guide for the latest list of NICs and Converged Adapters that are supported with iSCSI boot.
• Hardware Acceleration with vStorage APIs for Array Integration (VAAI). ESX can offload specific storage operations to compliant storage hardware. With storage hardware assistance, ESX performs these operations faster and consumes less CPU, memory, and storage fabric bandwidth.
• Storage Performance Statistics. vSphere 4.1 offers enhanced visibility into storage throughput and latency of hosts and virtual machines, and aids in troubleshooting storage performance issues. NFS statistics are now available in vCenter Server performance charts, as well as esxtop. New VMDK and datastore statistics are included. All statistics are available through the vSphere SDK.
• Storage I/O Control. This feature provides quality-of-service capabilities for storage I/O in the form of I/O shares and limits that are enforced across all virtual machines accessing a datastore, regardless of which host they are running on. Using Storage I/O Control, vSphere administrators can ensure that the most important virtual machines get adequate I/O resources even in times of congestion.
• Network I/O Control. Traffic-management controls allow flexible partitioning of physical NIC bandwidth between different traffic types, including virtual machine, vMotion, FT, and IP storage traffic (vNetwork Distributed Switch only).
• Lockdown Mode Enhancements. VMware ESXi 4.1 lockdown mode allows the administrator to tightly restrict access to the ESXi Direct Console User Interface (DCUI) and Tech Support Mode (TSM). When lockdown mode is enabled, DCUI access is restricted to the root user, while access to Tech Support Mode is completely disabled for all users. With lockdown mode enabled, access to the host for management or monitoring using CIM is possible only through vCenter Server. Direct access to the host using the vSphere Client is not permitted.
• Improved Support for Handling Recalled Patches in vCenter Update Manager. Update Manager 4.1 immediately sends critical notifications about recalled ESX and related patches. In addition, Update Manager prevents you from installing a recalled patch that you might have already downloaded. This feature also helps you identify hosts where recalled patches might already be installed.
• ESX/ESXi Active Directory Integration. Integration with Microsoft Active Directory allows seamless user authentication for ESX/ESXi. You can maintain users and groups in Active Directory for centralized user management and you can assign privileges to users or groups on ESX/ESXi hosts. In vSphere 4.1, integration with Active Directory allows you to roll out permission rules to hosts by using Host Profiles.
• Memory Compression. Compressed memory is a new level of the memory hierarchy, between RAM and disk. Slower than memory, but much faster than disk, compressed memory improves the performance of virtual machines when memory is under contention, because less virtual memory is swapped to disk.

You can see the full feature list on the VMware page, the list is pretty long.

About Brian

Brian is a Technical Architect for a VMware partner 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 for 2012 & 2011. VCP3, VCP5, VCA-DT, VCP5-DT, Cisco UCS Design

• Mail
|
• Web
|
• Twitter
|
• LinkedIn
|
• More Posts (189)

With more talk about Storage IO Control (SIOC) each month, VMware is starting to leak more details about the feature. The best write up on the feature was by Scott Drummonds last month that you can read here.  With SIOC you will be able to have almost a quality of service for VM’s in regards to storage IO control. With a very simple setup showcased in the video below you can level the playing field so that something happening in one virtual machine does not monopolize all of the storage bandwidth and starve other machines.

A few things to keep in mind for now. That SIOC is enabled per datastore, does not have a reservation limit at this time, only enforces limits when a threshold is reached and can enforce limits for IOPS when specified at the VM level.  Thanks to Duncan for these details.

In the images below you can get an idea of how Storage IO Control is working along with Shares applied to Virtual Machines to stop any VM from hogging all of the IO.

About Brian

Brian is a Technical Architect for a VMware partner 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 for 2012 & 2011. VCP3, VCP5, VCA-DT, VCP5-DT, Cisco UCS Design

• Mail
|
• Web
|
• Twitter
|
• LinkedIn
|
• More Posts (189)