VMwareAppVolumesPOC安装配置文档文档格式.docx
《VMwareAppVolumesPOC安装配置文档文档格式.docx》由会员分享，可在线阅读，更多相关《VMwareAppVolumesPOC安装配置文档文档格式.docx（44页珍藏版）》请在冰豆网上搜索。
AppStackVolume：
包含一个或多个应用程序的虚拟磁盘，以只读模式共享给多个用户使用。
AppStack
Volume分配给指定用户后，里面安装的应用程序就会自动部署到该用户登录的桌面计算机上。
WritableVolume：
一对一分配给不同桌面的虚拟磁盘，每个用户拥有自己的WriteableVolume。
WritableVolumes有3中类型，不同类型可以支持存储不同内容：
UserProfileDataOnly
UserInstalledApplicationsOnly
BothProfileDataandUserInstalledApplications
AppVolumes安装
AppVolumes的安装组件主要包括两部分：
在桌面计算机上安装AppVolumesAgent代理程序；
在管理服务器上（WindowsServer）上安装AppVolumesManager管理程序。
安装AppVolumesAgent
当然通常是先部署好Manager，这里为了文字内容流畅，先介绍Agent的安装过程。
AppVolumesAgent需要安装在用户桌面上，在Horizon环境下先安装在模板机里，这样部署出来的虚拟桌面都具备接收AppVolume的功能了。
***v2.6版本中增加了Broker选项，暂且不用理它~这里填入Manager的DNS名或IP，如果还没装Manager就填预留的，千万别填错，填错得重装一次：
装完要重启一次，如果Manager还没装起来，就等会再重启吧。
安装AppVolumesManager
Manager是AppVolumes的核心组件，负责Volumes的维护和分配，部署过程比较简单。
部署一台新的WindowsServer虚机，这里以WindowsServier2008R2为例，进行Manager的安装部署。
如果你想把它跟Horizon的其它组件部署在一起应该也可以，不过我还没这样干过。
数据库可以选择已有的数据库实例进行安装，如果没有可以选择安装本地数据库，它会帮你装一个SQL
Server2008Express精简版上去。
我选择用已有数据库服务器，方便统一管理。
要在数据库服务器预先创建好数据库，如DB_AppVolMgr，注意数据库上的TCP/IP客户端协议、SQLServerBrowser服务要打开。
这里设置管理界面访问端口，AppVolumesManager默认没有开启https，有点不符合VMware软件的惯例作法（题外了~）
安装完不用重启。
至此，AppVolumesManager管理程序安装完成，可以进行系统初始化工作了。
AppVolumes初始化
在浏览器输入AppVolumesManager的DNS名称或IP地址打开初始化页面：
App_Volumes_26_EULA_enforced_production_license.key
默认的测试license信息（如果你把下载时提供的导进去可以获得一个50000用户无时间限制的license）
一步一步填写活动目录相关信息：
（跟WorkSpace的配置风格类似）
填写vCenterServer及vSphere主机相关信息：
可以勾选”MountOnHost”，支持在vCenterServer不可用情况下直接从vSphere主机挂载，前提所有的vSphere主机都用同一个root密码。
选择AppStack和WritableVolumes两种卷的默认存储位置，可以放一起也可以分开。
建议将AppStack放在读性能好的Datastore上，Writable放在读写性能好的Datastore上。
这里让你选择操作的执行方式是在后台执行还是强制立即执行，安全起见我都选的background
选择将模板Volume上传到哪个Datastore上面，（这里有个bug，后面讲）
确认所有设置ok后，点Next
AppVolumes管理界面一瞥
再次输入AppVolumesManager的地址就会出现管理登录界面了，蜂窝背景显得Hi-tech。
***目前版本还不提供中文界面初次登录进去看到的一片空白：
用起来之后差不多会是这个样子：
AppStacks部分创建AppStack
在Volumes-AppStacks，选择CreateAppStack：
填写AppStacks名称之后，即创建出一个空的AppStacks卷，处于Unprovisoned状态：
选中它，点击Provision，选择一台装有Agent的桌面作为provisioninghost，用于捕获应用：
然后进入到Provisioning状态：
登录到作为provisioninghost的桌面，开始安装应用，确认安装完成后点击”确定”结束Provisioning
Provisioning的过程跟ThinAppCapture的过程类似，但是效率更高，主要体现在：
1、不需要扫描两次比对出差异数据
2、可以一次性捕获多个应用
测试安装了WinRAR和AdobeReader两个软件：
然后确认结束，重启机器。
如果是误点了”确认”还可以选”否”回到provisioning模式。
重启后登录系统，看到捕获成功的信息窗口。
这时候刚才装的两个应用从程序列表里消失了，说明已经成功捕获到AppVolumes的虚拟磁盘里了：
AssignAppStack
回到AppVolumesManager管理界面将这个AppStack卷assign给用户或者桌面：
可以Assign给用户或用户组：
也可以Assign给具体桌面计算机或组织单元OU
将AppStackAssign给用户组之后，以组里的成员用户user02登录桌面，刚捕获的应用程序又回来了：
以用户user02登录另一台桌面vDesktop01，自动在vDesktop01机器上挂载AppStack卷：
磁盘管理里也能观察到多出来的CVApps卷：
更新AppStack
除了创建新的AppStack卷，还可以通过”更新”操作对现有卷进行变更，如应用程序版本更新，增加新的软件组件等。
对于新建的命名可以追加版本号，方便管理和识别：
接下来的过程同第一次创建新AppStack卷的Provisioning过程跟一样，不在介绍。
测试AppStack
这里做一个小测试，验证AppStack卷的只读特性。
以user01登陆vDesktop01，将AppStack里的AdobeReader从10.1.0更新到10.1.14：
更新完成后，在vDesktop01这台机器的AdobeReader版本为：
10.1.14
注销user01，以user02登陆vDesktop02，查看这台机的AdobeReader版本仍然为：
10.1.0：
接着注销user02，以user01登陆vDesktop02，AppStack会自动加载到vDesktop02上：
查看vDesktop02的AdobeReader版本为：
10.1.0。
同样以user02登陆vDesktop01，查看vDesktop01上的AdobeReader版本依然是：
10.1.14。
说明对程序版本的变更并没有保存到AppStack里面，而只是保存在vDesktop02桌面本地磁盘里。
验证了AppStack卷的只读特性。
如果希望用户所做的变更能够被保存下来，并且随着用户登录出现在不同的桌面上，能否实现？
接下
来试试WritableVolume卷。
WritableVolume部分创建WritableVolume
在Volumes-WritableVolumes，选择CreateWritable：
发现没有SourceTemplate可选，但之前已经导入进Datastore了
（就是前面提到的bug，或者说不完善的地方。
原因：
导入templates的时候只提供了一个Datastore
位置，如果Writable卷默认不存储在该Datastore上面，则会找不到writable_templates。
）
不过解决起来并不麻烦，只需要手动将writable_templates目录移到存放writablevolumes的Datastore即可。
这个时候再次创建，安装时候导入的3个SourceTemplate出现了，作用分别是：
只存用户profile，
只存应用，存应用+Profile。
选择template_uia_plus_profile.vmdk这个模板进行创建（后面会对其功能做个测试）：
在创建Writable卷时候同样比较灵活，可以选择基于具体桌面计算机或组织单元OU创建
也可以基于用户或用户组创建。
为了体现AppVolumes的应用分层，以及为不同用户提供个性化应用程序的目的，建议基于用户创建：
创建完成后在列表多出两个WritableVolumes，未加载时是Detached的状态：
展开一个WritableVolume可以进行编辑，建议勾选”BlockLogin”选项：
基于单台计算机创建的Writable卷，机器启动后就会自动挂载上去，不管有没有用户登录；
而基于单个用户创建的Writable卷，只有当用户登录桌面后，才会自动挂载到该桌面机器上。
如果客户机的APPVolumesAgent没安装或状态不正常的话，这里状态会显示Offine：
加载正常的机器上同样会多出一个名为”CVWritable”的磁盘：
测试WritableVolumes
验证Writable卷区别于AppStack卷的一些特性。
Test01：
首先为用户user01创建一个Writable卷：
以user01登录vDesktop01桌面时，user01Writable卷自动加载到vDesktop01计算机上：
在vDesktop01上做一些变更，为了跟上一个测试对比，还是以将AdobeReader版本从10.1.0升级到10.1.14版本为例：
同时，为了验证这个Writable卷是否会存储应用程序和用户Profile数据，在vDesktop01上新安装了Thunderbird软件，并添加了一些Feeds作为用户数据：
然后在vDesktop01上注销user01，以user01登录vDesktop02，登录成功user01对应的Writable卷自动加载到vDesktop01计算机上：
查看vDesktop02上AdobeReader版本已经是10.1.14：
再打开Thunderbird客户端，居然没有刚才添加的Feeds用户数据。
这里我不确定是否我对WritableVolume功能理解有问题，还是测试方法不对。
OK，开始下一个测试。
Test02：
再为用户user01分配一个AppStack卷，这样用户user01同时assign了AppStackVolume和WritableVolume两个卷。
以user01登录到vDesktop01桌面，两个卷会同时附加到vDesktop01上。
从User的视角看：
从桌面计算机的视角看：
说明可以为同一个用户同时分配不同类型的AppVolume卷，互不冲突。
为vDesktop03桌面Assign一个Writable卷，正常情况下该Writable卷自动加载到vDesktop03计算机上：
将user01从vDesktop01桌面注销，再以user01登录到vDesktop03桌面。
当用户user01登录后，vDesktop03仍然只加载了它本身的Writable卷，没有加载user01的两个卷：
说明基于用户分配的卷跟基于计算机分配的卷相冲突，同一台桌面计算机同时只能加载基于用户分配的卷或者基于计算机配方式的卷，不能混合加载使用。
从user01的视角也可以看到，两个卷都没有被加载：
当把vDesktop03的Writable卷禁用后，user01的2个卷加载正常：
一些问题：
在测试过程中遇到一些奇怪的问题，比如：
1、用户登录后提示”已使用临时配置文件登录”：
2、用户登录时提示：
无法加载用户配置文件，换其它没有AssignApp卷的用户登录正常：
3、登录后提示”...Systemprofile\Desktop引用了一个不可用的位置”：
4、AppVolume卷较多时，用户登录login时间比较久，在HorizonView环境下建议用户退出时只用断开虚拟桌面连接，不要注销。
对于这些问题，都没有去深究原因，重启几次或者过段时间问题现象又会自动消失。
另外，我的Horizon环境下同时还部署了PersistentDisk、ThinApp，不确定相互之间是否有冲突导致。
整体而言，AppVolumes的功能还是蛮不错的，很好的实现了应用分层的概念，相当于ThinApp应用打包的增强版，同时又能像托管式应用虚拟化一样有较好的兼容性和运行性能。
希望下一个版本，VMware能将AppVolumes跟Horizon有更好的融合，把应用程序license管理等加进来，功能重复的组件该丢弃的就丢弃了。
-End-
升级会员 