[ovirt-users] Unable to set up oVirt 4.0 HE using glusterfs storage

[Kevin Hung]

On 7/4/2016 4:38 AM, Simone Tiraboschi wrote:
> On Sun, Jul 3, 2016 at 5:57 AM, Kevin Hung <khung at nullaxiom.com> wrote:
>> 4. Using cloud-init with default values to customize the engine appliance
>> can fail on the line "Creating/refreshing DWH database schema" if it takes
>> longer than 600 seconds to return output. This may apply to any other step
>> that takes a long time to complete. The VM no longer appears to be exist
>> after the setup exits that so I am unable to debug.
> 600 seconds seams more than a reasonable time to create an empty DB,
> if it requires more than 10 minutes for a simple/short operation there
> is probably something strange with the storage.
I monitored the host RAM/CPU usage and the utilization of the Ethernet 
interface on the shared storage. RAM and CPU usage were minimal and 
there was barely anything going through the network interface. I can 
confirm that the network interface is fine as it is heavily utilized 
when the engine setup uses it to copy the image to the storage. I'm not 
sure what other statistics I should monitor to see if there's a bottleneck.
>> 5. Without using cloud-init, the setup creates an engine VM that I cannot
>> log into (it does not seem to use the engine admin password or a blank
>> password).
> Yes, the engine VM host-name and its root password are configured via
> cloud-init and there is not default password.
> If you want to avoid using cloud-init you have to reset the root
> password of the engine VM as for any el7 machine.
>
>> 6. Destroying the VM (option 4) leaves the files intact on the shared
>> storage so I cannot restart setup without deleting those first. This may be
>> intentional, but the use of kvm terminology (destroy for power off) is not
>> common, not to mention that "virsh -r list --all" does not list the VM
>> anymore.
> On failures, there is not just the engine VM disk but a whole storage
> domain for hosted-engine which also contains ancillary disks.
> Re-deploying over a dirty storage is not supported so please clean up
> the whole storage domain on failures.
>
>> 7. Unable to deploy second host through web UI (error "Failed to configure
>> management network on host node2 due to setup networks failure.") or using
> This is not hosted-engine specific:
> https://bugzilla.redhat.com/show_bug.cgi?id=1350763
Thanks for pointing out the BZ ticket. I'm not entirely certain that's 
the same issue I was seeing. Of course, I have no way of verifying 
anymore as I have already re-deployed using CentOS instead of Node.
>
>> ovirt-hosted-engine-setup (it looks like it can't connect to or doesn't
>> start the broker service).
>> 8. Random errors to stderr: "vcpu0 unhandled rdmsr" (this seems to be an
> Are you running in a nested env?
No, this is bare-metal, not a nested environment.