VMware Workstation 7的新特性:

• 第一款在 Windows 虚拟机中支持 Windows Aero 3D 图形的桌面虚拟化产品。

• 借助快捷安装功能，在虚拟机中安装 32 位和 64 位 Windows 7 比在物理 PC 上更轻松。

• Workstation 7 可与 Flip 3D 和 Aero Peek 结合使用，显示虚拟机的实时进度。

• 比 Windows XP Mode 更出色，可使用 3D 图形技术运行 Windows XP，性能更快捷，与 Unity 之间的集成更紧密，支持共享文件夹和简便的拖放操作。

• 经过优化，可以最大限度地发挥在 32 位和 64 位 Windows 7 PC 上运行时的性能。

•VMware Workstation 是第一款支持 3D 图形的虚拟机平台，

•现在支持更多 3D 应用程序，在 Windows 虚拟机中支持 Windows Aero、DirectX 9.0c Shader Model 3 和 OpenGL 2.1。

创建的每个虚拟机最多可拥有 4 个虚拟处理器或 4 个虚拟内核，以及最多 32 GB 内存。

• 可实现无驱动打印，这使您的 Windows 和 Linux 虚拟机可以自动访问 PC 打印机，无需任何配置或驱动程序。

• 智能卡身份验证使虚拟机可以共享对智能卡读卡器的访问，或将特定虚拟机绑定到智能卡读卡器以访问公司机密数据。

• 虚拟机现在支持 IPv6 网络

立即在虚拟机中安装和运行 VMware vSphere 4 和 ESXi。

• 借助针对 SpringSource Tools Suite 和 Eclipse IDE for C/C++ 的全新 IDE 集成，可简化软件开发和测试过程。

•借助记录回放调试改进，可以更快地查找非确定性错误。

• 借助远程调试，可以更轻松地与其他开发人员共享虚拟机记录以供分析。

• AutoProtect 按设定的间隔自动拍摄快照，帮助您防范意外事故，使您可以轻松、及时地返回正常运行状态。

• 使用 256 位 AES 加密，可保护您的虚拟机不受窥视。

• 可暂停虚拟机以释放 CPU 资源，供其他运行中的虚拟机或高要求应用程序使用。

• 可在 PC 和虚拟机之间使用拖放操作，移动格式化文本、图形和电子邮件附件变得更轻松。

• 可在 PC 和虚拟机之间复制和粘贴图形和格式化文本。

• Windows 用户将发现可以更轻松地创建虚拟网络以满足测试需求。

• 借助 ALSA 声卡支持，Linux 用户可以享受更优美的音质。

1 | 2 | 3

在了解ESX内存管理如何工作前, 需弄清以下三个定义.

• 机器内存(Machine Memory): 为ESX服务器上安装的物理内存, 由ESX Kernel管理.
• 物理内存(Physical Memory): 分配给虚拟机的内存, 在虚拟客户系统看来就是它的物理内存, 由进行管理.
• 虚拟内存(Virtual Memory): 运行客户操作系统上的应用系统看到的内存.

虚拟机内存使用

现在让我们注意内存是如何分配给客户机的. 每当应用程序需要一个内存页用于存储数据, 需要通过操作系统提交请求. 操作系统监控着哪些内存页正被使用, 哪些处于空闲的状态. 想象是两个简单的列表, 一个用于空闲内存页, 另一个用于已分配页. 因此当收到应用程序提交的请求时, 操作系统会在其空闲内存页中为应用程序指定一个内存页. 然后操作系统将此内存页从”空闲列表”移到”已分配列表”.

在ESX系统管理层(虚拟层?), 内存是按需进行分配. 当虚拟机第一次访问物理内存, 系统管理层将为虚拟机指派机器内存页. 管理程序会为每个虚拟机在保持一条从物理内存页到机器内存页(PMP-MMP)的映射记录, 因此管理程序清楚哪些内存页被使用以及在机器内存中的位置.

