Re: Migrate Hosted-Engine from one NFS mount to another NFS mount
On Wed, 23 Feb 2022, Matthew.Stier@fujitsu.com wrote:
I’ve always been told that migrating self-hosted-engine storage was a backup, shutdown, and rebuild from backup procedure.
In my iscsi environment it has never worked. (More due to the history of my environment, than the procedure itself.)
This didn't work for me either, though it may have had to do with the many issues I had moving from 4.3 to 4.4. What did work was backing up and restoring to a standalone engine. I had initially planned to migrate it back to a self-hosted setup later, but found that this setup is a lot less temperamental than the self-hosted engine. It also doesn't have to be a dedicated machine, it can be a VM hosted outside of oVirt, which may also be useful if you're hosting some stuff needed for bootstrapping the environment like DNS, NTP, etc. outside of oVirt.
On Thu, Feb 24, 2022 at 10:13 AM Sketch <ovirt@rednsx.org> wrote:
On Wed, 23 Feb 2022, Matthew.Stier@fujitsu.com wrote:
I’ve always been told that migrating self-hosted-engine storage was a backup, shutdown, and rebuild from backup procedure.
In my iscsi environment it has never worked. (More due to the history of my environment, than the procedure itself.)
This didn't work for me either, though it may have had to do with the many issues I had moving from 4.3 to 4.4. What did work was backing up and restoring to a standalone engine.
I had initially planned to migrate it back to a self-hosted setup later, but found that this setup is a lot less temperamental than the self-hosted engine. It also doesn't have to be a dedicated machine, it can be a VM hosted outside of oVirt, which may also be useful if you're hosting some stuff needed for bootstrapping the environment like DNS, NTP, etc. outside of oVirt.
Not sure this is the best thread to write the below, but anyway: hosted-engine is in essence a solution to two separate "problems": 1. A "place" to put your engine without maintaining dedicated hardware. Your point above definitely addresses this point reasonably in a different way. 2. High Availability. If you have more than one host, you get this "for free". If you want to roll your own HA on your own thing, you have to do this yourself, which will likely cost money, or time, or (probably) both. The downside is of course that it's, as you say, "more temperamental". I still think it's a good solution to the two points above, but definitely understand others that prefer hosting the engine elsewhere - with HA (and have a more complex solution, where it's hard (for me) to judge which is more complex) or without (and then get a significantly simpler solution but a higher risk). I'd also like to mention that at some point we added a few features that should make HE deployment in general, and especially deploy+restore, more resilient - by allowing you to "help" the tool do its job if needed. See e.g.: https://github.com/oVirt/ovirt-ansible-collection/blob/master/roles/hosted_e... So if you have a concrete setup where HE restore would have failed before, I encourage you to try again - in most cases, it should now pause and let you handle failures instead of aborting. Best regards, -- Didi
I've moved from 1 volume to another by using the hosted-engine. hosted-engine --get-shared-config storage --type=he_shared and then '--set-shared-config' to set the new value. I'm not sure but also '--type=local' might be needed. Best Regards,Strahil Nikolov On Thu, Feb 24, 2022 at 10:38, Yedidyah Bar David<didi@redhat.com> wrote: On Thu, Feb 24, 2022 at 10:13 AM Sketch <ovirt@rednsx.org> wrote:
On Wed, 23 Feb 2022, Matthew.Stier@fujitsu.com wrote:
I’ve always been told that migrating self-hosted-engine storage was a backup, shutdown, and rebuild from backup procedure.
In my iscsi environment it has never worked. (More due to the history of my environment, than the procedure itself.)
This didn't work for me either, though it may have had to do with the many issues I had moving from 4.3 to 4.4. What did work was backing up and restoring to a standalone engine.
I had initially planned to migrate it back to a self-hosted setup later, but found that this setup is a lot less temperamental than the self-hosted engine. It also doesn't have to be a dedicated machine, it can be a VM hosted outside of oVirt, which may also be useful if you're hosting some stuff needed for bootstrapping the environment like DNS, NTP, etc. outside of oVirt.
Not sure this is the best thread to write the below, but anyway: hosted-engine is in essence a solution to two separate "problems": 1. A "place" to put your engine without maintaining dedicated hardware. Your point above definitely addresses this point reasonably in a different way. 2. High Availability. If you have more than one host, you get this "for free". If you want to roll your own HA on your own thing, you have to do this yourself, which will likely cost money, or time, or (probably) both. The downside is of course that it's, as you say, "more temperamental". I still think it's a good solution to the two points above, but definitely understand others that prefer hosting the engine elsewhere - with HA (and have a more complex solution, where it's hard (for me) to judge which is more complex) or without (and then get a significantly simpler solution but a higher risk). I'd also like to mention that at some point we added a few features that should make HE deployment in general, and especially deploy+restore, more resilient - by allowing you to "help" the tool do its job if needed. See e.g.: https://github.com/oVirt/ovirt-ansible-collection/blob/master/roles/hosted_e... So if you have a concrete setup where HE restore would have failed before, I encourage you to try again - in most cases, it should now pause and let you handle failures instead of aborting. Best regards, -- Didi _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ADENQ3OIQ3XNYT...
participants (3)
-
Sketch -
Strahil Nikolov -
Yedidyah Bar David