Code Soil

Windows CE被很多Thin Client采用，作为嵌入式的操作系统。在WinCE based Thin Client上，通常使用RDP协议与远程桌面进行连接，对Windows CE Terminal Services Client (cetsc.exe)的配置也就非常重要。

启动CETSC后，CETSC读取.rdp文件中的设置，或是根据注册表HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client下的设置连接远程主机。下面就是一个可以设置的选项列表（对.rdp文件和注册表均适用）。注意此处以在Thin Client上广泛使用的Windows CE 5.0为例；Windows CE 6的设置有所不同。此外这些设置不适用于Windows Mobile。

一直想找个机会贴一下NEC的Thin Client Device，今天就拿出来秀一秀吧。

TC-Station（上图左）是2005年4月25日正式发表的大概是NEC最初的专用瘦客户机产品（在这之前就已经推出过将普通PC硬盘去掉的瘦客户机产品）。

标售价格：5.5万日元
操作系统：基于UNIX的专用OS
本体重量：0.85kg
消费电力：8W

TC-Station High-end Model（上图右）是2005年11月21日正式发表的升级产品。和普通版的最大区别在于它内置了一个IC卡读卡器。

标售价格：7.8万日元
操作系统：Windows XPe
本体重量：1.92kg
消费电力：Max 24W

US100是2006年11月6日正式发表的，NEC的第一款面向全球发售的瘦客户机产品。在这一款产品中，NEC以两项特有技术领先于其他厂商的产品：高速视频播放——部分解决了瘦客户机上的视频性能问题；VoIP语音电话，解决了RDP不支持语音输入，无法进行电话会议的问题。US是U-Station的缩写。

标售价格：5.2万日元
操作系统：基于UNIX的专用OS
本体重量：0.42kg
消费电力：Max 13W

US110是2007年10月15日正式发表的下一代产品。它不仅继承和发扬了US100的高速视频播放和点到点VoIP语音电话的特有功能，更是以其极高的性价比对其他厂商构成了极大的威胁。

标售价格：4.9万日元
操作系统：Windows CE
本体重量：0.35kg
消费电力：11W（平均），25W（最大）

VMware在VM World 2007上公布了许多新产品的新特性，这里就把旗舰产品Virtual Infrastructure (ESX Server, VirtualCenter)的最新动向、特性做一总结（这里的资料都不是“新闻”，相信大家都已经从大小道消息早就知道了，只是做一归纳）。

Virtual Infrastructure 3.5

Plug-and-Play Datacenter: ESX 3i

VMware ESX Server 3i 是基于VMware ESX Server 3发展而来的下一代Hypervisor体系结构。简单来说，ESX 3i就是ESX 3去掉了COS (Service Console)之后的部分。

根据VMware统计，传统的ESX Server 3中，基于REHL3的COS占用了约2GB的硬盘资源，并且需要打针对REHL3的补丁——针对ESX Server3的补丁中，有一半左右是针对COS的。与之相反，Hypervisor部分（VMKernel）只占用32MB的硬盘。在ESX 3i中，就是去掉了这臃肿的、占原来ESX Server 3的98%的COS，留下一个轻便的，甚至可以嵌入服务器固件的内核。

当然，COS也不是说扔掉就能直接扔掉的——COS作为一个SHELL，一个命令行的操作界面，还是提供了很多功能的。那么这些功能在没有了COS的ESX 3i中是如何实现的呢？

■ 使用命令和脚本管理ESX的功能——在ESX 3i中，由于ESX服务器本身上已经没有命令行界面，因此提供了一个远程的命令行界面（类似SSH的感觉），叫做Remote CLI (Remote Command Line Interface)。通过这一“新SSH”，可以像在本地一样执行命令。

■ 服务器性能和健康状态的监控——在传统的ESX 3中，只需要安装软件 (例如NEC的ESMPRO) 即可监控服务器的各项状况，如温度，风扇转速等等。在ESX 3i中，则通过标准的监控协议CIM来进行服务器状况的监控。

■ 3rd Party Agent——在传统的ESX 3中，有时候会需要在COS安装一些第三方的软件的Agent，例如用于备份的软件。在ESX 3i中则只能通过其提供的界面，API等进行通信；对于备份则可使用VCB (VMware Consolidated Backup)进行。