我们知道了如何分配内存, 但在应用程序不需要内存页时会发生什么. 在这种情况下应用程序将再次通过操作系统的一个系统调用去释放内存. 释放的内存页从”已分配列表”又移回到”空闲列表”.因为操作系统根本不清楚自己实际是虚拟机, 也没有与系统管理层(虚拟层?)交互. 虚拟层根本不知道这些内存页现在是空闲的. 所以, 系统管理程序(虚拟层?)仅仅是分配内存给虚拟机, 虽然在虚拟机操作系统里内存页不断的被分配和释放, 但是系统管理无法回收客户端释放的内存.

虚拟机摘要中包含的主机内存使用和客户机内存使用, 其中主机内存使用是分配给虚拟机的物理内存. 记住该值包含虚拟化管理(如PMP-MMP影射表)所需内存. 在一个内存使用过量的服务器上主机内存使用是基于共享的, 但客户机内存使用会被标注为高水位.(On a non-memory overcommitted host this represents a “high water mark” on the guest’s memory usage, but host memory usage is based on shares when the host is overcommitted.)

摘要中的客户机内存是客户端操作系统和活动的应用程序所需要的内存额. 并不是如前面提到的ESX系统管理层(虚拟层?)根本不知道客户端物理内存页的实际状况. 实际上该值是通过统计抽样计算得出的. 这意味着ESX系统管理层(虚拟层?)是随机的采集和监测一段时间内客户端内存和页面访问情况. 这个值与客户机总内存推算出客户机内存的使用.

上图描述了客户机内存状态. 分配给客户机的总内存, 可分配给操作系统和应用程序, 或不分配.分配的内存可处于有效或失效状态.

- 虚拟机内存分配结束 -

1. Allocated memory
该值在虚拟机属性的硬件选项卡中, 为虚拟机用到的物理内存总额, 虚拟机不能超过该限制获取更多的内存.
2. Reservations(保留)
分配虚拟机的最少内存量, 确保虚拟机可以获得的最小内存. 当该条件不能得到满足时, 将无法启动虚拟机. 就是所谓的”接入控制”. 该值在虚拟机属性的资源选项卡中设置, 默认情况下没有配置该选项.
3. Limits(限制)
该值约束虚拟机使用的内存上限.

VMkernel交换文件
当虚拟机运行需要更多内存时利用该文件将内存内容交换到磁盘以释放内存. 当设置保留后,  保留的内存将得到保护, 不会被交换到磁盘. 因此每当虚拟机启动时, VMkernel会创建一个容量为限制减去保留后大小的交换文件. 例如我们有一个虚拟机限制内存为1024M, 保留内存为512M, 则创建的交换文件大小为1024MB-512MB=512MB. 如果我们将保留内存设为1024M, 就不会创建交换文件.
请记住, 在默认情况下, 没有设置任何保留和限制, 因此为每个虚拟机创建与分配内存相同大小的交换文件.

4. Shares(份额)
份额指定虚拟机的相对优先级或重要性, 份额高的虚拟机相比份额低的虚拟机可消耗更多的资源. 不像固定的限制(Limits)和保留(Reservations), 份额(Shares)能动态改变.

记住份额系统仅在内存资源匮乏导致争用发生时发挥作用.

份额通常指定为高(High)、正常(Normal)、低(Low)或自定义值. 这些值按4:2:1比例指定份额值.
低: 1MB按5个份额分配给虚拟机.
正常: 1MB按10个份额分配给虚拟机.
高: 1MB按20个份额分配给虚拟机.

例: 我们有5个虚拟机, 各分配2,000M内存, 份额值设为”Normal”. ESX服务器只有4,000MB物理内存可用于虚拟机. 这里每个虚拟机可得到20,000个份额(10*2,000), 所有虚拟机共计份额为100,000(20,000*5), 这里每个虚拟机将获得同等的资源20,000/100,000=1/5现有的资源=4,000/5=800MB.
现在我们改变1号虚拟机的份额为”High”, 1号虚拟机将获得40,000个份额(20*2,000), 因此1号虚拟机得到的资源为40,000/120,000=1/3现有的资源=4,000/3=1,333MB, 其他四个虚拟机得到资源为20,000/120,000=1/6现有的资源=4000/6=666MB

我们可配置资源池以代替基于一个虚拟机的这些设置, ESX资源池共用CPU和内存资源.

- 虚拟机的内存设置结束 -

