Thanks! I'm suffering from this issue as well. Did you have to manually copy some data to the other store or anything? Or is this the full procedure, start to finish?
-- Matthew Trent Network Engineer Lewis County IT Services 360.740.1247 - Helpdesk 360.740.3343 - Direct line ________________________________________ From: users-boun...@ovirt.org <users-boun...@ovirt.org> on behalf of Dariusz Kryszak <dariusz.krys...@gmail.com> Sent: Friday, February 26, 2016 2:12 AM To: Simone Tiraboschi Cc: users Subject: Re: [ovirt-users] Master Doamin - Ovirt 3.6 - hoted engine OK. I've made it!!!! procedure: 1. backup hosted engine config engine-backup --mode=backup --file=engine_`date +%Y%m%d_%H%M%S`.bck - -log=engine_`date +%Y%m%d_%H%M%S`.log 2. on the hypervisor hosted-engine --set-maintenance --mode=global 3. on the management host systemctl stop ovirt-engine.service 4. on the management host su - postgres psql \c engine --- tu have to find maualy valuses but master always has storage_domain_type=0 UPDATE storage_domain_static SET storage_domain_type=(select storage_domain_type from storage_domain_static where storage_name='hosted_storage') WHERE storage_name='DS_MAIN' UPDATE storage_domain_static SET _update_date=(select _update_date from storage_domain_static where storage_name='hosted_storage') WHERE storage_name='DS_MAIN' UPDATE storage_domain_static SET storage_domain_type=1 WHERE storage_name='hosted_storage'; UPDATE storage_domain_static SET _update_date=null WHERE storage_name='hosted_storage'; 5. on the management host systemctl start ovirt-engine.service 6. on the hypervisor hosted-engine --set-maintenance --mode=none end. enjoy :-) On Fri, 2016-02-26 at 09:17 +0100, Simone Tiraboschi wrote: > > > On Thu, Feb 25, 2016 at 10:03 PM, Dariusz Kryszak < > dariusz.krys...@gmail.com> wrote: > > > > > > > > > > On Tue, 2016-02-23 at 17:13 +0100, Simone Tiraboschi wrote: > > > > > > > > > On Tue, Feb 23, 2016 at 4:19 PM, Dariusz Kryszak < > > > dariusz.krys...@gmail.com> wrote: > > > > Hi folks, > > > > I have a question about master domain when I'm using hosted > > engine > > > > deployment. > > > > At the beginning I've made deployment on NUC (small home > > > > installation) with hosted engine on the nfs share from NUC > > host. > > > > I've configured FS gluster on the same machine and used it for > > > > master domain and iso domain. Lets say All-in-ONE. > > > > After reboot happened something strange. Log says that master > > > > domain is not available and has to become on the > > hosted_storage. > > > > This is not ok in my opinion. I know that behavior because > > master > > > > doamin is not available, has been migrated to other shareable > > (in > > > > this case hosted_domain is nfs ). > > > > Do you thing, that should be locked in this particular case > > means > > > > when available is only hosted_storage? Right now it is not > > possible > > > > to change this situation because hosted engine resides on the > > > > hosted_storage. I Can't migrate it. > > > > > > > > > > > It could happen only after the hosted-engine storage domain got > > > imported by the engine but to do that you need an additional > > storage > > > domain which will become the master storage domain. > > > In the past we had a bug that let you remove the last regular > > storage > > > domain and it the case the hosted-engine would become the master > > > storage domain and as you pointed out that was an issue. > > > https://bugzilla.redhat.com/show_bug.cgi?id=1298697 > > > > > > Now it should be fixed. If it just happened again just because > > you > > > gluster regular storage domain wasn't available is not really > > fixed. > > > Adding Roy here. > > > Dariusz, which release are you using? > > > > Regarding to the ovirt version. > > 1. ovirt manager > > ovirt-engine-setup - oVirt Engine Version: 3.6.2.6-1.el7.centos > The patch that should address that issue is here: > https://gerrit.ovirt.org/#/c/53208/ > > But you'll find it only in 3.6.3; it wasn't available at 3.6.2.6 > time. > > Recovering from the condition you reached is possible but it requires > a few manual actions. > If your instance was almost empty redeploying is also an (probably > easier) option. > > > > # uname -a > > Linux ovirtm.stylenet 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 > > 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > cat /etc/redhat-release > > CentOS Linux release 7.2.1511 (Core) > > > > > > > > 2. hypervisor > > > > uname -a > > Linux ovirth1.stylenet 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 > > 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > cat /etc/redhat-release > > CentOS Linux release 7.2.1511 (Core) > > > > rpm -qa|grep 'hosted\|vdsm' > > vdsm-cli-4.17.18-1.el7.noarch > > ovirt-hosted-engine-ha-1.3.3.7-1.el7.centos.noarch > > vdsm-xmlrpc-4.17.18-1.el7.noarch > > vdsm-jsonrpc-4.17.18-1.el7.noarch > > vdsm-4.17.18-1.el7.noarch > > vdsm-python-4.17.18-1.el7.noarch > > vdsm-yajsonrpc-4.17.18-1.el7.noarch > > vdsm-hook-vmfex-dev-4.17.18-1.el7.noarch > > ovirt-hosted-engine-setup-1.3.2.3-1.el7.centos.noarch > > vdsm-infra-4.17.18-1.el7.noarch > > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users