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_Upgradi... - 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. Is what I've suggested a valid upgrade path, or is there a more sane way of going about this? -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@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.
On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright <cwright@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_Upgradi... - 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 cwright@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
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 cwright@cuttingedge.com.au | W www.cuttingedge.com.au /SYD /BNE /TYO On Wed, Nov 22, 2017 at 11:56 PM, Yedidyah Bar David <didi@redhat.com> wrote:
On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright <cwright@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_Upgradi... - 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 cwright@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.
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? -----Original Message----- From: users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of Cam Wright Sent: Wednesday, November 22, 2017 6:54 PM To: Yedidyah Bar David <didi@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 cwright@cuttingedge.com.au | W www.cuttingedge.com.au /SYD /BNE /TYO On Wed, Nov 22, 2017 at 11:56 PM, Yedidyah Bar David <didi@redhat.com> wrote:
On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright <cwright@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 cwright@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
On Mon, Nov 27, 2017 at 6:53 PM, Chas Ecomm <chashock@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-bounces@ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of Cam Wright Sent: Wednesday, November 22, 2017 6:54 PM To: Yedidyah Bar David <didi@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 cwright@cuttingedge.com.au | W www.cuttingedge.com.au
/SYD /BNE /TYO
On Wed, Nov 22, 2017 at 11:56 PM, Yedidyah Bar David <didi@redhat.com> wrote:
On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright <cwright@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 cwright@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
participants (3)
-
Cam Wright -
Chas Ecomm -
Yedidyah Bar David