1. please be specific, whats the details of the vm that failed
2. provide the vdsm log, maybe we could see the xml there

(In reply to Roy Golan from comment #1)
> 1. please be specific, whats the details of the vm that failed
> 2. provide the vdsm log, maybe we could see the xml there

ignore 2. the call doesn't reach vdsm . it fails on the engine client (apache xmlRpc client)

does it reproduce? or was it only for the first time after installation?
did you try to install again and it happened again?

(In reply to Michal Skrivanek from comment #5)
> does it reproduce? or was it only for the first time after installation?
> did you try to install again and it happened again?

Hi Michal,

It seems to be quite reproducible and appears after the first setup.

doesn't reproduce on upstream 3.4

(In reply to Michal Skrivanek from comment #7)
eventually it does:)
though it happens only in the Default cluster (due to its arch initially created as Unknown)
New cluster always enforces a specific arch in the dialog.
Another workaround is to put the host to Maintenance and then Activate

analysis

setup:
 use Default cluster or any cluster with arch "Undefined"
 install a host, wait for it to go UP ; don't "Activate"

outcome:
 emulated_machine field of the cluster is never set (i.e null) by the host
 running a VM fails - XML rpc client refuses to send null values

cause:
 different flow between Activate and Install - 
 Activate:
  - we call VdsManager.refreshHost which set auto-detect treu (because arch == Undefined)
  - monitoring cycle starts, Host goes UP, we call VdsManager.refreshHost again,  the emulated machine is now set
 
 Install:
 - we put the host on status Initializing and wait for monitoring to kick in
 - monitoring ends, host goes Up, we call VdsManager.refreshHost, we set auto-detect to true and emulated machine is null

root cause:
 refreshHost first tries to detect emulated machine (proccesSoftwareCapabilities) and update the cluster and cpu and arch - which sets emulated machine to null if the arch has change 

monitoringStrategy.processHardwareCapabilities(vds);

Verified in rhevm-3.4.0-0.9.beta1.el6ev (av3.1).

Verification steps (same used for reproducing the bug in rhevm-3.4.0-0.4.master.el6ev):
1. On a clean RHEL 6.5 machine install RHEVM:
  # yum install rhevm-setup -y
  # rhevm-setup
  ...use defaults wherever possible...
2. In RHEVM Webadmin, add new host and wait until it's Up.
3. Add new storage (I used NFS), wait until it's Active.
4. Add new VM (fill in only the VM name). Add a disk to the VM so it can run (1GB, Thin Provision, Activate, Bootable).
5. Run VM.

Results: 
The VM is successfully launched, no errors in engine.log or vdsm.log.

Also had to chance to see start VM work fine on av3.1 (same flow as in comment #13)

Issue still happens on 9cf2c62b6eea35bd5bf4186a040ccb7c2b4c9082

(In reply to Kiril Nesenko from comment #16)
logs / access info / anything?
Is it exactly the same issue?
Does the workaround from bug 1077300 help?

Verified in rhevm-3.4.0-0.18.el6ev.noarch (av9).

Verified manaually and also in automated test scenario.
The verification steps were exactly the same as in comment 13, just copy&pasting:

1. On a clean RHEL 6.5 machine install RHEVM:
  # yum install rhevm-setup -y
  # rhevm-setup
  ...use defaults wherever possible...
2. In RHEVM Webadmin, add new host and wait until it's Up.
3. Add new storage (I used NFS), wait until it's Active.
4. Add new VM (fill in only the VM name). Add a disk to the VM so it can run (1GB, Thin Provision, Activate, Bootable).
5. Run VM.

Results: 
The VM is successfully launched, no errors in engine.log or vdsm.log.

Closing as part of 3.4.0