按照官方的wiki，我们亦可以分如下几类：
- 虚拟化
- Ovirt可以做到将当前的内存state做到快照里了，而不是以前仅仅可以实现磁盘的状态。当然这个要依赖于libvirt>1.0.1, 但是有个bug，那就是当有spice的session时，Qemu会崩溃。更多信息请猛击这里。
- HTML5的火热程度似乎已经过去，Ovirt作为B/S的选择，这个似乎是绕不过去的，从上个版本的网络配置就可看出一些端倪，当然GWT的进展也是决定其UX的一个因素，比如从3.0之后的UserPortal的变化。那么关于从门户直接访问虚拟机，3.3版本的更新体现在访问协议的实现，分别noVNC和spice for html5,当然和本地客户端相比，还是有很多事情要做的。
- RDP的支持可以不必强制浏览器的activeX的支持，可以选择将VM的信息按照rdp客户端的格式保存，这个作为linux用户，我就不作任何的点评了。
- 支持了虚拟机实例的选择，这个是借鉴了IaaS平台的理念，如AmazonEC2,OpenStack都的instance type的选择，Ovirt主要是扩充了模板的概念，3.3以前的版本，模板的制作是没有多大灵活性的，这个其实个人不是太赞成这样的做法，这个是和Ovirt的设计初衷有点偏离的，希望不要偏的太远，目前还可以接受。
- 虚拟机的OS类型使用配置文件替代VmOsType.java的静态定义，这是个蛮大的进步，说明了Operations团队的介入，而不是程序员的主观臆断。关于具体配置项，见官方wiki.
- 3.3之前的版本，集群的类型选择决定了虚拟机的类型，如cpu的型号支持，3.3实现了模拟，即qemu的 -M 选项。
- Ovirt目前支持了光纤、iscsi、posix、NFS、local的方式的存储，现在加上了glusterfs，虽然原来可以基于nfs或posix来加载，但是大家知道gluster 3.4发布后，qemu可直接访问glusterfs的存储，无须通过其它translate来完成，这个特性的支持，算是redhat给其storage产品寻找着出路。
- 集成cloud-init，在部署虚拟机的时候，这个工具还是蛮有用处的，如网络，ssh key,时区、用户数据注入等，类似openstack的heat项目，尤其是批量在池中建立linux发行版的虚拟机的时候，工作流程：
b、安装操作系统
c、安装cloud-init
d、在此可选是否建立模板
e、配置cloud-init,在ovirt3.3中可使用webadmin、RESTful API，以及挂载预定义的磁盘（vm payload）
f、启动虚拟机
g、耐心等待cloud-init的配置生效
h、虚拟机配置完成并可以直接使用。
是不是很像微软的syspre技术？不过比那个东西好使多了。
- 基础支撑平台
- 设备自定义属性，如果大家熟悉vm-manager或者是熟悉qemu命令行参数的话，或者是熟悉libvirt的xml文件的话，知道虚拟机的外设是有很多可以选择和定义的，Ovirt3.3来的晚了一些，如：磁盘、网卡、显卡、声音、通道、智能卡、watchdog等等。抱歉！我来晚了！
- SDK有了java的版本了，类似早些实现的python-sdk,相信不久的将来ruby、go之类的会接踵而至的。
- SupperVDSM的改进，原来的设计有些不合理的地方，比如vdsmd启动起来，使用root的授权进而启动suppervdsm.于是有此改进，详情参考这里。
- 由于plugin的引进，外部程序的执行可能还含有子程序，所以通过RESTful API定义额外的任务成为必须。
- 异步任务的管理程序改进，增加了纠错能力，如后端的vdsm程序崩溃引起的任务id丢失等，详情参考这里.
- ssh增强，在以前的版本中使用host-deploy或升级node仅使用用户名(root)和密码来做认证，现在可以使用公钥认证或任意的授权的用户来升级node.
- ssh模拟fencing,这是在用户没有电源管理的情况下的一个测试环境或模拟fencing状态的一个替代方法，即当主机失去相应的时候，此功能会尝试通过ssh链接去重启vdsm的服务，具体步骤如下：
b、保证一个合法的代理主机存在，即统一数据中心下处于up状态的主机。
c、如果连接超时：第一台主机的网络失效，主机的状态将变为”正在连接“；这时，管理端engine发出三次询问vdsm状态的指令（配置：VDSAttemptsToResetCount），等的时间决定于主机的负载情况（configured by the the config values TimeoutToResetVdsInSeconds[deafult 60sec] + (DelayResetPerVmInSeconds[default 0.5sec]*(the count of running vms on host) + (DelayResetForSpmInSeconds[default 20sec]*(1 if host runs as SPM or 0 if not))）；举个例子，按上述情况,vdsm hang住3次将花掉9分钟；这时如果主机仍然没有相应，则尝试执行vdsmd 重启，如果指令没有执行成功，则立即将此主机fence;在重复上述的重试时间；如果主机仍然没有相应，将主机的状态设置为“无响应”。
看起来是那么繁琐，是的，其实这个是比较温和的做法，还是在共享存储有额外的机制管理的情况下（SPM），否则就是简单粗暴的直接断电fencing.
- 网络
- ovirtmgmt管理网络不再仅在host deploy的bootstrap时初始化，而是在数据中心的setupNetwork中搞定。
- “迁移风暴”的尝试之一，可以定义专门用于迁移的网络角色，这个和qemu的迁移机制相对应的，当迁移发生时，整个vm的信息都通过TCP/IP来传输，而目前的engine 的规则是所有的目标qemu都是走的ovirtmgmt网络，此分离的意义便是如此减轻它的负担。
- 集成openstack quantum成为ovirt的网络提供者，用于：发现网络、部署网络。network as a service成为可能。
- Network relaoded，这是对VDSM网络方面的改进，诸如网络方式的确定等。
- 多网关支持，原来的版本，网关仅ovirtmgmt决定，3.3用户可给每个逻辑网络自定义网关！
- 存储
- KVM新的半虚拟化SCSI设备， virtio-scsi的支持，相比于原来的virtio-blk有了很多新的特性，具体情形见这里。
- Glusterfs swift的管理支持。
- 可以管理gluster hooks(Volume lifecycle extensions),可以查看hooks列表、激活以及关闭
- 增加对存储的添加、编辑、删除连接的功能。
- 在虚拟磁盘的hot plug和hot unplug时添加vdsm hooks point.
- 增强对启动磁盘的检查，如copy后，再删除原内容，中间尽可能的捕获一些异常情况。
- 支持独立软件供应商的备份/恢复机制。
- NetApp的存储磁盘校准，这个和厂商关系密切，详情可参考这里。
- 服务级别 这是企业级软件的一个衡量标准，大多和质量有关，诸如稳定性、健壮性等
- 计划任务 Scheduler的实现，这个会将我的注意力集中到jboss Droopl planner（现在更名为OptaPlanner),也是我担心engine的去向的问题，庞杂而紧耦合。
- Network QoS,容许用户在每个虚拟网卡级别上限制出、入带宽。
- 软件实现的watchdog集成，用户可以为虚拟机添加watchdog设备，用于高可用的服务是非常重要的一环。（pacemaker的新的对虚拟机的支持，亦是同理）
- intel TXT(Trusted Execution Technology)支持，俗称安全节点池。
- 部署、集成
- ovirt-node-vdsm-plugin项目的崛起，ovirt-node的野心不再是仅仅支持ovirt-engine了，分离出vdsm仅仅是为了更好的支撑ovirt-engine.
- 使用otopi彻底重写engine-setup、engien-clearup、engine-upgrade及AIO
- 因为有node-plugin的存在，ovirt-node已经转变为希望支持更多的、可定制性更强的发行版。
- 界面
- 由于spice proxy ,无需插件的访问方式的变更，管理端和用户门户的访问虚拟机的设置均有一些变化。
- ovirt支持界面的定制了！这是个好的消息，由于GWT的css分离特性，3.3的ovirt支持几种界面的定制：弹出窗口、登录界面、主界面的头、及部分表格的样式。
- 改善IE8下用户门户的体验，linux用户无视。
在其wiki上的3.3 release notes上，支持openstack的glance和neutron的服务，参考的slides,分别是glance-intergrated 和 neutron 。
Ovirt在虚拟化管理的路上还需要走很久！未来虽然是明朗的，但道路将是坎坷的！从架构上来说也有很多的缺陷，而且和OpenStack的分工，也将影响着社区的走向。重要的是我们能从中学到什么？能解决用户多少问题？
思考吧！
没有评论:
发表评论