On Tue, Jan 14, 2014 at 8:21 PM, Sandro Bonazzola <sbonazzo(a)redhat.com&gt; wrote: I would like to say that I was able to pass from 3.3.2 to 3.3.3beta1 without any downtime as far as VMs are concerned and my GlusterFS based DC. I also put my line inside wiki testing page. My setup is composed by a fedora 19 server used as engine (actually a vSphere VM) + 2 Fedora 19 server used as Hypervisors (BL685 G1 blades). 3 VMs configured: CentOS 5.10, CentOS 6.4, Fedora 20 Starting point is Fedora 19 with stable repo and a GlusterFS Datacenter. Gluster version on the two nodes is 3.4.2-1.fc19 and I have set quorum policy this way: gluster volume set gvdata cluster.quorum-type none This lets me maintain DC and VMs active also with only one host active at a time. Steps done: - enable beta repo on engine - engine-setup --> proposed to update ovirt-engine-setup package - yum update ovirt-engine-setup - engine-setup --> ok, downloaded new packages and setup - 1 day test with new engine and keep hosts the same version - migrate all 3 VMs to the currently SPM host (host2) - put non SPM host1 in maintenance - enable beta repo on host1 - stop vdsmd on host1 (possibly not necessary...) - yum update on host1 - merge between /etc/vdsm/logger.conf and created .rpmnew NOTE: in December I previously changed DEBUG entries to INFO in this file. In 3.3.3 they are yet set to DEBUG, but there is a new entry for ha engine -> it could be useful to put this note in release notes if one simply updates host and doesn't redeploy it (in this last case I don't know if a yum remove / yum install is made or the same "problem" is present...) In my case before merge this was the situation: # diff logger.conf logger.conf.rpmnew 2c2 < keys=root,vds,Storage,metadata --- 11c11 < level=INFO --- 16c16 < level=INFO --- 22c22 < level=INFO --- 32a33,38 43c49 < level=INFO --- So after the merge I have the new config file but with the INFO settings instead of DEBUG. - shutdown -r of host1 - activate host1 in webadmin gui - migrate all 3 VMs to the new version host1 - some tests accessing consoles - select host1 as SPM in webadmin gui before working on update for host2; wait and see --> ok - put host2 in maintenance - enable beta repo on host2 - stop vdsmd on host2 - yum update on host2 - merge new /etc/vdsm/logger.conf - shutdown -r of host2 - activate host2 in webadmin gui - migrate all 3 VMs to the new version host2 - test access to consoles Bye, Gianluca