Cormac Hogan
Product Support Engineering
January 2009

FalconStor provide a very easy method for deploying their NSS Virtual Appliance (VA). The download is in the form of an ISO image which contains an installation script. When this script is run, the script prompts you for a datastore on which to place the VA. Once the script completes, you will have a Virtual Machine called FalconStor-NSSVA.

More information and eval copies of the NSS VA can be found at http://www.falconstor.com.

Requirements:

• 2 IP addresses (static or DHCP allocated)
• 2 vCPUs
• 1GB Memory
• 3GB of disk space for the OS
• Additional disk space for LUN presentation and snapshots
• FalconStor IPStor Management Console

This guide is split into 5 parts:

• Part 1: Configuring the FalconStor NSS Virtual Appliance
• Part 2: Configuring the ESX to use FalconStor NSS VA Storage
• Part 3: Configure Replciation on the NSS VAs.
• Part 4: Install the FalconStor Storage Replication Adapter
• Part 5: Configure the SRA & Test SRM Functionality

Part 1: Configuring the NSS VA
Section 1: Configure the NSS VA network

Once the NSS VA is deployed, open a console session. Login as root (the default password is IPStor101). This should automatically launch the setup menu. If not, at the command line, run the command vaconfig. This will launch the setup menu.

Here you can setup hostname, time zone, root password, network configuration, gateway, DNS & NTP. Once complete, tab to finish and hit enter.

Section 2: Configure the NSS VA storage

Our next step is to configure the NSS VA with additional storage so that can be used for LUN presentation by the appliance. This is quite straight forward as all we have to do is assign additional virtual disks to the appliance.

In this example I have created two additional virtual disks. Later on, we will see that one of these is used by the NSS VA to present a LUN and the other disk is used for holding my snapshots. Of course, I could have added a single virtual disk and used it to manage both the LUN presentation and snapshot holding area.

One thing that you will notice here is that there is a new SCSI controller. The virtual disks that we wish the appliance to use as storage entities must be placed on a different controller. This is easily achieved by giving the new virtual disks a target id of 1 rather than 0. This will automatically create a new (LSI Logic) SCSI controller. However the appliance must be powered off in order to do this configuration. Do the same for both the primary and secondary NSS VAs.

Section 3: Configure the NSS VA iSCSI target

In order to configure the iSCSI target on the NSS VA, we need to use the FalconStor IPStor Console. Once installed, this can be used to manage multiple virtual appliances.

Here is the main screen of the console after installation:

Step 1: Right click on the IPStor Servers icon and select Add to add individual IPStor Servers. Alternatively, right click on the IPStor Servers icon and select Discover to discover all IPStor servers on a particular subnet:

Add:

Discover:

Step 2: In this example, I have successfully discovered two NSS VAs. The first is on my primary/protected site; the second is on my target, recovery site. You will need to authenticate against each NSS VA in order for it to expand its properties as shown below:

Step 3: Now I need to ensure that one of the devices that I added as an additional virtual disk to this appliance are configured for use as a LUN that can be presented to the outside world. To do that, I must first assign this new storage for use as a LUN which can be presented to the outside world. Typically, once you authenticate against the NSS VA via the IPStor Console, you will receive a pop-up window stating that a LUN is ready for use. Note that these storage configuration steps are only necessary on the primary/protected site – these steps are not necessary on the target/recovery site.

Notice that the category is currently Unassigned. The first thing we must do is to click on the Prepare Disk button.

If you do not see the disk that you just added to the NSS VA, you should be able to rescan the adapter to pick up the new disk. On the IPStor Console under Physical Adapters right click on SCSI Adapter.0 and perform a rescan. This should rescan the scsi bus of the VM and pick up the new storage you have added.

Step 4: Change Device Category from Unassigned to Reserved for Virtual Device.

Click OK, and at the next prompt type the word YES in upper case to confirm the action.

Click OK. The device is now assigned to the category Reserved for Virtual Device.

Step 5: Next, click on the Create SAN Resource button. Alternatively, for future reference, navigate to Logical Resources, then SAN Resources, right click and select New. Either of these steps will launch the following wizard.

Click Next:

Ensure that the SAN Resource Type is set to Virtual Device. Click Next.

