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