目前本本的独立显卡的设计有三种：一为焊接式，既移动芯片直接焊接在主板上，此种方案设计复杂但占用空间小，多用于轻薄和超轻薄笔记本中。第二种为针脚兼容式，既图形芯片厂商推出的移动图形芯片与前一代芯片在针脚上完全兼容，这样笔记本制造厂商便可以将它已有的电路模块中无需重新设计，由此可以缩短设计时间。第三种为ATI和NVIDIA所推出的模块形式，该模块包括移动图形芯片和显存，通过模块底部的触点与主板焊接。但这三种有一个共同点就是都不能进行随意的更换。而且存在一个致命的弊端：从产品发布到对应的笔记本电脑上市，中间往往间隔漫长的时间。
从部署在测试环境的探索到生产环境的实践，OpenStack是一个灵活性非常强的云管理平台，各个组件开源独立，组合多样。自然就增加了安装和运维的复杂性和难度。为了让企业云计算工程师在日常运维管理openstack平台的时候能更好的互助解决遇到的坑和难点问题，社区日前组织了交流，本文将活动中大家交流的一些典型问题整理分享给读者。整理者：Garyy
1、如何把原有虚拟化下的系统迁移到OpenStack集群？哪种方案可行并更方便？
【问题描述】如何把在vmware下的应用系统整体平滑迁移至openstack集群？1.虚拟机vmdk文件倒进倒出；2.在openstack集群新搭建虚拟机，进行业务系统迁移。哪种方案可行并更方便？
@潘延晟 系统工程师：
虽然第二种方式麻烦一些。不过终究还是比较稳妥的一种可进可退的方案。只是在一些实际环境中。一些应用过老。文档资料不全。技术支持中断等原因导致没有办法搭建一个新的环境。而不得不被迫采用V2V的方式。
我觉得还是要根据具体情况详细分析。针对所有的业务来制定适合的方案。如果可以新建环境进行业务迁移固然最好。如果新环境没办法成功搭建。考虑V2V的方式。也并不一定就是九死一生，做好虚拟机备份在进行迁移也未尝不可。
@youki2008 广东溢达 系统架构师：
为了业务的平稳迁移，建议采用第2中方案。虽然第1种的方案操作简单，但是vmdk磁盘格式转换的过程中有可能会出错。
@chinesezzqiang 信息技术经理：
根据项目经验，建议是重新建立VM，进行数据层的迁移，而不是VM的迁移，虽然vmdk可以转换，但是风险很高。
@liujinlong 项目经理：
从工作简便易行上是第一种。
从易用兼容是第二种，取决于你的数量级以及迁移时间与应用可接受的方式，看有没有应用组支撑您重新部署，如果没有就考虑第一吧，v2v把vmdk倒出，然后转换qcow2。但是可能会有兼容性或者倒出损坏的问题。
@hongtu_zang 中信科技发展有限公司 技术经理：
在Openstack集群新搭建虚拟机，进行业务系统迁移。
虚拟机导出导入之后，不能保证原有的程序一定可以正常运行。也不好保证vmdk在做v2v转换之后就一定不会损失格式或者有虚拟化格式之后的效率损失。
迁移在大多数情况下比较靠谱，可以充分测试没问题之后再切换业务入口。
也可以两种同时进行，对于不同业务选择不同的迁移方案。
个人意见是尽量多的选择2。
2、OpenStack 与 K8S 容器平台的融合方案？
【问题描述】
背景环境：我们公司目前有两个轻量级的验证性平台。一个是基于 OpenStack P版本的 IaaS 云平台，一个是基于 K8S 1.8版本的容器平台，都是使用的社区版本进行的构建，并且在进行了验证之后将公司内部的应用系统迁移到了云平台上，将与项目、研发等相关的产品迁移到了容器平台上。经过一年多的运行之后，现在因为管理上的需要，规划将两个平台进行整合，方便进行统一的管理。
现场信息：云平台有10台主机，容器平台5台主机
已有的思考和尝试：当前的想法是准备采用在云平台上开设虚机主机，通过虚拟主机的环境重新构建一套新的 K8S 环境，对现有容器平台的业务进行迁移。遇到的难点在于有些容器平台上的业务对性能要求比较高，经过这样两层包装处理性能衰减的会比较多，影响运行的效率。另外，还有一块儿我们的部分业务是需要直接和主机的外接物理设备进行通讯和交互处理的，在本身只有一层平台的时候配置虚拟主机或者容器可以访问到该硬件资源就比较复杂了，现在如果变成两层结构的话，感觉实施部署以及出现故障之后的排故，都会变的很复杂。
但之前有想尝试通过 K8S 来打包 OpenStack，但结果尝试失败了，也没找到比较合适的开源方案，而且感觉容器平台上部署云平台的思路，也有点儿本末倒置，就放弃了。
希望专家能够提供一些方案性的建议，如果可以的话最好是基于开源的方案，以及一些思路。
@Garyy 某保险 系统工程师：
目前在 OpenStack 上部署 Kubernetes 有多种方式：
//Tectonic
由 CoreOS 开发，是开源企业级的 Kubernetes 部署解决方案，对 Kubernetes 做了一些改造，支持多集群管理（也就是支持多租户管理），更流畅的图形化管理等。但 Tectonic 主要的目标是在公有云上部署，比如 GCE、AWS 等，虽然也开始支持 OpenStack 等私有云，但目前还不够成熟，处于 pre-alpha 阶段，所以暂不考虑。
//kops
由 Kubernetes 社区开发，是一个部署 Kubernetes 的命令行工具，和 Tectonic 一样，主要的目标也是在公有云上部署 Kubernetes，而且对 OpenStack 的支持也不算好，目前处于 Alpha 阶段。所以 kops 也不予考虑。
//kubeadm
由 Kubernetes 社区开发，是 Kubernetes 目前官方推荐的部署方式，大幅简化了 Kubernetes 的部署复杂度，但依旧需要较多的手动操作，而且这和在裸机上部署是没有任何区别的，对 Kubernetes 没有任何的功能增强。但是可以考虑在其他方案实施难度较大时，作为备选方案：先用 kubeadm 在 OpenStack 上手动搭建好环境，做成镜像，再使用 cloud-init 注入个性化数据（可能这部分的工作量也不小）。
@郑金辉 中国电信系统集成公司 技术总监：
本来通过 Magnum 可以实现K8s在openstack环境下的部署，可你的实际情况又不允许，这就不好办了。你或者可以试着按照社区里面那样实现K8s和openstack各个组件的对接，但是工作量可不小。
3、公司规划基于OpenStack开源架构方面的进行存储统一管理，是否有好的解决方案？
【问题描述】目前公司规划基于openstack开源架构方面的进行存储统一管理（例如对接ceph，或者对接glusterfs）但是开源存储针对openstack 页面管理等没有很好的支持，是否有好一些的解决方式?
@zhuqibs Mcd 软件开发工程师：
对于开源的存储解决方案，都是不稳定的，比如glusterfs，就经常不可读，冒bug，让你不得不重启，总之，我们吃过无数的苦头。Ceph也一样，不过社区支持好，遇到问题总有前辈来解决。
所以，如果你一定要上开源的分布式存储，建议上ceph、hdfs等社区活跃的分布式存储。ceph虽然源于openstack，但目前使用的领域已经远远不限于openstack了。当然openstack对它的支持是原生的，最好的。 如果你再不放心，就只能去买华为的分布式存储，性能很不错。
奥，对了，你可能意思是没有”界面‘’管理，不过你放心，ceph的新版本自己有比较好的管理界面了。
@youki2008 广东溢达 系统架构师：
OpenStack私有云中，对传统存储的自动化统一管理，其实还是需要利用传统存储的自身工具，再开发一个统一的界面来进行管控。
4、OpenStack的nova接管vSphere时需注意什么问题？
@zhuqibs Mcd 软件开发工程师：
nova-scheduler 可调度的 nova-compute 可以有多个，并且每个 nova-compute 对应了 vSphere 上的一个 Cluster ,每个 Cluster 又都要有一个 Datastore 进行配置和使用。
通过 Openstack 来创建 vSphere 的虚拟机后，虚拟机在 vCenter 的总控界面中会得到呈现，并且可以支持 VMware 的高级功能。除此之外，在 Horizon 中也会得到呈现，能够像管理其他 Openstack 虚拟机一样管理 vCenter 中的虚拟机，但也可能会存在部分 VMware 的功能限制(如ssh keys等)。
@youki2008 广东溢达 系统架构师：
逻辑上看，OpenStack与vCenter直接通信，VC管理整个ESXi集群，vMotion、HA、DRS也都能用了。但vCenter从Nova-Compute中抽离出了ESXi主机，Nova-Scheduler将整个自管理的集群作为一个独立主机接入——这会导致一些问题，大致特点如下：
不同于基于内核的hypervisor，vSphere需要一个单独的vCenter主机，VM是运行在ESXi主机上而不是计算节点上。
尽管OpenStack已支持多hypervisor，但一个计算节点同时只能支持一种hypervisor。因此，multi-hypervisor的OpenStack混合云，对于每一种hypervisor类型就至少要有一个计算节点来对应。
VCDriver有限制，每个Nova-Compute服务仅能对应一个vSphere集群。当计算节点作为VM运行在同一集群下时，就具有了HA能力。
VCDriver中每个cluster都要有一个datastore来进行配置和使用。
5、Zabbix 监控OpenStack虚拟机选择什么方式？
【问题描述】使用了openstack 私有云，被迫研究监控。想法是，使用zabbix监控 openstack云主机。
一种方式：在云主机中安装 zabbix客户端，这个不讨论了。
另一种方式：zabbix连接 openstack。
查看了一些 zabbix的模板，实现不了云主机的监控，目前还在困惑中。
@zhuqibs Mcd 软件开发工程师：
分两层，不要混淆。
对于用户层，只需要知道Iaas层的云虚拟机是否正常，当然是在openstack用zabbix来监控Iaas层的实例，这没有毛病是必须的。
对于底层，openstack集群的服务器的监控，当然你也可以用zabbix，是用内部的那个，还是自搭，我建议后者，由于网络的原因，最好不好混起来。
@youki2008 广东溢达 系统架构师：
我们的做法是采用第一种方式：在云主机中安装 zabbix客户端。第二种方式使用zabbix连接openstack监控云主机的话，监控的内容没有第一种方式多，只能简单的监控云主机的状态。
@Garyy 某保险 系统工程师：
推荐第一种方案，openstack的监控这块做得并不好
如果通过openstack中转的话，很多方面会收到openstack社区的限制
我们通过prometheus实现的。
6、OpenStack的实施中遇到的难题？
【问题描述】在使用商用openstack产品，在纳管VMware的vCenter时是如何能匹配OpenStack产品的上层组织架构（如多租户的情况）进而有效避免多次重复纳管，在接管vcenter时如何能保证网络的正常使用，对网络的影响最小？在哪些操作的时候，对网络有影响？请专家给点意见呗。
@Garyy 某保险 系统工程师：
1.根据VMWare中的VM所在的网络信息，在Openstack中创建对应的网络，VLAN ID保持一致
2.在OpenStack中创建port对象，MAC地址保持与VMWare中VM的MAC地址一致
3.在OpenStack中创建VM对象，UUID保持与VMWare中VM的UUID一致
4.将新创建的VM对象连接到分布式vSwitch
5.将新创建的VM的VNC端口打开，以支持远程访问
方案的核心思想是在OpenStack里增加一个与创建VM过程类似的纳管过程，输入被纳管VM的IP、MAC、CPU和内存规格、操作系统等信息，将创建VM的各环节在OpenStack里跑一遍，从而在OpenStack数据库中构造被纳管的VM相关的配置管理数据，但在最后一步并不将相关指令真正下发到vCenter。
@asdf-asdf cloudstone 研究学者：
openstack产品纳管vmware稳态计算资源时候，网络部分需要根据稳态网络变化来进行对应调整。这个联动技术，目前定义为云网联通,，意思就是和云环境(openstack)进行联动变化。稳态网络变更时候需要调用云网(openstack接口)完成sdn的网络变化，下策略到sdn中使其能适应稳态网络环境的变化。这个技术需要单独适应客户环境化开发(客制化)开发.比较难处理的一部分业务内容 。
7、OpenStack中的内部组件是靠什么通讯的？如何保证通讯的可靠性？
@youki2008 广东溢达 系统架构师：
OpenStack 组件之间的通信分为四类：
1 基于 HTTP 协议
2 基于 AMQP(Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议) 协议（基于消息队列协议）
3 基于数据库连接（主要是 SQL 的通信）
4 Native API（基于第三方的 API）
基于HTTP协议进行通信：
通过各项目的 API 建立的通信关系，基本上都属于这一类，这些 API 都是 RESTful Web API，最常见的就是通过 Horizon 或者说命令行接口对各组件进行操作的时候产生的这种通信， 然后就是各组件通过 Keystone 对用户身份进行校验，进行验证的时候使用这种通信，还有比如说 Nova Compute 在获取镜像的时候和 Glance 之间，对 Glance API 的调用， 还有比方说 Swift 数据的读写，也是通过这个 HTTP 协议的 RESTful Web API 来进行的。
基于高级消息队列协议：
基于 AMQP 协议进行的通信，主要是每个项目内部各个组件之间的通信，比方说 Nova 的 Nova Compute 和 Scheduler 之间，然后 Cinder 的 Scheduler 和 Cinder Volume之间。
需要说明的是，Cinder 是从 Nova Volume 演化出来的，所以 Cinder 和 Nova 之间也有通过 AMQP 协议的通信关系，由于 AMQP 协议进行通信也属于面向服务的架构， 虽然大部分通过 AMQP 协议进行通信的组件属于同一个项目，但是并不要求它们安装在同一个节点上，给系统的横向扩展带来了很大的好处，可以对其中的各个组件分别按照他们负载的情况进行横向扩展，因为他们不在一个节点上，分别用不同数量的节点去承载它们的这些服务。
（ AMQP 是一种协议，OpenStack 没有规定它是用什么实现，我们经常使用的是 Private MQ，实际上用户也可以根据自身的情况选择其它的消息中间件。）
基于SQL的通信：
通过数据库连接实现通信，这些通信大多也属于各个项目内部，也不要求数据库和项目其它组件安装在同一个节点上，它也可以分开安装，还可以专门部署数据库服务器， 把数据库服务放到上面，之间通过基于 SQL 的这些连接来进行通信。OpenStack 没有规定必须使用哪种数据库，虽然通常用的是 MySQL
通过Native API实现通信：
出现在 OpenStack 各组件和第三方的软硬件之间，比如说，Cinder 和存储后端之间的通信，Neutron 的 agent 或者说插件和网络设备之间的通信， 这些通信都需要调用第三方的设备或第三方软件的 API，我们称为它们为 Native API，那么这个就是我们前面说的基于第三方 API 的通信。
@Garyy 某保险 系统工程师：
我们知道对Openstack的各个组件（nova，cinder，neutron等）来说，跨组件交互时使用的是RestAPI相互调用公共接口，组件内部各个进程间通信时使用RPC消息通信，从而实现各组件、各进程之间的解耦。Openstack RPC（Remote Producer Call）机制基于AMQP（Advanced Message Queuing Protocol）协议，搭配各种消息服务器（RabbitMQ，Qpid等）实现各个组件内部进程间的消息传递。
AMQP是一个提供统一消息服务的应用层标准协议，基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品、不同开发语言等条件的限制，实现异步通信。
RPC.call：发送请求到消息队列，等待返回最终结果。
RPC.cast：发送请求到消息队列，不需要等待最终返回的结果。
在AMQP模型中，几个主要功能模块连接成一个处理链完成预期的功能：
Publisher：消息发送者，将消息发送到 Exchange。
Message：由Header和Body组成，Header是由Publisher添加的各种属性的集合，包括Message是否被持久化、由哪个Message Queue接受（Routing Key）、优先级是多少等。而Body是真正需要传输的数据，它是对Server不可见的二进制数据流，在传输过程中不受影响……
Exchange：接收发布应用程序发送的消息，并根据Routing Key和Binding信息、Exchange Type等参数将这些消息路由到消息队列。
Binding：关联Exchange和Message Queue，提供路由规则。
Message Queue：存储消息，直到这些消息被消费者安全处理完为止。
Consumer：消息接受者，从 Message Queue 获取消息。
使用这个模型我们可以很容易的模拟出存储转发队列和主题订阅这些典型的消息中间件概念。
AMQP是非对称的，客户端生产和消费消息，服务器存储和路由这些消息。一个AMQP服务器类似于邮件服务器，Exchange类似于消息传输代理（email里的概念），Message Queue类似于邮箱。Binding定义了每一个传输代理中的消息路由表，发布者将消息发给特定的传输代理，然后传输代理将这些消息路由到邮箱中，消费者从这些邮箱中取出消息。
AMQP模型中不同类型的Exchange对应不同的routing算法：
Direct Exchange：Point-to-Point 消息模式，Direct Exchange 根据 Routing Key 进行精确匹配，只有对应的 Message Queue 会接收到消息。
Topic Exchange：Publish-Subscribe（Pub-sub）消息模式，Topic Exchange 根据 Routing Key 进行模式匹配，只要符合模式匹配的 Message Queue 都会收到消息。
Fanout Exchange：广播消息模式，Fanout Exchange 将消息转发到所有绑定的 Message Queue。
@zhuqibs Mcd 软件开发工程师：
楼上的兄弟回答的很全面了，但问的是内部组件，我只摘录一段：
rabbitmq是openstack的内部默认队列 ，非常关键，一旦阻塞或宕了，整体openstack就会全跨。原生的没有高可用，但如果真上生产，一定要要配置高可用。
基于高级消息队列协议：
基于 AMQP 协议进行的通信，主要是每个项目内部各个组件之间的通信，比方说 Nova 的 Nova Compute 和 Scheduler 之间，然后 Cinder 的 Scheduler 和 Cinder Volume之间。
需要说明的是，Cinder 是从 Nova Volume 演化出来的，所以 Cinder 和 Nova 之间也有通过 AMQP 协议的通信关系，由于 AMQP 协议进行通信也属于面向服务的架构， 虽然大部分通过 AMQP 协议进行通信的组件属于同一个项目，但是并不要求它们安装在同一个节点上，给系统的横向扩展带来了很大的好处，可以对其中的各个组件分别按照他们负载的情况进行横向扩展，因为他们不在一个节点上，分别用不同数量的节点去承载它们的这些服务。
（ AMQP 是一种协议，OpenStack 没有规定它是用什么实现，我们经常使用的是 Private MQ，实际上用户也可以根据自身的情况选择其它的消息中间件。）
8、同城双活数据中心机房如何规划使用OpenStack产品？
【问题描述】商用openstack产品时，对不同同城双活中心机房，如何进行纳管vmware的 vcenter，对纳管同城双活机房的Laas层的资源，架构如何规划，在实施过程中，请专家们在有这方便的多介绍一下经验，进而让大家尽量避免少跳坑，进而提高业务的连续性。
@Garyy 某保险 系统工程师：
同城的双数据中心和异地中心通过专线互联，搭建大二层网络，并实现数据中心业务数据二层网络的联通，真正意义的实现了计算、存储、网络资源的统一管理统一调度。配合业务应用的高可用设计，可以实现同城双活数据中心中有一个出现故障，可以由另一个中心无缝接替业务，业务连续运行，用户使用无感知。而如果出现重大事故，同城的两个双活中心都出现故障，异地的灾备中心可以分钟级启动并承载业务，从而最大限度保障业务连续性。
OpenStack采用multi-region方式，将平台可以部署在3个数据中心，其中两个为同城双活数据中心实现业务无缝切换，和一个为异地容灾中心，实现在同城的主数据中心出现重大故障的情况下，分钟级业务切换。同时3个数据中心采用统一接口对接上层云资源管理平台，集中化的认证keystone。各个数据中心的基础资源有独立调度平台。
@asdf-asdf cloudstone 研究学者：
每个数据中心部署 openstack云平台(虚拟化平台)区域，统一由上层云管理平台完成纳管，vmware区域由openstack的 wmware的纳管接口完成纳管，资源规划需要详细调研你的业务云化需求。
方案参考 vmware的一个虚拟化资源池由48个服务器构成，每16个服务器一个机柜，内部部署vc等关联系统，接入传统网络环境,IP地址等按照稳态计算环境部署(传统虚拟化环境)。
openstack一个虚拟化资源池区域 15台服务器组成一个区域，3个控制节点，其他是计算节点，接入硬件SDN构成租户方式的云化虚拟化环境，通过弹性ip和外部系统完成互联。
两个底层虚拟化技术通过云管理平台完成互联互动,对SDN进行集成(创建vmware系统的vm后，调用sdn接口完成网络配置下发)。
要求实现
双活需要每个数据中心部署对应的虚拟化池，上层统一管理，对vmware资源池要提前规划好所需资源包括IP地址、网络vlan、存储空间等, 尤其网络部分需要完整规划避免日后有过多变更。
openstack由于云化管理为敏态技术，sdn 加持可通过接口后期定义完成网络变化。
双活的核心业务系统需要安装业务需求完成规划部署，在两个数据中心实现双活运行，先规划好基础的云架构，然后挑选一个业务系统进行测试部署，测试成功后可推广实施。对于不适用的稳态业务系统, 目前还是应按照稳态技术进行部署在vmware中。
9、Openstack刚填好坑，更新版本后又要填坑，如何才能高效的运维，避免踩坑？
【问题描述】Openstack的坑是超多的，有的同学说不惧怕填坑，我要说等你填完，半年时间又上一个新版本，难道你继续填坑？如何才能高效的运维，避免踩坑？听听大家日常运维经验！
@zhuqibs Mcd 软件开发工程师：
无法，因为软件的更新迭代太快了，你看现在大家学习都不去书店了，为什么能，一方面是因为电子书，但更重要的原因是软件更新太快，写书的都写不过来了，写好书，可能写书的版本就被淘汰了，所以，现代IT学习都靠原版的document。 所以，你要“高效运维”， 除非你不改版本。
（1） 选用成熟开源软件，github上star低于200的，坚决不碰；
（2） 选用LTS版本，稳定版；
（3） 不追逐潮流，基本上2年内，不更新版本。
@chinesezzqiang 信息技术经理：
简单来说的话：
1.有开发能力的单位是不惧怕的，但是运维成本超高；
2.没有开发能力的，建议使用成熟的商业套件；
3.无论开源还是商用，必须要做好架构的高可用和存储的高可用。
10、OpenStack如何与Kubernetes做整合？
@zhuqibs Mcd 软件开发工程师：
vmware + Kubernetes = PKS， 可以做私有云的商业化部署；
openstack也有自己的组件marathon来对接docker容器，不过，方向错了，应该去对接Kubernetes，结果却是docker。
所以，要把openstack和Kubernetes整合，只能由openstack构建虚机Iaas，Kubernetes在虚机实例上建立集群。但很不稳定，因为openstack不稳定啊。 所以，现在都是由公有云厂商，对openstack的改进后，再和Kubernetes整合； 分为全托管（只管用集群）+半托管（master节点不管）+自建三种模式.
@youki2008 广东溢达 系统架构师：
openstack与k8s关注的层面不一样， OpenStack关注IaaS资源以及管理，K8S专注容器，没必要整合在一起吧。
@chinesezzqiang 信息技术经理：
这是两种不同的技术，同时是两种不同的虚拟化层面。openstack关注IAAS，k8关注的是容器。两者可以独立使用，也可以融合使用。
@俞黎敏 IBM广州 软件开发工程师：
OpenStack提供IaaS资源以及管理，K8S负责CaaS管理，K8S专注在容器这一层。
11、OpenStack虚拟机、裸金属的OS agent应该如何统一嵌入？
【问题描述】在构建基于OpenStack的云解决方案，虚拟机、裸金属往往需要使用一个带内agent帮助其中的监控、管理（如修改密码）能力补齐。但在虚拟机、裸金属两种典型不同的计算实例场景下，如何做到其统一嵌入agent是一个比较难的问题，涉及几个点：
1.虚拟机、裸金属镜像统一是各云特别是公有云积极尝试的点，如果裸金属、虚拟机各自嵌入的agent不同，那镜像统一难度又将变大；
2.按照OpenStack已有的虚拟机方案，其默认使用的qga使用虚拟机的VirtIO serial保证平台与agent通讯的，裸金属目前没有此方案，且在裸金属之上实现虚拟的VirtIO serial难度也较大；
以上，抛出这个问题，暂不了解AWS、阿里云为代表的公有云都是如何实现的，如有大神了解，请帮忙介绍下。
@付广平 民生银行 研发工程师：
qga是通过compute节点socket与虚拟机serial隧道建立通信的，这种方案只适用于虚拟机，裸机无法支持。
目前OpenStack好像还没有统一的OS agent可以同时适用虚拟机和裸机，可以参考trove guest agent自己写一个应用层agent实现如监控、修改密码等功能。
AWS也是通过应用agent进行监控和管理的，可以参考ssm-agent。
@chinesezzqiang 信息技术经理：
据我所知，这两个方案是独立的。
1.虚拟机是使用qga来监控虚拟机的，不适合裸金融的使用；
2.其他的平台，如阿里、腾讯等用的是自开产品；
3.建议在openstack环境内部署saltstack等类似的运维自动化软件，便于监控和维护。