Select the disk that you wish to use as a SAN resource. The disk that I just added was id 2 and was 8GB in size so I will select the second disk. As an fyi, the other disk shown here is another 8 GB virtual disk of which 20% is used for holding my snapshots. We will see more about this later. Click Next.

Leave this at Express (default). Also leave the size to allocate at the maximum value as we use the whole disk. Click Next.

Select a name for the SAN Resource. You can also leave this at the default name allocated by the IPStor Console. In this case the name is SANDisk-0003. Click Next. At the final window, you will be displayed the details on the SAN Resource. Simply click Finish.

Step 6: After you have successfully created a SAN Resource, you are prompted to add clients to it. Alternatively, for future reference, navigate to Logical Resource, then SAN Resources, select the disk, right click and select Assign. For SRM, our clients will be our ESX server of course. The pop-up looks like this:

Click No as we have not yet created an iSCSI target on the NSS VA. If you had already created an iSCSI target, you could click Yes.

Step 7: To create an iSCSI target, navigate to SAN Clients, right click and select Add. This launches the following wizard:

Step 8: Click Next:

Step 9: Check the iSCSI tick box as shown above and click Next.

Step 10: Select which IP address that you are going to use for iSCSI connectivity. Choose whichever one is not used for management purposes. This will be the IP address that you will add to the targets of the ESX server’s iSCSI initiator. Click Next.

The next window lists the initiators that the NSS VA already knows about. Here we can see an initiator from an ESX server already listed. If the iSCSI initiator from your ESX server does not appear in the list, then you will have to manually add it by clicking the Add button. Here I just check the tick box against the initiator that I want to present this LUN (SAN Resource) to.

Step 11: Click Next.

Step 12: By default, this window will appear with the option to set CHAP authentication. Click the radio button which states Allow unauthenticated access as shown above. We are not going to worry about CHAP here. Click Next.

The next screen is QoS (Quality of Service).

Step 13: This can be left at the default value of Medium. Click Next.

The next screen allows us to configure client information.

Step 14: Note that an IP address is not required if the client name is resolvable. Also note that this is the IP address of the ESX host’s VMkernel iSCSI interface, not Service Console interface. Finally note that I chose client type as Linux. Click Next.

Step 15: Uncheck Enable Persistent Reservation & click Next.

This final screen displays an overview of the configuration of the client.

Step 16: Click Finish. You should now observe a new SAN Client.

Step 17: We saw earlier that when we successfully created a SAN Resource, we were prompted to add clients to it. At that time we did not have a client defined but now we do. To assign a client to a SAN resource now, navigate to Logical Resource, then SAN Resources, select the disk, right click and select Assign. This will launch a new wizard:

Step 18: Click Next.

Step 19: Select the check box against the iSCSI Target Name and click Next.

Step 20: This screen allows you to change the presentation LUN id. We can leave this at the default of LUN id 0. Click Next.

Step 21: Click Finish. This assigns the LUN to the client.

Step 22: Right Click on the disk (SAN Resource) , go to TimeMark/CDP and select Enable. TimeMarks are point in time images of any SAN or NAS virtual drive.

This launches the following wizard.

Step 23: Many of the screens that follow are related to the how often you should take snapshots. The settings here are related to a customer’s own environment. In most of the following screens I have chosen the default. However, these values may not be ideal for your customer’s environment and ideally the customer should discuss these settings with FalconStor to make sure that they meet their needs.

Step 24: For the purposes of my demo configuration, I left Enable CDP unchecked.

Step 25: In the schedule I set the initial snapshot to be at 09:30am on Jan 6^th, and then every hour after that, keeping a maximum of 8 snapshots (timemarks).

Step 26: Click Finish to complete setting up the timemark. The NSS VA is now configured and we should be in a position to discover this LUN from the ESX server.

Part 2: Configuring the ESX to use storage from the NSS VA

Step 1: In the dynamic discovery section of the iSCSI initiator on the ESX, add the IP address of the NSS VA iSCSI interface.

Step 2: Rescan the SAN and discover the FalconsTor NSS VA LUN.

Step 3: Build a VMFS on it.

Step 4: Place a virtual machine on the VMFS.