Storage VMotion

在很久前的VCP会议中就听说过Storage VMotion。基本描述起来就是：现有的VMotion并不移动VM的存储节点（也即image文件所在的位置），而是移动VM隶属的计算节点（从一台Host移动到另一台Host）。而Storage VMotion则可以同时移动VM的存储节点，也即把VM从一个Datastore移动到另一个Datastore。

但是，VMware却同时告诉我们，Storage VMotion并不像VMotion那样可以轻松地执行。因为Storage VMotion耗费资源尤其是I/O资源，并且有部分功能不完善（例如目前还没有GUI，只能通过svmotion，svmotion.pl脚本操作），因此不应该像VMotion那样在业务中日常应用，而是作为一个能让系统不间断运作的维护工具。VMware建议的应用场景包括：Storage Array Migration（比如说买了新的FC SAN，要把整个系统从旧SAN移动到新SAN，又不想中断业务时），I/O Optimization（比如说LUN之间的负载不平衡，有的LUN上VM很多，有的LUN上VM却很少时）。

据称Storage VMotion将在ESX Server 3.5（当然也包括ESX Server 3i 3.5）中提供，并逐步在以后的版本中补完功能。

Site Recovery Manager

这也是3.5当中（VirtualCenter 2.5）提供的一个功能。如果说VMware HA (High Availability)是面向服务器、VM的灾难恢复方案，那么Site Recovery Manager就是面向Site的灾难恢复方案。只要预先定义好备用的一套Site（包括Host，存储，VM，网络拓扑结构等），Site Recovery Manager就可以按照计划或在发生万一的故障时进行fail over。

Distributed Power Management (DPM)

上次TSX的时候听说DPM，还以为是什么UPS的虚拟化工具——电源管理嘛。其实，所谓的“分布式电源管理”，是一个环保节能（也即最近提倡的Green Datacenter）的工具。可以把DPM与DRS进行比较：DRS是Load Balance的解决方案，可以自动平衡各Host间的负载，将VM平均移动到各个Host上；而DPM则是节约电能的解决方案，当VM数量较少时，DPM将VM集中移动到几台Host上，然后将其他没有VM运行的Host关闭电源。

Update Manager

Update Manager也是VC2.5中的新功能，其功能其实很简单——利用DRS将某一台ESX上的所有VM移动到其他Host上，然后对这台ESX进行打补丁等升级维护工作。难得的是这些全是全自动的。

顺便说一句，ESX 3i中，虽然只有32MB但是一样是要升级的。只不过3i不再（也无法）靠安装补丁文件的方式，而是靠更换整个3i的Image的方式（有点像固件、BIOS更新）进行升级。

Guided Consolidation

这个功能更不是什么出奇的东西了。Guided Consolidation = Capacity Planner + Converter + 集成在一起的图形界面。具体来说，就是通过VC，自动发现网络中的物理服务器（只限于Win2003等），通过Capacity Planner分析该服务器，给出移植到虚拟平台的方案，然后通过Converter执行P2V，转移到虚拟化世界来。

Para-Virtualization (exp.), Vista Guest OS, enhanced HA, enhanced VCB, NPIV and more

在3.5中，也会试验性地支持Para-Virtualization，当然这也需要OS的支持（如RHEL5等）。此外，Windows Vista也终于结束了漫长的评测过程，正式被纳为虚拟OS家族的成员。

还有许多其他的功能，这里就不一一说明，有兴趣的话请Google相关资料。

Beyond 3.5 …

Enhanced VMotion

众所周知，执行VMotion的要求近于苛刻——这也不能怪VMware，因为不同CPU之间，即使是微小的指令集的差异，也会导致对于企业应用来说噩梦一般的“蓝屏”。此外更令人郁闷的是，两台Host只见究竟能否做VMotion，只有在实际做之前才知道（当然，熟悉VMotion的VCP可以轻易的事先判断）。

VMware将会逐渐打破这一壁垒。首先是通过AMD的“AMD-V Extended Migration Technology”以及Intel的“Flex Migration”，使得同一厂商的不同CPU家族之间可以Hot Migration；并且会逐渐依靠其夹在VM和硬件中间的身份进行协调，使得在不久的将来不同厂商的CPU只见的VMotion也成为可能。

