Posts tagged esx3i
Install ESX Server 3.5/3i onto ESX Server
Jan 21, 2008
已经有许多文章介绍如何在VMware Workstation上安装ESX Server，而在一台ESX Server上安装ESX Server其实也是大同小异。这里就把安装时的关键步骤记录一下。
# 下面的文章中，将直接安装在硬件的ESX Server称为【Host ESX Server】，将安装在Host ESX Server上的ESX Server称为【Guest ESX Server】
1. 做好Guest ESX Server的设置
就如同安装其他Guest OS一样，通过VI Client或者VirtualCenter连接到Host ESX Server，并创建一台VM。 创建时，OS类型选择“其他”，vCPU为2个，内存为1GB或更多即可。
2. 将网卡类型改为e1000
在创建好VM之后，不要急着安装。
在安装Guest ESX Server时，由于ESX Server无法识别默认的AMD网卡，需要手动编辑.vmx文件，将网卡类型改为ESX Server能够识别的“e1000” 。
登录到Host ESX Server的Service Console，在/vmfs/volumes/下找到创建好的VM的.vmx文件，用vi编辑器在其中加入如下行：
ethernet0.virtualDev = “e1000″
这里，ethernet0是第一个虚拟网卡，如果创建VM时设置了多块网卡，需要分别设置。设置好之后，可通过启动VM时的Boot Menu来确认。
默认的网卡类型：AMD Am79C970A
更改后的网卡类型：Intel E1000
3. Host ESX Server硬件的CPU必须支持VT (Virtualization Technology) (如果是AMD CPU，则是AMD-V)
Intel的VT或AMD的AMD-V是在CPU级别提供对虚拟化支持的技术。在ESX Server上安装32位的操作系统，如Windows XP时，打开或关闭VT功能对性能不会造成多大影响，但是在ESX Server上再安装ESX Server时，不使用VT却能让ESX Server虚拟机的启动时间变慢到10倍以上。
（我在不开启VT的情况下，在一台双Xeon CPU，12GB内存的ESX Server 3上安装ESX Server 3i，经过4小时的100%CPU占用率之后我放弃了）
4. 打开VMware的后门
要让ESX 3.5/3i顺利地运行在Host ESX Server上，还需要打开VMware的“后门”，否则很有可能会见到VMware中的“紫屏”（可以和Windows中的“蓝屏”媲美）。
要打开这个后门，允许在虚拟机上安装ESX Server，需要在.vmx文件中增加如下两行：
monitor_control.vt32 = “true”
monitor_control.restrict_backdoor = “true”
monitor_control.restrict_backdoor = “true”
这个后门不仅避免了“紫屏”等死机、不稳定等问题，更是将启动速度再提高10倍。我在打开VT的情况下启动Guest ESX Server花费了30分钟，在即打开VT，又打开这些后门选项之后，只花费了2分钟。
5. 在Host ESX Server上允许Promiscuous Mode
做好上面的一切之后，你应该就可以顺利安装Guest ESX Server了。可是安装完成启动之后，却发现无法通过VirtualCenter来管理它——甚至连ping Guest ESX Server的Service Console都ping不通！这是为什么呢？
原因在于Host ESX Server上，连接着Guest ESX Server的vSwitch的设置。vSwitch默认是不允许promiscuous mode（允许网卡监听发往其他MAC地址的包的模式）的。但是在Guest ESX Server中，网卡只是一个桥接（bridge）作用，并不直接绑定MAC地址。因此，必须在Host ESX Server中允许promiscuous mode，Host ESX Server才能正确地将包传递给Guest ESX Server的Service Console（3i则是管理用IP）。
到这里，就可以体验ESX 3.5/3i的神奇世界了。
Virtual Infrastructure New Features
Nov 13, 2007
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月份推出。