Now that we have a running VM on this volume, we can replicate it to the other NSS VA.

Part 3 – Configure Replication on the NSS VAs

Step 1: Return to the FalconStor IPStor Console. Connect to both the NSS virtual appliances.

Step 2: On the primary/protected NSS VA, navigate to Replication then Outgoing, right click on Outgoing and select Enable SAN Resources to enable replication on SAN Resources. This opens the following wizard. Click Next.

Step 3: Select the disk to replicate.

Notice that I already have a predefined snapshot resource for SANDisk-0002 but none for SANDisk-0003. This means is that I have a location to store my snapshots. The next screen will prompt me for a location as I have chose SANDisk-0003 which has no snapshot resource created.

Step 4: This disk is already used for storing snapshot resources for SANDisk-0002. I will now use it for storing snapshot resources for SAN Disk-0003 also. If you have not got any free space, you will need to allocate a new virtual disk from the ESX to the NSS VA and use that as a location for storing snapshots.

Step 5: This screen asks you how much space to dedicate on this disk for snapshots. The default is 20%. Click Next.

Many of the screens that follow are related to the how often you should take snapshots. The settings here are related to a customer’s own environment. In most of the following screens I have chosen the default. However, these values may not be ideal for your customer’s environment and ideally the customer should discuss these settings with FalconStor to make sure that they meet their needs.

Step 6: This screen allows the predefined space allocated to snapshots to grow. The default is to allow it to grow by 20% segments and to grow to use the entire disk allocated to snapshot resources. Click Next to accept the defaults.

Step 7: This screen defines what to do with snapshots when there is not space available on the snapshot resource or the snapshot resource is no longer available. Again, I have accepted the default which means it will delete older snapshots if no space is available, or if there is a disk failure, it stops using the snapshot resource entirely. However, other options may be more suitable to customers.

Step 8: This option can pause I/Os for certain operations on the NSS. By default it is enabled, but can be disabled if your customer wishes. Click Next.

Step 9: This screen asks you to select a remote NSS for replication. In this example I only have two appliances so my remote NSS is chosen automatically. Click Next.

Step 10: Populate with the IP address or hostname that we be used for replication traffic.

Step 11: Decide whether the replication should be done in Continuous Mode or Delta Mode. Again, this is a call that the customer will have to make for themselves. FalconStor support both methods of replication for SRM.

FalconStor don’t make a recommendation on this, so as I said it is up to the customer. In this case I left it in Delta Mode. Click Next.

Step 12: The recommended timemark schedule is up to the customer and depends what is being snapshot’ed . If there are a lot of DB applications on the VMFS volumes then a customer will notice if you quiece applications every 10 minutes. According to FalconStor, hourly is the most common timemark deployment schedule. Click Next.

Step 13: This screen allows you to control resources during synchronization. Leave this at the default which is unchecked. Click Next for Replication Protocol.

Step 14: Replication Protocol is TCP. Click Next for Data Transmission Options.

Step 15: Click Next unless you wish to compress or encrypt your replication data.

Step 16: Select a disk on the remote/target NSS to replicate the data (resource) to:

Step 17: Select a disk on the remote/target NSS to store snapshots (timemarks) to:

Step 18: This screen asks you how much space to dedicate on this disk for snapshots. We’ve seen this before when setting up timemarks earlier. The default is 20%. Click Next.

Step 19: This screen allows the predefined space allocated to snapshots to grow. The default is to allow it to grow by 20% segments and to grow to use the entire disk allocated to snapshot resources. Click Next to accept the defaults.

Step 20: As before, this screen defines what to do with snapshots when there is not space available on the snapshot resource or the snapshot resource is no longer available. Again, I have accepted the default which means
it will delete older snapshots if no space is available, or if there is a disk failure, it stops using the snapshot resource entirely. However, other options may be more suitable to customers.

Step 21: Click Finish to complete the Replication configuration.

Step 22: Click OK after verifying clocks are in sync on both the primary and target replication servers.

Step 23: You can observe the synchronization by viewing the Replication -> Outgoing -> San Resource (disk) -> Replication tab:

Step 24: Enable TimeMark on the replicated LUN.

