Few notes:

1. (Probably unrelated to current bug) The setup log has:

2016-06-14 13:48:10 INFO otopi.plugins.ovirt_hosted_engine_setup.storage.blockd blockd._misc:639 Creating Volume Group
2016-06-14 13:48:11 DEBUG otopi.plugins.ovirt_hosted_engine_setup.storage.blockd blockd._misc:641 {'status': {'message': 'Failed to initialize physical device: ("[\'/dev/mapper/1IET_000c0001\']",)', 'code': 601}}
2016-06-14 13:48:11 ERROR otopi.plugins.ovirt_hosted_engine_setup.storage.blockd blockd._misc:647 Error creating Volume Group: Failed to initialize physical device: ("['/dev/mapper/1IET_000c0001']",)
2016-06-14 13:48:11 DEBUG otopi.plugins.otopi.dialog.human human.queryString:156 query OVEHOSTED_FORCE_CREATEVG
2016-06-14 13:48:11 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:219 DIALOG:SEND                 The selected device is already used.

But code 601 (or the message) do not say _why_ it failed. It could have been network issues, permissions, failure on the iscsi target, whatever. Not sure we can/should do anything about this in the code, but it still might help to check/attach other relevant logs (vdsm, storage, syslog etc).

2. This looks remarkably similar to bug 1238823 . The fix there was to zero the volume before first use. But the patch was in HA code, and I can't find where we call this code in setup, if at all. I might be missing something.

The fix was in -ha in VdsmBackend.createVolume in storage_backend.py

While on -setup we already:
from ovirt_hosted_engine_ha.lib import storage_backends
...
backend = storage_backends.VdsmBackend(
...
            created = backend.create({
                lockspace + '.lockspace': 1024*1024*backend.blocksize/512,
                lockspace + '.metadata': md_size,
            })

and VdsmBackend.create internally calls VdsmBackend.createVolume

Reproduction/verification steps:

1. Allocate an iSCSI target lun for hosted-engine
2. Fill it with random data
3. Deploy hosted-engine on it
4. Run 'hosted-engine --vm-status'

(In reply to Yedidyah Bar David from comment #4)
> Reproduction/verification steps:
> 
> 1. Allocate an iSCSI target lun for hosted-engine
> 2. Fill it with random data

^^^
I think that the point is here: during development activities we mainly tested iSCSI deployment with iSCSI targetcli using file based backend.
The same in automated tests and probably also for QE.
In this case the LUN is initialized to zero by construction.

Nothing really ensures that all the SAN devices really initialize the device.


> 3. Deploy hosted-engine on it
> 4. Run 'hosted-engine --vm-status'

To clarify: A workaround is to make sure that the storage space used for hosted-engine is zeroed prior to deploy. As Simone noted above, this is the default for many storage systems. If it's not, the admin should manually zero it.

(In reply to Yedidyah Bar David from comment #6)
> To clarify: A workaround is to make sure that the storage space used for
> hosted-engine is zeroed prior to deploy. As Simone noted above, this is the
> default for many storage systems. If it's not, the admin should manually
> zero it.

This workaround never worked for me if iSCSI target is EL6 (though not tested with EL7 target), "discovered" LUN was always detected by hosted-engine --deploy as dirty.

(In reply to Jiri Belka from comment #7)
> This workaround never worked for me if iSCSI target is EL6 (though not
> tested with EL7 target), "discovered" LUN was always detected by
> hosted-engine --deploy as dirty.

Well, this isn't current bug :-) Current bug is if it does not tell you "dirty" but it still actually is.

ok, steps based on #4

ovirt-hosted-engine-setup-2.0.1-1.el7ev.noarch