VMware App Volumes POC安装配置文档.doc

VMware App Volumes POC安装配置文档 准备工作环境准备在测试 App Volumes 之前，除了 download App Volumes 的安装光盘 iso 以外，还需要有一套Horizon View 桌面虚拟化环境，或者有套 vSphere 虚拟化环境，以及 Windows AD 域环境。当前版本的 App Volumes 跟 Horizon 的整合度较低，或者基本上没有什么整合，因为你在配置 App Volumes的过程中，不需要在Horizon 中做任何设置，管理起来也是独立的，你需要在 Horizon View Administrator 里管理桌面池、托管应用、托管主机以及 ThinApp，在 APP Volumes Manager 里管理App Volumes 的创建、分配和维护。尽管独立性很高，但 App Volumes 只适用于虚拟化桌面环境使用。以下内容基于 App Volumes 2.6、Horizon View 6.1、vSphere 6.0一点概念正如 App Volumes 的命名一样，它的本质是包含了 Application 的 Volume 卷。不同于 ThinApp 是将单个应用封装在沙盒容器中，App Volumes 是将一个或多个程序封装在虚拟磁盘中。App Volume 有两种类型，具体如下：AppStack Volume：包含一个或多个应用程序的虚拟磁盘，以只读模式共享给多个用户使用。AppStackVolume 分配给指定用户后，里面安装的应用程序就会自动部署到该用户登录的桌面计算机上。Writable Volume：一对一分配给不同桌面的虚拟磁盘，每个用户拥有自己的 Writeable Volume。Writable Volumes 有 3 中类型，不同类型可以支持存储不同内容：User Profile Data OnlyUser Installed Applications OnlyBoth Profile Data and User Installed ApplicationsApp Volumes 安装App Volumes 的安装组件主要包括两部分：在桌面计算机上安装 App Volumes Agent 代理程序；在管理服务器上（Windows Server）上安装 App Volumes Manager 管理程序。安装 App Volumes Agent当然通常是先部署好 Manager，这里为了文字内容流畅，先介绍 Agent 的安装过程。App Volumes Agent 需要安装在用户桌面上，在 Horizon 环境下先安装在模板机里，这样部署出来的虚拟桌面都具备接收 App Volume 的功能了。* v2.6 版本中增加了 Broker 选项，暂且不用理它 这里填入 Manager 的 DNS 名或 IP，如果还没装 Manager 就填预留的，千万别填错，填错得重装一次：装完要重启一次，如果 Manager 还没装起来，就等会再重启吧。安装 App Volumes ManagerManager 是 App Volumes 的核心组件，负责 Volumes 的维护和分配，部署过程比较简单。部署一台新的 Windows Server 虚机，这里以 Windows Servier 2008R2 为例，进行 Manager 的安装部署。如果你想把它跟 Horizon 的其它组件部署在一起应该也可以，不过我还没这样干过。数据库可以选择已有的数据库实例进行安装，如果没有可以选择安装本地数据库，它会帮你装一个 SQLServer 2008 Express 精简版上去。我选择用已有数据库服务器，方便统一管理。要在数据库服务器预先创建好数据库，如 DB_AppVolMgr，注意数据库上的 TCP/IP 客户端协议、SQL Server Browser 服务要打开。这里设置管理界面访问端口，App Volumes Manager 默认没有开启 https，有点不符合 VMware 软件的惯例作法（题外了）安装完不用重启。至此，App Volumes Manager 管理程序安装完成，可以进行系统初始化工作了。- 9 -App Volumes 初始化在浏览器输入 App Volumes Manager 的 DNS 名称或 IP 地址打开初始化页面：App_Volumes_26_EULA_enforced_production_license.key默认的测试 license 信息（如果你把下载时提供的导进去可以获得一个 50000 用户无时间限制的 license）一步一步填写活动目录相关信息：（跟 WorkSpace 的配置风格类似）填写 vCenter Server 及 vSphere 主机相关信息：可以勾选”Mount On Host”，支持在 vCenter Server 不可用情况下直接从 vSphere 主机挂载，前提所有的 vSphere 主机都用同一个 root 密码。选择 AppStack 和 Writable Volumes 两种卷的默认存储位置，可以放一起也可以分开。建议将 AppStack 放在读性能好的 Datastore 上，Writable 放在读写性能好的 Datastore 上。这里让你选择操作的执行方式是在后台执行还是强制立即执行，安全起见我都选的 background选择将模板 Volume 上传到哪个 Datastore 上面，（这里有个 bug，后面讲）确认所有设置 ok 后，点 NextApp Volumes 管理界面一瞥再次输入 App Volumes Manager 的地址就会出现管理登录界面了，蜂窝背景显得 Hi-tech。*目前版本还不提供中文界面初次登录进去看到的一片空白：用起来之后差不多会是这个样子：AppStacks 部分创建 App Stack在 Volumes - AppStacks，选择 Create AppStack：填写 AppStacks 名称之后，即创建出一个空的 AppStacks 卷，处于 Unprovisoned 状态：选中它，点击 Provision，选择一台装有 Agent 的桌面作为 provisioning host，用于捕获应用：然后进入到 Provisioning 状态：登录到作为 provisioning host 的桌面，开始安装应用，确认安装完成后点击”确定”结束 ProvisioningProvisioning 的过程跟 ThinApp Capture 的过程类似，但是效率更高，主要体现在：1、 不需要扫描两次比对出差异数据2、 可以一次性捕获多个应用测试安装了 WinRAR 和 Adobe Reader 两个软件：然后确认结束，重启机器。如果是误点了”确认” 还可以选”否”回到 provisioning 模式。重启后登录系统，看到捕获成功的信息窗口。这时候刚才装的两个应用从程序列表里消失了，说明已经成功捕获到 AppVolumes 的虚拟磁盘里了：Assign App Stack回到 App Volumes Manager 管理界面将这个 App Stack 卷 assign 给用户或者桌面：可以 Assign 给用户或用户组：也可以 Assign 给具体桌面计算机或组织单元 OU将 AppStack Assign 给用户组之后，以组里的成员用户 user02 登录桌面，刚捕获的应用程序又回来了：以用户 user02 登录另一台桌面 vDesktop01，自动在 vDesktop01 机器上挂载 AppStack 卷：磁盘管理里也能观察到多出来的 CVApps 卷：更新 App Stack除了创建新的 App Stack 卷，还可以通过”更新”操作对现有卷进行变更，如应用程序版本更新，增加新的软件组件等。对于新建的命名可以追加版本号，方便管理和识别：接下来的过程同第一次创建新 App Stack 卷的 Provisioning 过程跟一样，不在介绍。测试 App Stack这里做一个小测试，验证 App Stack 卷的只读特性。以 user01 登陆 vDesktop01，将 AppStack 里的 Adobe Reader 从 10.1.0 更新到 10.1.14：更新完成后，在 vDesktop01 这台机器的 Adobe Reader 版本为：10.1.14注销 user01，以 user02 登陆 vDesktop02，查看这台机的 Adobe Reader 版本仍然为：10.1.0：接着注销 user02，以 user01 登陆 vDesktop02，AppStack 会自动加载到 vDesktop02 上：查看 vDesktop02 的 Adobe Reader 版本为：10.1.0。同样以 user02 登陆 vDesktop01，查看 vDesktop01 上的 Adobe Reader 版本依然是：10.1.14。说明对程序版本的变更并没有保存到 AppStack 里面，而只是保存在 vDesktop02 桌面本地磁盘里。验证了 AppStack 卷的只读特性。如果希望用户所做的变更能够被保存下来，并且随着用户登录出现在不同的桌面上，能否实现？接下来试试 Writable Volume 卷。Writable Volume 部分创建 Writable Volume在 Volumes - Writable Volumes，选择 Create Writable：发现没有 Source Template 可选，但之前已经导入进 Datastore 了（就是前面提到的 bug，或者说不完善的地方。原因：导入 templates 的时候只提供了一个 Datastore位置，如果 Writable 卷默认不存储在该 Datastore 上面，则会找不到 writable_templates。）不过解决起来并不麻烦，只需要手动将 writable_templates 目录移到存放 writable volumes 的 Datastore 即可。这个时候再次创建，安装时候导入的 3 个 Source Template 出现了，作用分别是：只存用户 profile，只存应用，存应用+Profile。选择 template_uia_plus_profile.vmdk 这个模板进行创建（后面会对其功能做个测试）：在创建 Writable 卷时候同样比较灵活，可以选择基于具体桌面计算机或组织单元 OU 创建也可以基于用户或用户组创建。为了体现 App Volumes 的应用分层，以及为不同用户提供个性化应用程序的目的，建议基于用户创建：创建完成后在列表多出两个 Writable Volumes，未加载时是 Detached 的状态：展开一个 Writable Volume 可以进行编辑，建议勾选”Block Login”选项：点击上图圈的小箭头可以跳转到计算机目录，查看对应计算机的卷加载状态。基于单台计算机创建的 Writable 卷，机器启动后就会自动挂载上去，不管有没有用户登录；而基于单个用户创建的 Writable 卷，只有当用户登录桌面后，才会自动挂载到该桌面机器上。如果客户机的 APPVolumes Agent 没安装或状态不正常的话，这里状态会显示 Offine：加载正常的机器上同样会多出一个名为”CVWritable”的磁盘：测试 Writable Volumes验证 Writable 卷区别于 App Stack 卷的一些特性。Test 01：首先为用户 user01 创建一个 Writable 卷：以 user01 登录 vDesktop01 桌面时，user01 Writable 卷自动加载到 vDesktop01 计算机上：在 vDesktop01 上做一些变更，为了跟上一个测试对比，还是以将 Adobe Reader 版本从 10.1.0 升级到 10.1.14 版本为例：同时，为了验证这个 Writable 卷是否会存储应用程序和用户 Profile 数据，在 vDesktop01 上新安装了 Thunderbird 软件，并添加了一些 Feeds 作为用户数据：然后在 vDesktop01 上注销 user01，以 user01 登录 vDesktop02，登录成功 user01 对应的 Writable 卷自动加载到 vDesktop01 计算机上：查看 vDesktop02 上 Adobe Reader 版本已经是 10.1.14：再打开 Thunderbird 客户端，居然没有刚才添加的 Feeds 用户数据。这里我不确定是否我对 Writable Volume 功能理解有问题，还是测试方法不对。OK，开始下一个测试。Test 02：再为用户user01 分配一个AppStack卷，这样用户user01同时assign了AppStack Volume和Writable Volume 两个卷。以 user01 登录到 vDesktop01 桌面，两个卷会同时附加到 vDesktop01 上。从 User 的视角看：从桌面计算机的视角看：说明可以为同一个用户同时分配不同类型的 App Volume 卷，互不冲突。为 vDesktop03 桌面 Assign 一个 Writable 卷，正常情况下该 Writable 卷自动加载到 vDesktop03 计算机上：将 user01 从 vDesktop01 桌面注销，再以 user01 登录到 vDesktop03 桌面。当用户 user01 登录后，vDesktop03 仍然只加载了它本身的 Writable 卷，没有加载 user01 的两个卷：说明基于用户分配