You can configure TimeMark on both the primary & secondary side . On the primary side you can use it for local recovery and Business Continuity & at the DR site you can configure it to give you more than one recovery point.

You need to configure it at the DR site to be able to use the ‘test failover’ feature of the SRM. This is a handy feature because it is possible to validate a DR copy from a timemark without having to break the replication relationship between the primary and secondary sites.

To set it up, select the replicated device on the secondary/protected site under Replication -> Incoming -> hostname -> device name, right click and select TimeMark/CDP -> Enable.

This launches the following wizard.

Step 25: Click Next:

Step 26: Click Next:

Step 27: Click Next.

Step 28: Click Finish.

A view of the replicated SAN Resource from the primary/protected site:

A view of the replicated SAN Resource from the secondary/recovery site:

Now we can install the SRA and start using SRM.

Part 4 – Install the FalconStor Storage Replication Adapter

Step 1: Click Next:

Step 2: Check the Radio button to accept the EULA, then click Next:

Step 3: Click Next:

Step 4: Enter the license key from FalconStor for the SRA & click Next:

Step 5: Click Install.

Step 6: Click Finish.

Part 5 – Configure the SRA & Test SRM Functionality

The following tasks are carried out on the primary/protected site SRM.

Section 1: Add the primary side NSS-VA to the array managers.

Step 1: Click Add:

Step 2: Populate the details for the primary/protected side NSS VA and click Connect. Notice that the NSS
VA from FalconStor uses manager type NSS-S12.

Step 3: Click Next.

Section 2: Add the secondary/recovery side NSS-VA to the array managers.

Step 1: Click Add:

Step 2: Populate the details for the secondary/recovery side NSS VA and click Connect.

Step 3: Click Next.

Step 4: Verify that you have discovered the replicated LUN.

If you do not have a replicated LUN discovered, ensure that:

• The LUN has a valid VMFS-3 filesystem on it.
• The VMFS-3 contains a Virtual Machine.
• The LUN is indeed replicated.

Section 3: Configure the Protection Group

The following tasks are carried out on the primary/protected site SRM.

Step 4.1: Give the Protection Group a name then click Next.

Step 4.2: Select a datastore group (containing the replicated LUN) and assign it to the Protection Group.

Step 4.3: Select a datastore on the recovery site to use as a placeholder for the virtual machine configuration files. Then click Finish.

Section 4: Create the Recovery Plan

The following tasks are carried out on the secondary/recovery site SRM.

Step 1: Give the Recovery Plan a name then click Next.

Step 2: Select one or more Protection Groups to associate with the Recovery Plan. In this case I have only chosen a single PG, which is the FalconStor specific one.

Step 3: Do you wish to change the response times? If not, click Next.

Step 4: Which networks to use when testing failover. Leave it au auto to bring the VM up in a ‘bubble’ network.

Step 5: Do you want to suspend any virtual machine during a recovery plan run. If not, click Finish.

Section 5: Test Failover

These steps are carried out on the Recovery side SRM. Click on Test to do a test failover using a particular Recovery Plan.

Step 1: Test Failover start completed successfully.

Step 2: Replicated LUN is now visible to recovery side ESX. Remember that this is a timemark taken from the replicated SAN Resource – it is not the actual replicated SAN resource on the NSS VA. This is only made visible during an actual failover. This is why we need the TimeMark functionality placed on the replicated SAN Resource.

Step 3: VMFS-3 volume on the LUN is visible, but we can see it is treated as a snapshot.

Step 4: Virtual Machine is up and running.

That completes the configuration of Site Recovery Manager with FalconStor NSS-VA. Click Continue on the Recovery Steps screen to end the test failover process and return the storage to its original configuration, i.e. unpresent the timemark which was promoted to a real LUN, etc.

Misc

1. There is a log gathering utility that can be run in the NSS VA to capture configuration information which could be very useful to our support folks. The X-Ray is the configuration and log gathering utility that FalconStor support people use . You can run this from the IPStor Management Console by right clicking on the NSS-VA and selecting X-Ray.

2. I got this message occasionally when trying to do tasks in the console:

It seems to occur because the server disconnects from the console while I’m in the middle of setting up a task, i.e. adding a SAN resource. To increase the timeout value between the appliance and the console, go to

