On May 2, 2017, at 12:04 AM, Simone Tiraboschi <stirabos(a)redhat.com> wrote:
On Sat, Apr 29, 2017 at 1:11 AM, Jamie Lawrence <jlawrence(a)squaretrade.com> wrote:
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.
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.
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.
OK, I'm in a place where I can try this, but am unsure as to how to do it. Selecting
the hosted engine SD, it won't allow me to place it in maintenance ("Error while
executing action: Cannot deactivate Storage. The storage selected contains the self hosted
engine."). Poking around more the only related action I can find that isn't
disabled is Gluster stop, which, if it is allowed, would seem likely to end badly - if the
Gluster volume is stopped, the running engine VM won't be accessible, and of course
the engine auto-import process wouldn't find anything.
So, how does one destroy the hosted engine volume from within the engine?
-j