Software FT (Fault-tolerant Virtual Machines)

这一新特性的正式名称还不清楚，但是光看名字已经让人振奋不已。容错（fault tolerance，ft）服务器通常指一台服务器中包含两套相通的模块，通过lockstep processing互为备份，即便其中一组模块当机也能无停止地切换到另一组模块。它能提供99.999%，也即年当机时间不超过5分钟的连续可用性 (Continuous Availability, CA)。而相比之下，MSCS等集群只能提供99.9%，也即年当机时间8小时45分钟左右的高可用性（High Availability, HA）。

在VMware即将提供的软件FT（或虚拟FT？）功能中，可以将两台位于不同物理Host上的VM捆绑为一台fault tolerant VM，同步操作。从某种角度来说，用户不必再去购买昂贵的硬件容错服务器，而是通过使用Virtual Infrastructure就能拥有数台可靠的“软”容错虚拟服务器了。当然，究竟“软”容错能否从“硬”容错手中抢到市场，还要看“软”容错是否稳定，是否能像“硬”容错一样提供99.999%的可用性了。

Software FT虽然很可能不会在3.5中提供，但是预计将在明年中提供（4.0?）。

Related Products

Virtual Desktop Manager (VDM) 2.0

其实VDM并不是Virtual Infrastructure产品的一部分；它属于VMware的VDI产品族。它和著名的Leostream Connection Broker一样，是一个VDI Broker产品，是客户端设备连接虚拟桌面时的“管家”。有关VDM的详细信息，我将专文介绍。

 根据目前的消息，VDM2.0将在明年2008年2月份推出。

This article describes the solution for the “access denied” error occurs when using qwinsta.exe/rwinsta.exe or WTSOpenServer Windows API function to access to a Windows XP SP2 PC.

The same thing happens when you are trying to connect to a Windows XP SP2 using Terminal Services Manager from a Windows 2003 Server. 

- Because essentially qwinsta.exe command calls WTS functions (WTSOpenServer, WTSEnumerateSessions, …), you will encounter the same error when using either the command or the API.

As a quick answer, check the following points.
1. Ensure you have the correct credential
Although you do not need to provide a username and a password when executing qwinsta.exe or WTSOpenServer, Windows use its stored credentials automatically, just like accessing a shared folder.

The easiest way to confirm the credential is to use Explorer to access remote server’s C$ share. Also, you can use “net use” command.

For those who want to connect to a remote server programmatically using WTSOpenServer API, WNetAddConnection2 function should be enough to make sure you got a piece of credential before calling WTSOpenServer function.

Of course the user in the credential should be a use on the remote server who has enough privilege to carry out the operation.

2. Open RPC ports on firewall
An API call involves connecting to a remote machine use RPC. In most cases the RPC service is running and you can confirm that from the service management interface. To open RPC ports, simply enable “File and Printer Sharing” in the Windows Firewall setting.

(Generally, if the RPC is blocked by the firewall on remote machine, the error should be "1722 RPC server is unavailable" rather then "5 Access denied")

3. Disable "Force Guest" log on

You can change this option from either local security policy or registery.

Local security policy : run secpol.msc > Secuirty Settings > Local Policies > Security Options > Network access : Sharing and security model for local accounts, and set to "Classic".

Registry : find "forceguest" item in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, and set it to 0.

The two ways are equivalent. If this option is set to 1, remote logged in user will be impersonated as Guest account (and if Guest account is disabled, login fails). Set it to 0 enables user logging in as themselves.

4. If you still receive “access denied” and it only happens when the remote OS is Windows XP SP2, it is very probably the following case.

To confirm, you need a packet sniffer such as Wireshark (a great freeware).
When you use a sniffer to capture the SMB packets, you can see the authentication is OK (NTLM if workstation, Kerberos if Windows 2003 domain), but the RPC get nca_s_fault_access_denied (0×00000005) as error code.

This means the remote RPC component failed to execute the requested operation. It is because in Windows XP SP2, it is not allowed to operate on terminal service (Remote Desktop) through RPC by default. To modify this setting to enable Remote Desktop API through RPC, you need to find the following registry key:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server

Then add a DWORD value named “AllowRemoteRPC” and change its value to 1.