Tools -> Console Options -> Console Timeout setting.

vdf–VMware ESX Disk Free Command
As df works in Linux, vdf works in the Service Console. The df command will work in the Service Console, but will not show free disk space on VMFS volumes.
vmkchdev–VMware ESX Change Device Allocation Tool
This tool can assign devices to either the Service Console or VMkernel, as well as list whether a device is assigned to the SC or VMkernel. This replaced the vmkpcidivy command found in previous versions of VMware ESX.
vmkdump–VMkernel Dumper
This command manages the VMkernel dump partition. It is primarily used to copy the contents of the VMkernel dump partition to a usable file for troubleshooting.
vmkerrcode–VMkernel Status Return Code Display Utility
This command will decipher VMkernel error codes along with their descriptions.
vmkfstools–VMware ESX Server File System Management Tool
This utility is used to create and manipulate VMFS file systems, physical storage devices on an ESX host, logical volumes, and virtual disk files.
vmkiscsi-device–VMware ESX iSCSI Device Tool
Used to query information about iSCSI devices.
vmkload_mod–Vmkernel Module Loader
This application is used to load, unload, or list, device drivers and network shaper modules into the VMkernel.
vmkloader–VMkernel Loader
This command loads or unloads the VMkernel.
vmkpcidivy–VMware ESX Server Device Allocation Utility
This utility in previous versions of VMware ESX, allowed for the allocation of devices to either the Service Console, or the VMkernel. In VMware ESX 3.0, this utility is deprecated, and should only be used to query the host bus adapter allocations using the following: vmkpcidivy -q vmhba_devs
vmkuptime.pl–Availability Report Generator
This PERL script creates HTML that displays uptime statistics and downtime statistics for a VMware ESX host.
vmware-hostd–VMware ESX Server Host Agent
The vmware-hostd script acts as an agent for an ESX host and its virtual machines.
vmware-hostd-support–VMware ESX Server Host Agent Crash Information Collector
This script collects information to help determine the state of the ESX host after a hostd crash.

Networking and Storage Commands
esxcfg-firewall–VMware ESX Server Firewall Configuration Tool
Provides an interface to view and change the settings of Service Console firewall.
esxcfg-hwiscsi–VMware ESX Server Hardware iSCSI Configuration Tool
Provides an interface to allow or deny ARP redirection on a hardware iSCSI adapter, as well as enable or disable jumbo frames support.
esxcfg-linuxnet–No specific name
This command is only used when troubleshooting VMware ESX. It allows the settings of the vswif0 (virtual NIC for the Service Console under normal operation), to be passed to the eth0 interface when booting without loading the VMkernel. Without the VMkernel loading, the vswif0 interface is not available.
esxcfg-mpath–VMware ESX Server multipathing information
This command allows for the configuration of multipath settings for Fibre Channel and iSCSI LUNs.
esxcfg-nas–VMware ESX Server NAS configuration tool
This command is an interface to manipulate NAS files systems that VMware ESX sees.
esxcfg-nics–VMware ESX Server Physical NIC Information
This command shows information about the Physical NICs that the VMkernel is using.
esxcfg-rescan–VMware ESX Server HBA Scanning Utility
This command initiates a scan of a specific host bus adapter device.
esxcfg-route–VMware ESX Server VMkernel IP Stack Default Route Management
Tool
This can set the default route for a VMkernel virtual network adapter (vmknic).
esxcfg-swiscsi–VMware ESX Server Software iSCSI Configuration Tool
The command line interface for configuring software based iSCSI connections.
esxcfg-vmhbadevs–VMware ESX Server SCSI HBA Tool
Utility to view LUN information for SCSI host bus adapters configured in VMware ESX.
esxcfg-vmknic–VMware ESX Server VMkernel NIC Configuration Tool
Configuration utility for managing the VMkernel virtual network adapter(vmknic).
esxcfg-vswif–VMware ESX Server Service Console NIC Configuration Tool
Configuration utility for managing the Service Console virtual network adapter (vswif).
esxcfg-vswitch–VMware ESX Server Virtual Switch Configuration Tool
Configuration utility for managing virtual switches and settings.
esxnet-support–VMware ESX Server Network Support Script.
This script is used to perform a diagnostic analysis of the Service Console and VMkernel’s network connections and settings.
vmkping–Vmkernel Ping
Used to ping the VMkernel virtual adapter (vmknic)
vmkiscsi-ls–VMware ESX iSCSI Target List Tool
This command shows all iSCSI Targets that the iSCSI subsystem knows about, including Target name, Target ID, session status, host number, bus number, and more.
vmkiscsi-tool–VMware ESX iSCSI Tool
This command will show the properties of iSCSI initiators.
vmkiscsi-util–VMware ESX iSCSI Utility
This command will display LUN Mapping, Target Mapping, and Target Details.

