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_engine_setup/README.md#make-changes-in-the-engine-vm-during-the-deployment

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/ADENQ3OIQ3XNYTIKGMPXI233CUZOA3C7/