On Wed, Jul 27, 2016 at 5:38 PM, Nir Soffer <nsoffer@redhat.com> wrote:

On Wed, Jul 27, 2016 at 3:38 PM, Alexis HAUSER <alexis.hauser@telecom-bretagne.eu> wrote:

...

Hi,

I'm currently using an NFS storage for my hosted-engine. However, this NFS server will be removed soon. I'd like to move the hosted-engine to an iSCSI storage. How can I proceed ? The options for moving/copying VM disk don't seem to be available for the hosted engine in the web interface.

Yes, hosted engine has some limitations at this point, mainly all the interesting features like live storage migration, live snapshots, hot plug/unplug disk are not available.

Simone, do we have a simple procedure to move the engine to another storage?

Theoretically you could run engine-backup on the current engine VM, redeploy from scratch on the new storage domain and before running engine setup, inject there the backup. Something like: http://www.ovirt.org/develop/developer-guide/engine/migrate-to-hosted-engine... Unfortunately we know that migrating from HE to HE is not as simple as from physical to HE: https://bugzilla.redhat.com/show_bug.cgi?id=1240466#c21 In general the issue is that the DB backup form the old hosted-engine VM contains a lot of references to the previous hosted-engine env and you cannot simply remove/edit them from the engine since they are lock so you have to manually remove them from the DB which is quite risky/error prone. Improving engine-backup to automatically filter hosted-engine references is an RFE for 4.1. In the mean time I'd suggest, if feasible, to redeploy a new hosted-engine env and reattach there your storage domains and your hosts. This will imply a downtime.

Nir

On Thu, Jul 28, 2016 at 10:59 AM, Alexis HAUSER <alexis.hauser@telecom-bretagne.eu> wrote:

...

Unfortunately we know that migrating from HE to HE is not as simple as from physical to HE: https://bugzilla.redhat.com/show_bug.cgi?id=1240466#c21 In general the issue is that the DB backup form the old hosted-engine VM contains a lot of references to the previous hosted-engine env and you cannot simply remove/edit them from the engine since they are lock so you have to manually remove them from the DB which is quite risky/error prone.

This is a bit scaring. In case of issue with engine and trying to recover, it could also happen.

The backup and restore procedure on the same env is well testes, the issue is simply if you need to restore on a different environment (it's basically a migration) cause you have to remove all the references to the old env.

What other way would you suggest for backing the engine VM and being sure to be able to restore it as it was without errors ? Have you ever tried to backup/restore from rsync ? If there are data in the DB written when you're performing it, do you think it can cause issues ? If ovirt-engine service is stopped, is that problem avoided ?

Postgres is transactional so if you do it in the proper way I don't see issue but stopping the ovirt-engine service will of course help. But the issue is not that you risk data corruption, the issue is that when you import a backup of the engine DB to a different env, that backup says the hosted-engine storage domain is still the old one since it was that in the previous env and so on and you can simply edit the hosted-engine strage domain location from the engine itself since we are preventing it.

...

In the mean time I'd suggest, if feasible, to redeploy a new hosted-engine env and reattach there your storage domains and your hosts. This will imply a downtime.

Ok, I think I'll do that. A downtime isn't a problem right now, as I'm still at a pre-production step. (preparing it for production soon)