On Mon, Nov 27, 2017 at 6:53 PM, Chas Ecomm <chash...@speakfree.net> wrote:
> In my experience, though, you can't restore from a 3.6 engine backup to a > 4.1 engine. You'd have to install 4.0, restore, then upgrade to 4.1 > wouldn't you? > Correct. > > -----Original Message----- > From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf > Of > Cam Wright > Sent: Wednesday, November 22, 2017 6:54 PM > To: Yedidyah Bar David <d...@redhat.com> > Cc: users@ovirt.org > Subject: 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! > > > You didn't mention if you can stand downtime for your VMs or not. > 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 cwri...@cuttingedge.com.au | W www.cuttingedge.com.au > > /SYD /BNE /TYO > > > On Wed, Nov 22, 2017 at 11:56 PM, Yedidyah Bar David <d...@redhat.com> > wrote: > > On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright <cwri...@cuttingedge.com.au> > 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_ > >> Upgrading_Resources/ > >> - 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. > > > > You didn't mention if you can stand downtime for your VMs or not. > > 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 cwri...@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@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. > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > -- Didi
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users