Description of problem: If one of the host go down where the HE VM is running, the other hypervisor will not start the VM automatically if the iso domain is configured on the RHEV-M VM. It will be stuck in the below stage according to the engine log. MainThread::INFO::2016-05-04 04:19:40,638::ovf_store::109::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) Extracting Engine VM OVF from the OVF_STORE From the code, it seems that getEngineVMOVF is trying to access /rhev/data-center/mnt/* volume_path = os.path.join( volume_path, '*', sd_uuid, 'images', img_uuid, vol_uuid, ) volumes = glob.glob(volume_path) The iso domain is also mounted under /rhev/data-center/mnt/<nfs-path> . Since NFS server is running in the RHEV-M VM, this path /rhev/data-center/mnt/<nfs-path> will not be accessible and the process get hanged if we access this path. Hence ha-agent will also hang as it try to access /rhev/data-center/mnt/* . Therefore failover doesn't works. Version-Release number of selected component (if applicable): RHEV 3.6.5 ovirt-hosted-engine-setup-1.3.5.0-1.el7ev.noarch ovirt-hosted-engine-ha-1.3.5.3-1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Create a two node HE setup 2. Create an NFS export within the RHEV-M VM and add this as an iso domain from the RHEV admin portal 3. Power off the host where the HE VM is running. 4. HE VM will not start automatically and the agent log will be stuck with below logs MainThread::INFO::2016-05-04 04:19:40,638::ovf_store::109::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) Extracting Engine VM OVF from the OVF_STORE Actual results: HE VM is not automatically starting in the other HE host Expected results: HE VM should failover automatically. Additional info:
*** This bug has been marked as a duplicate of bug 1215434 ***
Sandro the appliance is the main installation method and using ISO is less used. Do you want to still support that method of installatino? if so i recommend to put the ISO on one of the installing host. What do you think?
So iiuc we need to block adding ISO domain both in the setup and in the backend, is that correct?
Not to block at the engine cause there might be iso domains already configured for some users already or if someone really wants an iso domain configured on the engine (let say non-appliance users probably) so its ok. Once we will exclude it from the setup it will diminish. But I do suggest doing it now.
OK, Sandro since it's setup related can your team take care of it?
Yaniv - do we still want this for 4.0? We don't have a good replacement for the ISO domain YET.
(In reply to Allon Mureinik from comment #9) > Yaniv - do we still want this for 4.0? We don't have a good replacement for > the ISO domain YET. It's the setup on the engine machine, not the domain in general.
If the user chooses the appliance flow we are already skipping the NFS ISO storage domain configuration. If the user manually executes engine-setup, the setup it's still asking but since rhbz#1317947 the default is now to skip it. Yaniv, is this enough to close this?
(In reply to Simone Tiraboschi from comment #12) > If the user chooses the appliance flow we are already skipping the NFS ISO > storage domain configuration. > If the user manually executes engine-setup, the setup it's still asking but > since rhbz#1317947 the default is now to skip it. > Yaniv, is this enough to close this? Looks good, closing.