I googled it and it seems there is no official document on it. (I don’t know why)

Access denied error often misleads us into thinking it must be because of the insufficient privilege, or because that the qwinsta.exe command / WTSOpenServer failed to utilized the credential. It wasted me about 5 hours in researching how to attach a credential to a RPC call, and I even got caught deeply into the complicated SSPI/LSA authentication architecture.

一个来月没写东西了，原因很简单，先是大病一场断断续续修养了两个星期；接着是新加坡出差；明天还要去北京……日子就这么在疲倦和麻痹中流逝而去了。

今天说一说“免费”。人们都喜欢免费的东西——从商场门口的免费品尝到网上的免费软件。只要是免费，就算品质不太好，服务不周到也就不大计较了。“要饭吃还嫌馊？”——我头脑中映出的就是这句歇后语。

那么，在企业应用中事情又是如何呢？我身边最近发生了这样的一个真实的事例。

【都是免费惹的祸】

我们组的技术人员H君三年来一直在做VMware GSX Server的技术支持工作。

如大家所知道的那样，VMware GSX Server是VMware稍早期的产品，运行在Windows或Linux的Host OS之上。2006年2月，VMware公司宣布将最低售价为$1400美元的VMware GSX Server作为免费软件提供。7月，这款已经成为免费软件的VMware GSX Server以另一个名字推出——VMware Server。

将收费软件变成免费软件，厂商、用户皆大欢喜，何乐而不为呢？

可是问题偏偏就出在这里。GSX变成免费软件之后，对于免费软件自然不会提供技术支持。对于已经购买GSX的客户，在售后服务合同到期后不会在续签。于是，H君就陆续收到了许多客户的抱怨。

“我们的GSX需要升级，可是新版本的GSX，也就是VMware Server是免费软件！这怎么可以？你们要想办法继续提供售后支持。”
“当初你们说GSX虚拟技术多么好多么好，和你们公司的服务器捆绑推销给了我们，现在GSX你们不支持了？！那要我们怎么办？服务器也要退货！”
……

最近几个月，H君都在头疼这些事情——都是免费惹的祸啊。

【我们的服务器贵在哪里】

NEC最值得骄傲的计算机技术是什么？是超级计算机。NEC的超级计算机世界闻名，远销欧美科研机关，目前法国气象局的气象预报系统就是使用了NEC的超级计算机。

那么NEC最值得骄傲的计算机产品是什么？是ft服务器，也就是容错(fault-tolerant)服务器。台湾不是架设了和日本新干线媲美的高速铁路么，里面的核心控制服务器全都是用的NEC的ft服务器。ft服务器里面，所有的硬件——CPU，内存，主板，硬盘，网卡等等全都是两套；服务器由4个模块构成：CPU Module #1, #2, PCI Module #1, #2。这四个模块以双工方式(duplex)同时运行，任何一个模块出了问题都可以零时延地fail over到另一个模块上。这样就保证了即便在万一的情况下（硬件的硬性损坏），也能365天 x 24小时无停止地运作。

看看 ft的主页就知道，ft的价格不菲。最最便宜的也要138万日元，按照今天的汇率（1人民币比16.18日元）相当于8万5千多人民币。在两三年前的汇率下相当于10万人民币（可见人民币上涨的速度真快呀~~~这是题外话）。而这仅仅是最便宜的ft。台湾高铁使用的ft，由于配置非常高，售价要在这个价格的十几倍以上，也就是一台服务器100万人民币以上。具体价格这里就不便介绍了。

不仅ft，NEC的其它服务器其实也都不便宜。这些昂贵的服务器，到底比那些杂牌的服务器强多少呢？

其实，从技术角度上讲，未必比那些杂牌服务器强很多，毕竟这个IT时代每个IT企业都必须掌握最新的技术才能生存。但是，包括NEC在内，这些大企业的产品的价值不仅在于产品本身。

前几个月某国某地ft服务器出现问题，更换了模块之后还是陆续出现问题。这里且不说问题的原因（其实很多都是人为造成的），单说出现问题后，由于频繁更换模块，已经没有备用的模块了。于是NEC就直接从日本空运过去十几个CPU Module和PCI Module，并直接派技术人员去更换、调查。这些就仿佛在说：“服务器出现问题了不怕，我们立刻免费给你换新的！又出问题了？那我们再给你免费换新的！”