VMware Consolidated Backup Commands
vcbMounter–VMware Consolidated Backup–Virtual Machine Mount Utility
This utility is used to mount a virtual machine’s virtual disk file for the purpose
of backing up its contents.
vcbResAll–VMware Consolidated Backup–Virtual Machine Restore Utility
This utility is used to restore multiple virtual machines’ virtual disk files.
vcbRestore–VMware Consolidated Backup–Virtual Machine Restore Utility
This utility is used to restore a single virtual machine’s virtual disk files
vcbSnapAll–VMware Consolidated Backup–Virtual Machine Mount Utility
This utility is used to backup one or more virtual machines’ virtual disk files.
vcbSnapshot–VMware Consolidated Backup–Snapshot Utility
This utility is used to backup a virtual machine’s virtual disk files.
vcbUtil–VMware Consolidated Backup–Resource Browser and Server Ping
This utility provides different information, depending on argument. The ping argument attempts to log into the VirtualCenter Server. The resource pools argument lists all resource pools, and the vmfolders argument lists foldersthat
contain virtual machines.
vcbVmName–VMware Consolidated Backup–VM Locator Utility
This utility performs a search of virtual machines for VCB scripting. It can list individual VM’s, all VM’s that meet a certain criteria, or VM’s on a specificESX
host.
vmres.pl–Virtual Machine Restore Utility
This PERL script is depreciated, and vcbRestore should be used instead.
vmsnap.pl–Virtual Machine Mount Utility
This PERL script is depreciated, and vcbMounter should be used instead.
vmsnap_all–Virtual Machine Mount Utility
This script is depreciated, and vcbSnapAll should be used instead.

例升级数据中心DL中名为xp的虚拟机:

vmware-vmupgrade -u administrator -n /DL/xp
Enter password for administrator:
Connecting to VirtualCenter server on local port 443
Looking for VMs…
Found /DL/xp
/DL/xp: host is VMware ESX Server version 3.5.0
/DL/xp: VM is powered off, checking virtual hardware
/DL/xp: virtual hardware upgrade was not required
/DL/xp: setting up tools upgrade…
/DL/xp: tools upgrade setup complete
/DL/xp: power on requested
/DL/xp: power on task is running
/DL/xp: power on is complete
/DL/xp: tools update completed successfully
/DL/xp: VM was powered off

升级主机192.168.100.101上所有已关闭的虚拟机，主机位于数据中心DL中，且主机一次最多启动2台虚拟机:
vmware-vmupgrade -u administrator -h /DL/192.168.100.101 -m 2
Enter password for administrator:
Connecting to VirtualCenter server on local port 443
Looking for VMs on host /DL/192.168.100.101…
Found /DL/192.168.100.101:VC25u2
Found /DL/192.168.100.101:xp
/DL/192.168.100.101:VC25u2: host is VMware ESX Server version 3.5.0
/DL/192.168.100.101:VC25u2: Cannot upgrade. VM is not powered-off
/DL/192.168.100.101:xp: host is VMware ESX Server version 3.5.0
/DL/192.168.100.101:xp: VM is powered off, checking virtual hardware
/DL/192.168.100.101:xp: virtual hardware upgrade was not required
/DL/192.168.100.101:xp: tools are up-to-date. Skipping tools upgrade

默认的安全配置为使用SSPI，但你可改为Kerberos验证方式，只需在vpxd.cfg文件的<vpxp></vpxd>中添加如下内容.
<sspiProtocol>Kerberos</sspiProtocol>