Re: [ovirt-users] Upgrading from Hosted Engine 3.6 to 4.X

Thanks for your response. Good to know that what I've suggested isn't completely whacky! We can't afford a lot of downtime on the VMs, probably 1-2 hours early morning at maximum given business needs, but we'd prefer to not have any downtime if at all possible. ...on your suggested plan, as that seems the more sane option if we can get a bigger maintenance window than the aforementioned couple of hours. The biggest issue I can see even in step one, however, is that all of our hosts are hosted-engine hosts, in that all four hosts are capable of running the engine.. so we'd need to bring both clusters (i.e.: all hosts) down. Having said that, it seems like a safer plan... as long as business requirements can accommodate. Thanks again. -C Cam Wright - Systems and Technical Resource Administrator CUTTINGEDGE / 90 Victoria St, West End, Brisbane, QLD, 4101 T + 61 7 3013 6200 M 0420 827 007 E cwright(a)cuttingedge.com.au | W www.cuttingedge.com.au /SYD /BNE /TYO On Wed, Nov 22, 2017 at 11:56 PM, Yedidyah Bar David <didi(a)redhat.com&gt; wrote: > On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright <cwright(a)cuttingedge.com.au&gt; wrote: >> >> Hi there, >> >> We're looking to upgrade our hosted engine setup from 3.6 to 4.0 (or 4.1)... >> >> We built the 3.6 setup a couple of years ago with Fedora 22 (we wanted >> the newer-at-the-time kernel 4.4) on the hosts and engine, but when we >> move to 4.X we'd like to move to EL7 on the engine (as that seems to >> be the supported version) and to the oVirt Node ISO installer on the >> hypervisors. >> >> We've got only four hosts in our oVirt datacentre, configured in two clusters. >> >> Our current idea is to take a backup of the oVirt database using the >> backup-restore tool, and to take a 'dd' of the virtual disk too, for >> good measure. Then upgrade the engine to 4.X and confirm that the 3.6 >> hosts will run, and then finally piecemeal upgrade the hosts to 4.X >> using the oVirt Node ISO installer. >> >> Looking at this page - >> https://www.ovirt.org/documentation/self-hosted/chap-Maintenance_and_Upgr... >> - it seems the 'hosted-engine --upgrade-appliance' path is the best >> way to do this... but because our hosts are running Fedora instead of >> EL, I think that makes this option moot to us. > > Basically yes. You might be able to somehow patch it to enforce > this, not sure it's worth it. > >> >> Is what I've suggested a valid upgrade path, or is there a more sane >> way of going about this? > > Sounds reasonable. > > If not, or if you need to minimize it, you should design and test carefully. > > If you can, something like this should work: > > 1. Take down all VMs on all hosts that are hosted-engine hosts > 2. Move all hosted-engine hosts to maintenance > 3. Remove one hosted-engine host from the engine > 4. Take a backup > 5. Reinstall the host as el7 > 6. Deploy new hosted-engine on new storage on this host, tell it to > not run engine-setup > 7. Inside the new engine vm, restore the backup and engine-setup > 8. See that you can start the VMs on the new host > 9. Remove the other host on that cluster, reinstall it with el7, add > 10. Handle the other cluster > > Plan well and test well. You can use VMs and nested-kvm for the testing. > Do not restore a backup of the real engine on a test vm that has access > to your hosts - it will try to manage them. Do the testing in an isolated > network. > > Best regards, > >> >> -C >> >> Cam Wright - Systems and Technical Resource Administrator >> CUTTINGEDGE / >> 90 Victoria St, West End, Brisbane, QLD, 4101 >> T + 61 7 3013 6200 M 0420 827 007 >> E cwright(a)cuttingedge.com.au | W www.cuttingedge.com.au >> >> /SYD /BNE /TYO >> >> -- >> >> >> This email is confidential and solely for the use of the intended recipient. >> If you have received this email in error please notify the author and >> delete it immediately. This email is not to be distributed without the >> author's written consent. Unauthorised forwarding, printing, copying or use >> is strictly prohibited and may be a breach of copyright. Any views >> expressed in this email are those of the individual sender unless >> specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting >> Edge). Although this email has been sent in the belief that it is >> virus-free, it is the responsibility of the recipient to ensure that it is >> virus free. No responsibility is accepted by Cutting Edge for any loss or >> damage arising in any way from receipt or use of this email. This email may >> contain legally privileged information and privilege is not waived if you >> have received this email in error. >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > > > > > -- > Didi -- This email is confidential and solely for the use of the intended recipient. If you have received this email in error please notify the author and delete it immediately. This email is not to be distributed without the author's written consent. Unauthorised forwarding, printing, copying or use is strictly prohibited and may be a breach of copyright. Any views expressed in this email are those of the individual sender unless specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting Edge). Although this email has been sent in the belief that it is virus-free, it is the responsibility of the recipient to ensure that it is virus free. No responsibility is accepted by Cutting Edge for any loss or damage arising in any way from receipt or use of this email. This email may contain legally privileged information and privilege is not waived if you have received this email in error.