这些更换用的模块、以及技师的海外出差费用都极其昂贵。用户花大价钱购买服务器，在某种程度上来说，购买的就是这种安心的售后服务。

【结语】

对于企业来说，采购时不仅要考虑当时的费用，而且要考虑到维护和持续使用时产生的费用——也即TCO的概念。对于没有售后保障的免费产品，在TCO上没有任何优势而言，除了小规模、实验性的应用之外，对于企业来说是不大适合的。

在最近的一篇blog中，使用了colgroup HTML标签。没想到，使用了colgroup的帖子经过XHTML Validator的检查，发现居然不符合XHTML规范。究其原因，说是发现了如下错误：

Error Line 78 column 139: document type does not allow element "br" here.
...ALIGN: center"></col></colgroup><br />

但是奇怪的是，我的源代码中，</colgroup>后并没有<br />。我们可以用W3Shool给出的最简单的例子进行实验：

试着在Wordpress (2.0.x，包括最新的2.0.10。在2.2上则没有这个bug) 中编辑一个新帖子，在代码画面敲入上面这段代码，发布，再去看生成的HTML时就会发现变成了这个样子：

由于</colgroup>和<tr>之间是不允许有<br/>的，所以导致XHTML验证错误。

那么追根到底是在什么时候这个<br/>被添加到输出的HTML中的呢？调查了一下数据库，发现在数据库里面的内容还是没有<br/>的，这说明它是在读取post的内容时，由相关的Filter添加的。一个post的内容在被从数据库读出来，到被显示在网页上之间使用的是叫做the_content的Filter Tag。在Wordpress中，默认有如下Filter被添加到the_content的处理中：

