November 2007
Monthly Archive
Wednesday 28 Nov 2007
MAC Address for Virtual Machines
虚拟世界的MAC地址
先看一下真实世界的MAC地址是如何分配，如何保证没有重复的。
每块网卡都有一个MAC地址，MAC地址是一个6字节、也即48bit的数据。前3字节称为OUI，是由IEEE组织注册给网络设备生产商的；每个厂商拥有一个或多个OUI，彼此不同。后三字节则是由网络设备生产商分配给自己生产的每一个拥有MAC地址的设备，互不重复。
在VM的世界中，每一台拥有虚拟NIC（网卡）的设备当然也拥有MAC地址。这虚拟网卡的MAC地址，当然也是按照规定，前三字节为OUI，后三字节逐一分配给每个设备。
由于虚拟网卡的”制造商“是VMware，XenSource，微软等虚拟平台软件的生产商，OUI当然就分配给了他们。
VMware VM所使用的OUI
按照VMware ESX 3的[Server Configuration Guide]的说法，VMware的使用下面的三个OUI作为VM的MAC地址：
- 00:0C:29 - 用于自动生成的MAC地址
- 00:50:56 - 用于手动设置的MAC地址
- 00:05:69 - 曾经用于旧版本的VM（大约是在ESX 1.5的时代），在ESX 3中已经不再使用
但是在实际应用上，我发现00:50:56这一MAC地址段并不是完全用于手动设置的MAC地址：
- 00:50:56:00:00:00 - 00:50:56:3F:FF:FF
这一段MAC地址可以用于手动设置的MAC地址 - 00:50:56:40:00:00 - 00:50:56:FF:FF:FF
这一段（我的推测，不一定准确），则是用于ESX 3上的自动生成的MAC地址（包括VM和Service Console）
MAC地址的生成
OUI有了，后三字节如何生成呢？要知道虚拟机是经常被创建和销毁的，这一点不像实体PC。网卡生产商可以计算每年生产多少块网卡，从而为每块网卡分配不同的MAC地址； VMware却不可能计算出每年有多少台VM、有多少块虚拟网卡被创建。
VMware ESX Server的算法是，使用散列算法，通过VM的UUID来生成MAC地址。VM的UUID是每一台VM特有的、128bit的ID，是由ESX Server硬件SMBIOS的UUID、加上VM的路径生成的。因此，一台虚拟机的虚拟网卡的MAC地址就与下面四个因素有关：
- VMware的OUI
- Host (ESX Server)的SMBIOS中的UUID
- VM在服务器上的路径
- 网卡的实体名 (Entity Name)，用来确保同一VM上的不同网卡有不同的MAC地址
MAC地址冲突的检测与解决
MAC地址一旦生成，就不会再有变化，除非上面所述的四项因素发生改变（最可能发生的就是第三项，VM在服务器上的路径改变）。
尽管如此，由于散列算法本身的特征，还是有万一发生MAC地址冲突的可能（可能性极小，和年末ジャンボ中头彩的几率差不多）。ESX Server会不断跟踪和检测运行中和挂起(Suspend)的VM，以保证没有MAC地址冲突。但是已经关闭电源的VM是不在检查对象之内的。
因此，万一一台VM启动时ESX检测到MAC地址冲突，它会分配给VM的虚拟网卡一个新的MAC地址。所以从这个意义上说，VM的MAC地址是可能发生变化的——只是这个概率实在太小。
手动指定MAC地址
手动指定MAC地址仅用于一些极其特殊的情况，通常是进行P2V的时候。例如，某物理服务器上的软件，其License已经与该服务器的MAC地址绑定，如果MAC地址改变则软件无法运行；再如，某些底层网络软件以MAC地址来鉴别机器时，为了不做更改能够继续使用，在P2V的时候也要手动指定MAC地址。
打开一个VM的.vmx文件，可以看到如下设置：（如果有多块NIC的话，那么就会有ethernet0、ethernet1、ethernet2……）
ethernet0.addressType = "generated"
ethernet0.generatedAddress = "00:0c:29:9b:fb:18"
ethernet0.generatedAddress = "00:0c:29:9b:fb:18"
这说明该NIC是自动生成的MAC地址。只需如下更改即可变为手动分配的MAC地址：
ethernet0.addressType = "static"
ethernet0.address = "00:50:56:00:00:01"
ethernet0.address = "00:50:56:00:00:01"
其中的00:50:56:00:00:01就是手动指定的MAC地址。
Saturday 24 Nov 2007
Settings for CETSC - RDP Client on Windows CE
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。
| Value | Type | Description |
|---|---|---|
| AlternateShell | String | 如果指定了该值，则RDP连接后登录到指定的shell程序，或执行指定的应用程序，而不是登录到通常的shell (explorer.exe)。 |
| AudioRedirectionMode | DWORD | 指定声音在哪里播放，默认值为0： 0 - 在远程主机播放 1 - 在本地 (Thin Client)播放 2 - 不播放声音 |
| AutoReconnectEnabled | DWORD | 当连接异常中断时，是否允许自动重新连接，默认值为1： 0 - 不允许 1 - 允许 |
| BBarEnabled | DWORD | 是否显示屏幕顶部的连接栏 (Connection Bar)，默认值为1 0 - 不显示 1 - 显示 |
| BBarShowMinimizeBtn | DWORD | 是否显示连接栏上的最小化按钮，默认值为1 0 - 不显示 1 - 显示 |
| BBarShowPinBtn | DWORD | 是否显示连接栏上的固定按钮 (Pin Button)，默认值为0 0 - 不显示 1 - 显示 |
| BBarShowRestoreBtn | DWORD | 是否显示连接栏上的还原窗口大小按钮 (Restore Button)，默认值为1 0 - 不显示 1 - 显示 |
| BBarPinned | DWORD | 是否自动隐藏连接栏，默认值为1 0 - 自动隐藏连接栏 1 - 一直显示连接栏 |
| BitmapCacheSize | DWORD | 以KB为单位指定内存里的位图缓冲区大小，默认值为1500，最大值为32000 |
| BitmapPersistCacheLocation | String | 指定位图缓冲区的位于何处，默认值为\Temp |
| BitmapPersistenceEnabled | DWORD | 指定是否允许位图缓冲。默认值为0 0 - 不允许 1 - 允许 |
| ColorDepthID | DWORD | 颜色深度，以bpp (bits per pixel)为单位。默认值为4 0 - 4 bpp 1 - 8 bpp 2 - 15 bpp 3 - 16 bpp 4 - 24 bpp |
| Compress | DWORD | 是否启用文件和目录压缩，默认值为1 0 - 不启用 1 - 启用 |
| ConnectToServerConsole | DWORD | 指定是否连接到远程主机的Console session。对于Windows x68和Windows CE来说，可以用 mstsc /console 或 cetsc /console命令连接到Console session，不需要该选项。该选项只用于不使用Windows作为OS的Thin Client。默认值为0 0 - 不连接到Console session (连接到Terminal Services session)。 1 - 连接到Console session 由于Windows XP无Console session和Terminal Services session之分，该参数对XP无效。 |
| DesktopHeight | DWORD | 以像素为单位指定屏幕高度，默认为1024 |
| DesktopWidth | DWORD | 以像素为单位指定屏幕宽度，默认为1280 |
| Disable Full Window Drag | DWORD | 指定拖动窗口时是否显示窗口内容。默认值为1 0 - 不显示 1 - 显示 |
| Disable Menu Anims | DWORD | 是否允许菜单动画显示。默认值为1 0 - 不允许 1 - 允许 |
| Disable Themes | DWORD | 是否允许显示主题。默认值为0 0 - 不允许 1 - 允许 |
| Disable Wallpaper | DWORD | 是否允许壁纸。默认值为1 0 - 禁止壁纸 1 - 允许壁纸 |
| DisableFileAccess | DWORD | 指定用户是否有权访问本地（Thin Client上面的）文件系统。默认值为1 0 - 允许用户访问本地文件系统 1 - 禁止用户访问本地文件系统 |
| Domain | String | 要连接的远程主机所在的域 |
| EnableDriveRedirection | DWORD | 是否允许重定向驱动器。默认值为1 0 - 不允许 1 - 允许 |
| EnablePortRedirection | DWORD | 是否允许重定向串口 (COM口)。默认值为1 0 - 不允许 1 - 允许 |
| EnablePrinterRedirection | DWORD | 是否允许重定向打印机。默认值为1 0 - 不允许 1 - 允许 |
| EnableSCardRedirection | DWORD | 是否允许重定向智能卡 (Smart Card)。默认值为1 0 - 不允许 1 - 允许 |
| KeyboardHookMode | DWORD | 设置Alt - TAB键的作用。默认值为2 0 - 显示本地 (Thin Client)的项目 1 - 显示远程 (Server)的项目 2 - 全屏时显示远程项目，窗口时显示本地项目 |
| MaxReconnectAttempts | DWORD | 设置连接丢失时重新尝试的次数。默认值为20 |
| MCSPort | DWORD | 设置RDP服务的端口。仅用于非Windows-based的Thin Client。 |
| MRUx (x=0,1,2..) | String | MRU = Most Recently Used，最近访问过的主机列表 |
| Password | Binary | 登陆远程主机用的密码 |
| ServerName | String | 远程主机名或IP地址 |
| StartFullScreen | DWORD | 是否以全屏模式开始远程连接，默认值为1 0 - 不以全屏模式 1 - 以全屏模式 |
| UserName | String | 登陆远程主机用的用户名 |
| WorkingDir | String | 工作目录 |
Friday 23 Nov 2007
Introduction to NEC’s Thin Client
一直想找个机会贴一下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（最大）
Tuesday 13 Nov 2007
Virtual Infrastructure New Features
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月份推出。