On Thu, Oct 22, 2015 at 5:38 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:


On Thu, Oct 22, 2015 at 5:28 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, Oct 22, 2015 at 5:08 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:

engine is up and admin web portal accessible and host results up.

I expected storage to be configured inside admin web portal but apparently I don't see anything already configured and also I don't see the sh engine VM listed... is it correct?

No, we have an open bug on that:

You can try to manually import it in the mean time.

Ok, I'll try.
So when bug solved, if I have a problem with the engine and for example I'm not able to connect to it through ssh and/or web admin console, what other means would I have to connect to it console and check (eg if it is in kernel panic for any reason)?

Ehm if the engine VM is not responding you cannot use the engine to check it. 
But you have an HA agent that monitors it for you and can restart if needed.

You can also use ssh with the root password you set via cloud-init.
 
During setup I was proposed to connect via remote-viewer via a temporary password; I imagine this way is not usable after install, correct?

You can use
hosted-engine --add-console-password to set another temporary password.
 

 

But hosted-engine storage domain can just contain the engine VM so you still need to add a regular storage domain for other VMs.




Ah, ok. I thought that the initial storage domain would have become the first storage domain for general VMs purposes too...
So actually if on dedicated filesystem/device, it could be small in size, say 5-10Gb if I use the appliance, correct?


20GB is the minimum recommended value plus you need additional space for ancillary storage domain data structured so I'd avoid allocating less than 25GB.
 
 
BTW: what is the 2Gb file system on loop device?

It was used by hosted-engine-setup as a fake storage pool to bootstrap the hosted-engine storage domain.
It shouldn't be there at the end.
Could you please attach hosted-engine-setup logs to let me check why it's still there?

here it is:

Thanks

That ovirt-hosted-engine-setup attempt used /dev/loop0 and it got correctly detached at the end.

2015-10-22 15:51:28 DEBUG otopi.plugins.ovirt_hosted_engine_setup.storage.storage plugin.executeRaw:828 execute: ('/sbin/losetup', '--detach', u'/dev/loop0'), executable='None', cwd='None', env=None
2015-10-22 15:51:28 DEBUG otopi.plugins.ovirt_hosted_engine_setup.storage.storage plugin.executeRaw:878 execute-result: ('/sbin/losetup', '--detach', u'/dev/loop0'), rc=0

So that /dev/loop3 is probably just a leftover of one of your previous attempts. I think you can safely remove it.
 


 
 

I configured the storage domain part as NFS, pointing to ovc71.localdomain.local:/NFS_DOMAIN
Reading page at

it is not clear to me what to do next if I want for example keep a single host with its sh engine as a replacement concept of what before was all-in-one... and start creating VMs....

You have to setup your first regular data domain for other VMs: you can add another NFS one.

OK.
In case I want to setup a single host with self hosted engine, could I configure on hypervisor
a) one NFS share for sh engine
b) one NFS share for ISO DOMAIN
c) a local filesystem to be used to create then a local POSIX complant FS storage domain 
and work this way as a replacement of all-in-one?

Yes but c is just a workaround, using another external NFS share would help a lot if in the future you plan to add o to migrate to a new server.
 
 



Put the host in global maintenance (otherwise the engine VM will be restarted)
Shutdown the engine VM
Shutdown the host
 


Ok. And for starting all again, is this correct:

a) power on hypevisor
b) hosted-engine --set-maintenance --mode=none

other steps required?

 
No, that's correct