（本读书笔记，摘自《Windows Internals》第4版）

Program和Process看起来是一回事，但是却是完全不同的2个概念。Program是一段顺序排列的指令，而Process是执行Program时所用的那些资源集合的容器(container)，通常包括：

• A private virtual address space
• An executable Program
• A list of open handles to various system resources (比如semaphores, 通讯端口, 或文件)
• A security context called an access token
• A unique identifier call a process ID, that identifies the user, security groups and privileges associated with the  process
• At least one thread of execution

查看Process的方法：(1)用Task Manager (2)用Windows Debug Tools工具中的命令行 tlist /t (3)用Process Explorer (可到这里下载：http://technet.microsoft.com/en-us/sysinternals/default.aspx)

在Task Manager中，右键点击Application名，然后选择“转到进程”可以把一个应用程序和它的进程联系起来。

Process Explorer里面的进程，底色是粉红色说明这个进程Host了service，底色是浅蓝色说明这是个用户进程。

今天有点莫名的兴奋，因为想到即将到来的西湖毅行。

关于环西湖群山的毅行，今年已经走过了2次，却未曾留下片言只语和半张照片。所有的回忆都只有小猪的半篇游记。

2次毅行都没能走到终点。

第一次是5月初，上海今年的夏天来的太早，30+度的天气和没经验的我们，在十里廊当开头的地方就疲惫不堪地下撤了。耗时5个小时，完成度1/3。
第二次是9月初，号称是为了哈巴的拉练。我们早去晚归不留宿杭州，因为早晚火车时间的限制，我们只能从10点走到18点。下雨、迷路，耗时8个小时，没带头灯，走到虎跑正好天黑，于是下撤，完成度2/3。

西湖毅行的攻略称：如果你能在7小时以内走下来，那么你就算是一个合格的新驴了。我们这群老驴拼死拼活，8小时才走了2/3，原来，我们都是“不合格！”

这一次，May的MBA同学要组织一次大规模的慈善毅行，我们起初是冷嘲热讽积极反对的，原因嘛无非是“我们这群老驴都走不下来，上百号人队伍怎么带呀，这种活动怎么可能成功呀？怎么可能有人走完全程呀？”

事情因为May被强制任命为CCO（Chief Charity Officer）而突然转变，我被勒令组织一支队伍来参加这次活动，看了活动的网站，才了解到这次活动是以4个人为一个小组，要求发挥Team Work的精神，中间设几个check point，全组完成才算完成。突然间，想要走完全程的念头冒了出来，而且愈来愈强烈。

好吧，决定第3次赴杭州奔西湖。2008年，突然变成了杭州活动年......

同学们，有兴趣的话，一起来参加这项有意义的活动吧!!
活动网站：http://ilovehiking.com.cn/intro.aspx

今天出丑了。

在和DCC的同事周核对文档的时候，有一处要说明是2年一次，看见她用Biennial这个词，当下表示反对，自以为是的说应该用biannual，因为每年一次是annual，所以2年一次应该是biannual。理由很简单，bi-这个词根是“2的”，比如双周的就是biweekly，2年一次当然是bi-加上annual咯。

好在周很认真的用金山词霸核对了下，这才发现biannual原来是一年两次，而非2年一次。而她的用词biennial才是真的正确的用法。

看来学什么都不能想当然呀。

Kingston 4G u盘变2G问题

由于一台PC系统熄了,无光驱,之前也未做DOS启动菜单之类,故想用手中的U盘引导还原系统,于是找了款制作USB引导的工具,--USBboot,U盘4G,提示必需做为HDD模式,做完偶然发现4G盘居然变为2G了,格式化&找相关修复工具均无奏效,百度&GOOGLE居然也无相关字样,较郁闷,以为盘熄了一芯片,寻思着一片2G,熄一正好余下2G,hoho...得要找JS换货,扯来扯去闹心,格来格去都是2G.突然想到在磁盘管理器里打开看一下,看其到底如何显示,打开所呈现在眼前的画面:

顿时心情舒畅极致,^^,提示未指派,那咱现在就指派,却右键无法指派,余下的就是用不了,又郁闷了,开IE找呀找的,找一U盘工具合集,Down到桌面,找里一工具--UFormat,测试用"0参数重置",--其实就是用0重置U盘的MBR&DBR处理完U盘为RAW格式,再格式化即修复了总容量.

盆盆兄的博客我是一直光顾的，从中获益匪浅。不过，也有不敢苟同之时。

今年情人节，盆盆兄发文：Hyper-V高可用性群集实测报告 （链接如下）
http://blogs.itecn.net/blogs/virtualization/archive/2008/02/14/HypervHA.aspx

文中提到：“例如对于一台1GB内存的虚机，如果共享存储是带宽为1Gb（125MB）的iSCSI，只需约16秒的停机时间（1Gb/8≈125MB，1GB/125MB=8秒，8×2=16秒）；如果是4Gb的光纤存储，则只需约4秒！不同虚机内存和存储带宽所对应的停机时间，如附图所示”


并分析说：“由于VMotion采用后台内存拷贝的模式，只有在拷贝内存位图表时，才会临时中止客户端访问，用户几乎感觉不到服务中断（一般最多1~2秒）

而Hyper-V快速迁移则需要有一个内存状态的保存和恢复时间，根据虚机内存和存储带宽的大小，有少量的服务中断时间（少则1~2秒，多则1~2分钟）。

从原理上讲，Hyper-V采用的是比较简单的内存状态保存的技术，以避免在内存映像传输时，后续的内存写入同步问题，以增加停机时间作为代价，但一般来说这点时间还是可以容忍的，通常不会有损SLA。”

分析的非常好，原理也解释的非常清楚。但是结论却不能苟同。

本人作为一个系统管理员，在日常的维护工作中的经验是，虚拟机所依赖的平台(HOST)，不论是VMWare ESX还是Windows 2008，都会面临常规的安全补丁的安装，并且要求重启。这种常规是每月一次的，而不是每年一次的。但是如果这种常规的重启发生在HOST上，则需要先把此HOST上所有的VM全部迁走。快速迁移的目的就在于此——在VM完全不停机不停止服务的状态下，迁移到其他主机。

从盆盆兄上述表格可以看出，只有非常极端的情况下（512内存并且有4GB FC），Hyper-V的快速迁移才能在2秒左右完成，而大多数情况是，VM至少带有1-2GB内存，链接采用的是1GB的通道。这种情况下，需要16-32秒才能完成迁移。这时候，大多数网络服务都会遭遇失败。也就是说，当Host需要打补丁的时候，就需要快速迁移，而微软的快速迁移需要其上的虚拟机都停止服务32秒，当这些虚拟机处在生产环境的时候，就需要发告示通知所有用户。这给管理带来了很大的麻烦。（即使不是生产环境，比如开发环境，你也得通知用户，即使这些用户也是IT部门，和你关系很铁很哥们） 。所以在我看来，这32秒的中断是不可容忍的。

VMware的VMotion做到了这一点，“用户几乎感觉不到服务中断”。因此任何一次HOST的维护都不需要通知用户，所有VM都保持持续运行，这太棒了！这就是目前我还坚定地支持VMWare的原因。

至于成本，我想，稳定压倒一切，为了可靠性和持续不断的服务，作为跨国企业，不会在乎这点点成本的。