<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 10:03 PM, Dariusz Kryszak <span dir="ltr"><<a href="mailto:dariusz.kryszak@gmail.com" target="_blank">dariusz.kryszak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
<br>
<br>
On Tue, 2016-02-23 at 17:13 +0100, Simone Tiraboschi wrote:<br>
><br>
><br>
> On Tue, Feb 23, 2016 at 4:19 PM, Dariusz Kryszak <<br>
> <a href="mailto:dariusz.kryszak@gmail.com">dariusz.kryszak@gmail.com</a>> wrote:<br>
> > Hi folks,<br>
> > I have a question about master domain when I'm using hosted engine<br>
> > deployment.<br>
> > At the beginning I've made deployment on NUC (small home<br>
> > installation) with hosted engine on the nfs share from NUC host.<br>
> > I've configured FS gluster on the same machine and used it for<br>
> > master domain and iso domain. Lets say All-in-ONE.<br>
> > After reboot happened something strange. Log says that master<br>
> > domain is not available and has to become on the hosted_storage.<br>
> > This is not ok in my opinion. I know that behavior because master<br>
> > doamin is not available, has been migrated to other shareable (in<br>
> > this case hosted_domain is nfs ).<br>
> > Do you thing, that should be locked in this particular case means<br>
> > when available is only hosted_storage? Right now it is not possible<br>
> > to change this situation because hosted engine resides on the<br>
> > hosted_storage. I Can't migrate it.<br>
> ><br>
> ><br>
> It could happen only after the hosted-engine storage domain got<br>
> imported by the engine but to do that you need an additional storage<br>
> domain which will become the master storage domain.<br>
> In the past we had a bug that let you remove the last regular storage<br>
> domain and it the case the hosted-engine would become the master<br>
> storage domain and as you pointed out that was an issue.<br>
> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1298697" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1298697</a><br>
><br>
> Now it should be fixed. If it just happened again just because you<br>
> gluster regular storage domain wasn't available is not really fixed.<br>
> Adding Roy here.<br>
> Dariusz, which release are you using?<br>
<br>
</div></div>Regarding to the ovirt version.<br>
1. ovirt manager<br>
ovirt-engine-setup - oVirt Engine Version: 3.6.2.6-1.el7.centos<br></blockquote><div><br></div><div>The patch that should address that issue is here:</div><div><a href="https://gerrit.ovirt.org/#/c/53208/">https://gerrit.ovirt.org/#/c/53208/</a><br></div><div><br></div><div>But you'll find it only in 3.6.3; it wasn't available at 3.6.2.6 time.</div><div><br></div><div>Recovering from the condition you reached is possible but it requires a few manual actions.</div><div>If your instance was almost empty redeploying is also an (probably easier) option.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
# uname -a<br>
Linux ovirtm.stylenet 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16<br>
17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux<br>
cat /etc/redhat-release<br>
CentOS Linux release 7.2.1511 (Core)<br>
<br>
<br>
<br>
2. hypervisor<br>
<br>
uname -a<br>
Linux ovirth1.stylenet 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16<br>
17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux<br>
cat /etc/redhat-release<br>
CentOS Linux release 7.2.1511 (Core)<br>
<br>
rpm -qa|grep 'hosted\|vdsm'<br>
vdsm-cli-4.17.18-1.el7.noarch<br>
ovirt-hosted-engine-ha-1.3.3.7-1.el7.centos.noarch<br>
vdsm-xmlrpc-4.17.18-1.el7.noarch<br>
vdsm-jsonrpc-4.17.18-1.el7.noarch<br>
vdsm-4.17.18-1.el7.noarch<br>
vdsm-python-4.17.18-1.el7.noarch<br>
vdsm-yajsonrpc-4.17.18-1.el7.noarch<br>
vdsm-hook-vmfex-dev-4.17.18-1.el7.noarch<br>
ovirt-hosted-engine-setup-1.3.2.3-1.el7.centos.noarch<br>
vdsm-infra-4.17.18-1.el7.noarch<br>
</blockquote></div><br></div></div>