Red Hat Bugzilla – Bug 1313917
[RFE] allow NFS hosted-engine system started on 3.4 to upgrade its filebase metadata and lockspace area to a VDSM volume as for fresh deployments
Last modified: 2017-12-05 12:10:30 EST
Description of problem:
At 3.4 time, hosted-engine could be deployed only on NFS.
HA metadata and lockspace was just two files inside the storage domain and they were created outside VDSM.
The file based approach would not work with block devices.
So, since with 3.5 where we started supporting also iSCSI, we wrote new code to use VDSM volumes for metadata and lockpspace; ovirt-hosted-engine-ha supports both file and volume based metadata and lockspace since 3.5.
hosted-engine-setup since 3.5 is always creating two VDSM volumes also for NFS deployment.
There was no explicit upgrade path between 3.4 and 3.5 so who started with 3.4 on NFS and upgraded to 3.5 (and also to 3.6) is still using the filebased metadata also on 3.5 or on 3.6.
Filebased metadata and lockspace are still there in 3.6 but by far less tested since all the new user from 3.5 and from 3.6 are already with volumes.
4.0 is probably the right moment to unify them moving everybody to volumes.
A critical point is that it would not be possibile to mix hosts that are using lockspace and metadata on files with hosts that are already pointing to a volume that is not in sync with the files at all so this upgrade will probably require to stop all the hosted-engine hosts (and obviously the engine VM) at the same time.
The only way to test the full upgrade path from 3.4 to 4.0 is:
3.4/el6 -> 3.5/el6 -> 3.5/el7 -> 3.6/el7 -> 4.0/el7
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Removed dependencies as this is not blocking recent versions (after 3.4).
ok, 3.4 -> 3.5 -> 3.6 -> 4.0 (ovirt-hosted-engine-setup-184.108.40.206-1.el7ev.noarch)
with some workarounds during the flow and there were some issues discovered:
BZ1365242, BZ1364557, BZ1364564, BZ1364568, BZ1364543, BZ1364571, BZ1364615