add_filter('the_content', 'wptexturize');
add_filter(’the_content’, 'convert_smilies’);
add_filter(’the_content’, 'convert_chars’);
add_filter(’the_content’, 'wpautop’);

经过检查，发现位于/wp-includes/functions-formatting.php中的wpautop函数中有如下代码：

可见，该函数中用preg_replace函数通过正则表达式删除掉了添加在table，thead，tfoot等后面的<br />，却没有删除colgroup后面的<br/>。因此，只要在这一行添加colgroup即可修正这个bug。将修改后的functions-formatting.php重新上传到服务器后，在此进行XHTML验证，正常通过。

在为期四天的VMware培训结束之后，最后除了提交一份调查问券之外，还有一份Review Question。根据老师的说法，这个可以看作是VCP考试的例题。回家在网上google了一下，发现这些例题和答案是公开在互联网上的，既然这样就不用担心是内部用的东西了。这里就把我做的解释也一起拿出来供有意报考VCP的同学参考（当然，可能“参考”一下网上流传的VCP真题更快捷一些……）。

Answers

1. A    2. B    3. C    4. B    5. B    6. D    7. A    8. A    9. B    10. D    11. D      

Explanation

1. VMware ACE (Assured Computing Environment)正如答案A所说，是用来提供安全、基于策略进行管理的虚拟PC环境的平台。VMware ACE可以作为一个独立平台使用，也可以和VMware Workstation 6结合使用，但是不可以和Virtual Infrastructure一起使用。
2. VMware Workstation没有提供远程管理工具；ESX Server比其他产品所支持的Guest OS更少，原因已经在正确答案B里面说明了。最后的D，除了ESX之外其它产品也支持多CPU，只是支持的CPU数量可能不同。
3. A的话前半句是对的，因为连接到VC可以提供更多的功能；但是如果没有购买VC的话就只能连接ESX了。
   C和D的描述基本一致，唯一的差别就是Clone之类的操作是否可以进行。没有VC的话是不能克隆的。
4. 多块物理网卡 (NIC)可以绑定在一起 (NIC Teaming)，从而实现负载平衡 (Load Balancing) 或者Fail over。Standby NIC的作用就是当前NIC发生故障时自动启用，以实现Fail over的。
5. Cold Migration顾名思义，就是在VM在停止状态时的移动。无论是Power Off还是Suspend，VM都会完全停止，不使用任何CPU和内存，因此可以Code Migration。如果VM正在使用着CPU和内存，就只能VMotion了。
6. A是错的，即便无论如何也满足不了A的Reservation，VC也只是会发出警告，而不会Power Off掉VM（除非定义了某些自动操作，比如资源不足时自动关闭VM等）。B更是无关了，因为是在Resource Pool的外面。
   C也不对，因为即便物理资源不够，VM还是能够启动，这时VC会把Resource Pool中其它VM所使用的资源强行剥夺过来，分配给这个VM以满足其Reservation。如果其它VM处也没有那么多资源，这时就无法启动了。
7. 无需说明了，在VM的BIOS画面敲ESC键可选择启动顺序。
8. 这个问题有一点Tricky。VMFS-2升级到VMFS-3之后，就是VMFS-3了，和其它的VMFS-3分区没有任何区别。ESX 2.x无法访问（只读都不行）VMFS-3。此外，升级VMFS-2并不需要把ESX 2加入到VC中。
9. 这个问题几乎天天被问，估计不用说明就都知道了。就算连接不到License Server了，还有14天的Grace Period。这14天结束之后，虽然正在运行的VM不会被强行关掉，但是却无法再启动任何VM了，除非再连接回License Server。
10. 看到D就不用看其它答案了，VMware CPU Compatibility Tool就是为了检测两台主机的CPU是否满足VMotion的要求的。
11. 访问ESX Server的Web Access不需要VI Client，因为Web Access是架设在ESX Server上的Tomcat Web Server，只需要浏览器就可以了。

刚刚发现了百分比(%)在IE和在Firefox中的表现并不相同，现在居然发现即便是在Firefox内部，em和%的表现也并不一样。

首先先要讨论一下，作为font-size等CSS属性的单位，78%和0.78em到底是否相同？

遗憾的是，我并不是CSS专家，所以我没法回答按照标准这两个单位是否完全相同。但是，根据某些权威网站的说明，

Both em and % are relative measures. The difference is what each is relative to. Em is always relative to font size. % is relative to the containing block, usually the body, a div, or a table, unless applied to font-size, in which case it applies to the parent font-size.

也就是说，在用于font-size的时候，两者的涵义应该是相同的。但是，当我用下面在Firefox (ver 2.0.0.3, 默认字体微软雅黑16px)上显示如下HTML片段时，却出现了令我不解的结果：

Firefox下的结果

IE下的结果

看了这些结果，我真的不明白了：到底font-size单位中的百分比和em是否相同？

此外，有一点让我安心的就是，如果使用em作为单位的话，就没有上一篇文章中提到的，IE和Firefox中大小不一致的现象了。

今天在测试IE7和firefox下blog的字体显示时，发现在某些特定的font-size下，IE和firefox所显示的字体大小并不相同。

这里要提前说明的是，我所遇到的问题是在如下环境下发生的：

• 所测试的字体为宋体 (Simsun)以及目前最时髦的微软雅黑 (Yahei)。测试结果表明，这个问题无论是在宋体还是在微软雅黑都会发生
• IE版本为IE6或IE7，firefox为2.0.0.3
• CSS当然是使用em体系，也即百分比单位、或者em单位的font-size (这年头应该很少有人用px来定义文档字体了吧？)
• Firefox的默认字体大小设置为16px，IE无法设定默认字体（中等大小时）大小（如果哪位知道如何更改默认字体大小，还请告诉我），据有关文档称也是16px。

为了找出问题的根本原因，我写了一段php代码用来输出font-size等于100% (也即1em) 到 50% (0.5em)之间的每隔1% (0.01em)的文字显示结果。该程序的运行结果如下图所示。

上图是在Firefox下的测试结果。然后，根据IE和Firefox下的结果，得出了右面的这张表格。

通过这张表格即可看出，虽然在大多数的的情况下IE和Firefox的结果是相同的，但是当设置font-size=97%的时候，IE会显示16px的字体，而Firefox则显示15px的字体。同样font-size=72%时，IE显示12px字体，Firefox则显示11px字体。

实际用计算器计算一下就知道，当font-size为97%时，16px X 97% = 15.52px。也就是说，在IE中15.52px被解释为16px字体，而在Firefox当中15.52px被解释为15px字体 (不知道是不是Firefox的计算方法有问题？或者是W3C规定这样做的？还是我计算错误？)。

补充一条最新发现：刚才试着用CSSViewer这个插件检查了一下font-size=97%时的像素值，发现结果并不是我想象的15.52px，而是15.4667px——不知道Firefox中究竟是按照什么标准计算百分比单位的font-size的呢？

IE和Firefox究竟谁对谁错，实在是难以说清，不过有一点是肯定的——就是在设计CSS的时候，要特别注意这些IE和Firefox之间不同的地方。

花了四天时间，终于上完了全部的课——这个又贵又长（$2995，四整天）的培训，也给我这个玩了近半年VMware VI3的人带来了一些新的收获。

本次培训课程的全称是VMware Infrastructure 3: Install and Configure，是一套覆盖了从初级到中级的、全面介绍VI3的功能和具体用法的课程。对于有一定VI3基础的人来说，可能这个课程的前半部分过于简单，因此我也考虑过是否要参加VMware最新的课程：VMware Infrastructure 3: Deploy, Secure & Analyzer。后者主要涵盖中级到高级内容，包括scripting（我最想学的部分），security（也是极其重要的部分，应该包括了firewall的设置等很重要的内容），以及更深入的DRS和HA，最后还有问题分析的工具和方法（和我现在的业务关系紧密）。——但是，遗憾的是该课程目前在我们这里还没有，于是我只好选择了前者。

上课的形式是50%讲座，50%实习 (Hands-on)的形式，使用的机器全都在美国。我们通过教室里PC机上安装的Citrix终端远程访问位于美国VMware总部的工作站，再从那里远程访问ESX Server和VirtualCenter Server（感觉就是特别绕，经常用着用着就不知道自己在哪里了）。参加这个课程除了可以得到一套全英文的教材，还赠送一套VI3的CD-ROM（但是License要到VMware公司去下载试用版），另赠送一VMware帆布包。

闲话不多说，下面就是一些课堂上注意到的一些Tips。

Tip 1 VMware ESX Server 可以安装在单CPU系统上

VMware的很多技术文档中都明确说明，ESX必须安装在双CPU或更多CPU的系统上。的确，这是官方的说法，但是事实上在单CPU服务器上安装ESX也并不会导致出错、无法安装。不过，在了解了VMkernel的CPU调度的原理之后，可以很明显地看出单CPU、特别是单Core、不支持Hyperthreading的CPU将会大幅度拖慢系统性能，尤其是在VM的CPU使用率较高的时候。可想而知在这样的环境下VMware DRS/VMware HA是难以运行，或者行为异常。

因此作为测试来说，实在没有Dual CPU的机器单CPU的也凑合着用吧，不过最好有Hyperthreading功能。至于production环境，务必使用双CPU或更多CPU的服务器。

Tip 2 VMotion的充分必要条件

要使用VMotion功能（以及依靠VMotion的其它功能例如DRS），有无数条件需要满足，例如首先要有一个用于VMotion的VMkernel，此外被移动的VM必须是存储在SAN之类的共有设备上等等。关于两台ESX的CPU，VMware说需要compatible CPU，也就是说进行VMotion的两台ESX Server的CPU要兼容。什么是“兼容”呢？当然，如果你去看Basic Administration Guide可以获得既详细却又冗长的答案，这里就把VMotion对CPU的要求做一总结：

 当然，与其要记住这么多，不如直接下载VMware提供的CPU Compatibility Tools，这个工具是专门为VMotion设计的，用来检查两台ESX Server的CPU兼容性。

Tip 3 Service Console是一个特殊的VM

很多人有一种误解，就是ESX Server启动之后看到的这个很像Linux界面——Service Console，就是ESX的OS本身。因此，很多人认为ESX Server是基于Linux的，或者说是安装在一个经过修改的Linux的上面的。

这种说法其实也不能说是完全错误，但是说ESX是构建在Linux之上的却是错误的——因为正相反，这个“Linux”也是运行在ESX之上的一个特殊的VM。

Service Console只被分配给一个CPU，无论物理服务器拥有多少个。这个CPU固定是CPU0，也即系统中的第一个逻辑CPU。和其他VM不同的是，Service Console可以直接和ESX的核心VMkenel打交道，进行系统管理操作。

此外，还有一些关于SAN的Multipathing，以及资源管理的话题，以后找时间专门说吧。