Thanks, I looked at that. Our implementation is pretty site-specific, but briefly, the Ovirt part is just a set of Puppet classes and some scripts for glue. The site specific stuff does things like driving our Gluster config, dumping the DB/loading into our PG cluster[1] and reconfiguring, hooking in to monitoring, replacing the Apache SSL cert, etc. The basic stuff isn’t all that different than one of the generic Puppetforge modules, and if you don’t have our exact environment and requirements, the rest of it wouldn’t be useful. -j Still hoping for a response to the original question… -j [1] We are a DB heavy shop and want our DBAs managing backups and whatnot, and the installer barfs because we aren’t running an ancient PG version and tune our DBs differently than the absurdly-mandatory Ovirt defaults, so this dance is painful.

It was imported automatically. The chain of events was install HE, wait for the emails saying it was done cogitating, create the regular Gluster SD, import it. Shortly thereafter, the HE domain was imported, and things (storage, hosts, clusters) all appear correct in the GUI, but the error persists. -j

On Sat, Apr 29, 2017 at 1:11 AM, Jamie Lawrence <jlawrence(a)squaretrade.com&gt; wrote: I'd suggest to destroy (but without deleting its content!!!) the hosted-engine storage domain in the engine: the auto-import process should simply trigger again.

Does anyone know the answer to the specific question below? I'm not asking for workarounds to try; that approach has repeatedly gone nowhere and time is becoming an issue for me. If I'm on the wrong track, I'd be happy to hear that, too. (Well, not happy, but that would at least be progress.) - - - - I’m wondering if I can do this a different way. Since it is already imported, I can create VMs, and the only other warning I’m getting in the logs is unrelated, I’m thinking that the problem here is that something didn’t get properly set in the DB, and I should be able to fix that manually. In looking at the code (https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules...), it to my (not very deep) read that the setSucceeded call failed, even though AttachStorageDomainToPool worked. if (getSucceeded()) { AttachStorageDomainToPoolParameters attachSdParams = new AttachStorageDomainToPoolParameters( addSdParams.getStorageDomainId(), addSdParams.getStoragePoolId()); setSucceeded(getBackend().runInternalAction( VdcActionType.AttachStorageDomainToPool, attachSdParams, getContext()).getSucceeded()); } setActionReturnValue(heStorageDomain); Is there a way to call setSucceeded without hacking together a custom utility? Not seeing it in vdsClient --help, which doesn’t surprise me. In looking over the stored procedures, I’m also not finding a likely candidate, but that is probably because there are so many that I’m just missing it. Does anyone know what the relevant SP is, or in some other way clue me in on the right direction here? I realize this is not supposed to be the way to do things. But I’m not finding a better solution, and attempting to find a “right” way via questions to this isn’t working either. And of course I take full responsibility when Ovirt kills my pets and drinks all my liquor.