Re: [ovirt-users] ovirt 3.6.7 and gluster 3.7.14

2016-10-24 Thread Luiz Claudio Prazeres Goncalves 
Hi Sahina,

I've tried to upgrade to Gluster 3.7.16, but it seems the yum repo
https://download.gluster.org/pub/gluster/glusterfs/3
.7/3.7.16/EPEL.repo/epel-7.2/x86_64/ is not working

Two questions:

1 - Should I switch to the following repo ? This one seems to be working.

[centos-gluster37]

name=CentOS-$releasever - Gluster 3.7

baseurl=
http://mirror.centos.org/centos/$releasever/storage/$basearch/gluster-3.7/

gpgcheck=1

enabled=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Storage


2 - I'm using Centos7.2 + oVirt 3.6.6 with external gluster replica 3
storage. Is safe to upgrade to gluster 3.7.16 my external gluster server's
? The plan is to upgrade to oVirt 3.6.7 after this gluster server's upgrade.



Thanks

-Luiz




2016-08-08 4:26 GMT-03:00 Sahina Bose <sab...@redhat.com>:

>
>
> On Mon, Aug 8, 2016 at 3:37 AM, Luiz Claudio Prazeres Goncalves <
> luiz...@gmail.com> wrote:
>
>> Hi, it seems the ovirt-3.6-dependencies.repo is pointing the yum repo to
>> http://download.gluster.org/pub/gluster/glusterfs/LATEST/EP
>> EL.repo/epel-$releasever/$basearch/ and http://download.gluster.org/pu
>> b/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/noarch, however
>> the "LATEST" is now pointing to gluster 3.8.x and not to 3.7.x anymore.
>>
>
>
> I checked the ovirt-release project and the dependency points to CentOS
> SIG repo - http://mirror.centos.org/centos/7/storage/$basearch/
> gluster-3.7/
>
>
>>
>> So, in order to fix it I was forced to manually adjust the yum repo paths
>> as you can see below.  Is this procedure correct? I would say yes, but it's
>> always good to double check :)
>>
>
>
> The procedure is correct.
>
>
>>
>> Also, It's currently running centos 7.2 + ovirt 3.6.6 + gluster 3.7.11
>> (client) and I'm planning to upgrade to ovirt 3.6.7 and gluster 3.7.14
>> (client).
>>
>> The oVirt Cluster is running on top of an external gluster replica 3
>> cluster, hosting the engine storage domain and vms storage domain, running
>> the version 3.7.11 which I'm also planning to move to 3.7.14 as well.  I'm
>> using XFS and not ZFS, which seems to have issues with gluster 3.7.13
>>
>> Is this upgrade safe and recommended?
>>
>
> Update the gluster servers first and then the clients.
>
>
>>
>> Thanks
>> -Luiz
>>
>> [ovirt-3.6-glusterfs-epel]
>>
>> name=GlusterFS is a clustered file-system capable of scaling to several
>> petabytes.
>>
>> #baseurl=http://download.gluster.org/pub/gluster/glusterfs/
>> LATEST/EPEL.repo/epel-$releasever/$basearch/
>>
>> baseurl=https://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.14
>> /EPEL.repo/epel-7.2/x86_64/
>>
>> enabled=1
>>
>> skip_if_unavailable=1
>>
>> gpgcheck=1
>>
>> gpgkey=https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key
>>
>>
>> [ovirt-3.6-glusterfs-noarch-epel]
>>
>> name=GlusterFS is a clustered file-system capable of scaling to several
>> petabytes.
>>
>> #baseurl=http://download.gluster.org/pub/gluster/glusterfs/
>> LATEST/EPEL.repo/epel-$releasever/noarch
>>
>> baseurl=https://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.14
>> /EPEL.repo/epel-7.2/noarch
>>
>> enabled=1
>>
>> skip_if_unavailable=1
>>
>> gpgcheck=1
>>
>> gpgkey=https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key
>>
>> ___
>> 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

[ovirt-users] ovirt 3.6.7 and gluster 3.7.14

2016-08-07 Thread Luiz Claudio Prazeres Goncalves 
Hi, it seems the ovirt-3.6-dependencies.repo is pointing the yum repo to
http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/$basearch/
and
http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/noarch,
however the "LATEST" is now pointing to gluster 3.8.x and not to 3.7.x
anymore.

So, in order to fix it I was forced to manually adjust the yum repo paths
as you can see below.  Is this procedure correct? I would say yes, but it's
always good to double check :)

Also, It's currently running centos 7.2 + ovirt 3.6.6 + gluster 3.7.11
(client) and I'm planning to upgrade to ovirt 3.6.7 and gluster 3.7.14
(client).

The oVirt Cluster is running on top of an external gluster replica 3
cluster, hosting the engine storage domain and vms storage domain, running
the version 3.7.11 which I'm also planning to move to 3.7.14 as well.  I'm
using XFS and not ZFS, which seems to have issues with gluster 3.7.13

Is this upgrade safe and recommended?

Thanks
-Luiz

[ovirt-3.6-glusterfs-epel]

name=GlusterFS is a clustered file-system capable of scaling to several
petabytes.

#baseurl=
http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/$basearch/

baseurl=https://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.14
/EPEL.repo/epel-7.2/x86_64/

enabled=1

skip_if_unavailable=1

gpgcheck=1

gpgkey=https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key


[ovirt-3.6-glusterfs-noarch-epel]

name=GlusterFS is a clustered file-system capable of scaling to several
petabytes.

#baseurl=
http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/noarch

baseurl=https://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.14
/EPEL.repo/epel-7.2/noarch

enabled=1

skip_if_unavailable=1

gpgcheck=1

gpgkey=https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Fwd: Having issues with Hosted Engine

2016-04-29 Thread Luiz Claudio Prazeres Goncalves 
Got it. It should be included until 3.6.6 GA

Thanks
Luiz

Em sex, 29 de abr de 2016 04:26, Simone Tiraboschi <stira...@redhat.com>
escreveu:

> On Fri, Apr 29, 2016 at 4:44 AM, Luiz Claudio Prazeres Goncalves
> <luiz...@gmail.com> wrote:
> > Hi Simone, I was reviewing the changelog of 3.6.6, on the link below,
> but i
> > was not able to find the bug (https://bugzilla.redhat.com/1327516) as
> fixed
> > on the list. According to Bugzilla the target is really 3.6.6, so what's
> > wrong?
> >
> >
> > http://www.ovirt.org/release/3.6.6/
>
> ' oVirt 3.6.6 first release candidate' so it's still not the GA.
>
> > Thanks
> > Luiz
> >
> > Em qui, 28 de abr de 2016 11:33, Luiz Claudio Prazeres Goncalves
> > <luiz...@gmail.com> escreveu:
> >>
> >> Nice!... so, I'll survive a bit more with these issues until the version
> >> 3.6.6 gets released...
> >>
> >>
> >> Thanks
> >> -Luiz
> >>
> >> 2016-04-28 4:50 GMT-03:00 Simone Tiraboschi <stira...@redhat.com>:
> >>>
> >>> On Thu, Apr 28, 2016 at 8:32 AM, Sahina Bose <sab...@redhat.com>
> wrote:
> >>> > This seems like issue reported in
> >>> > https://bugzilla.redhat.com/show_bug.cgi?id=1327121
> >>> >
> >>> > Nir, Simone?
> >>>
> >>> The issue is here:
> >>> MainThread::INFO::2016-04-27
> >>>
> >>>
> 03:26:27,185::storage_server::229::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(disconnect_storage_server)
> >>> Disconnecting storage server
> >>> MainThread::INFO::2016-04-27
> >>>
> >>>
> 03:26:27,816::upgrade::983::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(fix_storage_path)
> >>> Fixing storage path in conf file
> >>>
> >>> And it's tracked here: https://bugzilla.redhat.com/1327516
> >>>
> >>> We already have a patch, it will be fixed with 3.6.6
> >>>
> >>> As far as I saw this issue will only cause a lot of mess in the logs
> >>> and some false alert but it's basically harmless
> >>>
> >>> > On 04/28/2016 05:35 AM, Luiz Claudio Prazeres Goncalves wrote:
> >>> >
> >>> >
> >>> > Hi everyone,
> >>> >
> >>> > Until today my environment was fully updated (3.6.5+centos7.2) with 3
> >>> > nodes
> >>> > (kvm1,kvm2 and kvm3 hosts) . I also have 3 external gluster nodes
> >>> > (gluster-root1,gluster1 and gluster2 hosts ) , replica 3, which the
> >>> > engine
> >>> > storage domain is sitting on top (3.7.11 fully updated+centos7.2)
> >>> >
> >>> > For some weird reason i've been receiving emails from oVirt with
> >>> > EngineUnexpectedDown (attached picture) on a daily basis more or
> less,
> >>> > but
> >>> > the engine seems to be working fine and my vm's are up and running
> >>> > normally.
> >>> > I've never had any issue to access the User Interface to manage the
> >>> > vm's
> >>> >
> >>> > Today I run "yum update" on the nodes and realised that vdsm was
> >>> > outdated,
> >>> > so I updated the kvm hosts and they are now , again, fully updated.
> >>> >
> >>> >
> >>> > Reviewing the logs It seems to be an intermittent connectivity issue
> >>> > when
> >>> > trying to access the gluster engine storage domain as you can see
> >>> > below. I
> >>> > don't have any network issue in place and I'm 100% sure about it. I
> >>> > have
> >>> > another oVirt Cluster using the same network and using a engine
> storage
> >>> > domain on top of an iSCSI Storage Array with no issues.
> >>> >
> >>> > Here seems to be the issue:
> >>> >
> >>> > Thread-::INFO::2016-04-27
> >>> > 23:01:27,864::fileSD::357::Storage.StorageDomain::(validate)
> >>> > sdUUID=03926733-1872-4f85-bb21-18dc320560db
> >>> >
> >>> > Thread-::DEBUG::2016-04-27
> >>> > 23:01:27,865::persistentDict::234::Storage.PersistentDict::(refresh)
> >>> > read
> >>> > lines (FileMetadataRW)=[]
> >>> >
> >>> > Thread-::DEBUG::2016-04-27
> >>> > 23:01:27,865::persistentDict::252::Stora

Re: [ovirt-users] Fwd: Having issues with Hosted Engine

2016-04-28 Thread Luiz Claudio Prazeres Goncalves 
Hi Simone, I was reviewing the changelog of 3.6.6, on the link below, but i
was not able to find the bug (https://bugzilla.redhat.com/1327516) as fixed
on the list. According to Bugzilla the target is really 3.6.6, so what's
wrong?


http://www.ovirt.org/release/3.6.6/


Thanks
Luiz

Em qui, 28 de abr de 2016 11:33, Luiz Claudio Prazeres Goncalves <
luiz...@gmail.com> escreveu:

> Nice!... so, I'll survive a bit more with these issues until the version
> 3.6.6 gets released...
>
>
> Thanks
> -Luiz
>
> 2016-04-28 4:50 GMT-03:00 Simone Tiraboschi <stira...@redhat.com>:
>
>> On Thu, Apr 28, 2016 at 8:32 AM, Sahina Bose <sab...@redhat.com> wrote:
>> > This seems like issue reported in
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1327121
>> >
>> > Nir, Simone?
>>
>> The issue is here:
>> MainThread::INFO::2016-04-27
>>
>> 03:26:27,185::storage_server::229::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(disconnect_storage_server)
>> Disconnecting storage server
>> MainThread::INFO::2016-04-27
>>
>> 03:26:27,816::upgrade::983::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(fix_storage_path)
>> Fixing storage path in conf file
>>
>> And it's tracked here: https://bugzilla.redhat.com/1327516
>>
>> We already have a patch, it will be fixed with 3.6.6
>>
>> As far as I saw this issue will only cause a lot of mess in the logs
>> and some false alert but it's basically harmless
>>
>> > On 04/28/2016 05:35 AM, Luiz Claudio Prazeres Goncalves wrote:
>> >
>> >
>> > Hi everyone,
>> >
>> > Until today my environment was fully updated (3.6.5+centos7.2) with 3
>> nodes
>> > (kvm1,kvm2 and kvm3 hosts) . I also have 3 external gluster nodes
>> > (gluster-root1,gluster1 and gluster2 hosts ) , replica 3, which the
>> engine
>> > storage domain is sitting on top (3.7.11 fully updated+centos7.2)
>> >
>> > For some weird reason i've been receiving emails from oVirt with
>> > EngineUnexpectedDown (attached picture) on a daily basis more or less,
>> but
>> > the engine seems to be working fine and my vm's are up and running
>> normally.
>> > I've never had any issue to access the User Interface to manage the vm's
>> >
>> > Today I run "yum update" on the nodes and realised that vdsm was
>> outdated,
>> > so I updated the kvm hosts and they are now , again, fully updated.
>> >
>> >
>> > Reviewing the logs It seems to be an intermittent connectivity issue
>> when
>> > trying to access the gluster engine storage domain as you can see
>> below. I
>> > don't have any network issue in place and I'm 100% sure about it. I have
>> > another oVirt Cluster using the same network and using a engine storage
>> > domain on top of an iSCSI Storage Array with no issues.
>> >
>> > Here seems to be the issue:
>> >
>> > Thread-::INFO::2016-04-27
>> > 23:01:27,864::fileSD::357::Storage.StorageDomain::(validate)
>> > sdUUID=03926733-1872-4f85-bb21-18dc320560db
>> >
>> > Thread-::DEBUG::2016-04-27
>> > 23:01:27,865::persistentDict::234::Storage.PersistentDict::(refresh)
>> read
>> > lines (FileMetadataRW)=[]
>> >
>> > Thread-::DEBUG::2016-04-27
>> > 23:01:27,865::persistentDict::252::Storage.PersistentDict::(refresh)
>> Empty
>> > metadata
>> >
>> > Thread-::ERROR::2016-04-27
>> > 23:01:27,865::task::866::Storage.TaskManager.Task::(_setError)
>> > Task=`d2acf575-1a60-4fa0-a5bb-cd4363636b94`::Unexpected error
>> >
>> > Traceback (most recent call last):
>> >
>> >   File "/usr/share/vdsm/storage/task.py", line 873, in _run
>> >
>> > return fn(*args, **kargs)
>> >
>> >   File "/usr/share/vdsm/logUtils.py", line 49, in wrapper
>> >
>> > res = f(*args, **kwargs)
>> >
>> >   File "/usr/share/vdsm/storage/hsm.py", line 2835, in
>> getStorageDomainInfo
>> >
>> > dom = self.validateSdUUID(sdUUID)
>> >
>> >   File "/usr/share/vdsm/storage/hsm.py", line 278, in validateSdUUID
>> >
>> > sdDom.validate()
>> >
>> >   File "/usr/share/vdsm/storage/fileSD.py", line 360, in validate
>> >
>> > raise se.StorageDomainAccessError(self.sdUUID)
>> >
>> > StorageDomainAccessError: Domain is either partially accessible or
>&g

Re: [ovirt-users] Fwd: Having issues with Hosted Engine

2016-04-28 Thread Luiz Claudio Prazeres Goncalves 
Nice!... so, I'll survive a bit more with these issues until the version
3.6.6 gets released...


Thanks
-Luiz

2016-04-28 4:50 GMT-03:00 Simone Tiraboschi <stira...@redhat.com>:

> On Thu, Apr 28, 2016 at 8:32 AM, Sahina Bose <sab...@redhat.com> wrote:
> > This seems like issue reported in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1327121
> >
> > Nir, Simone?
>
> The issue is here:
> MainThread::INFO::2016-04-27
>
> 03:26:27,185::storage_server::229::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(disconnect_storage_server)
> Disconnecting storage server
> MainThread::INFO::2016-04-27
>
> 03:26:27,816::upgrade::983::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(fix_storage_path)
> Fixing storage path in conf file
>
> And it's tracked here: https://bugzilla.redhat.com/1327516
>
> We already have a patch, it will be fixed with 3.6.6
>
> As far as I saw this issue will only cause a lot of mess in the logs
> and some false alert but it's basically harmless
>
> > On 04/28/2016 05:35 AM, Luiz Claudio Prazeres Goncalves wrote:
> >
> >
> > Hi everyone,
> >
> > Until today my environment was fully updated (3.6.5+centos7.2) with 3
> nodes
> > (kvm1,kvm2 and kvm3 hosts) . I also have 3 external gluster nodes
> > (gluster-root1,gluster1 and gluster2 hosts ) , replica 3, which the
> engine
> > storage domain is sitting on top (3.7.11 fully updated+centos7.2)
> >
> > For some weird reason i've been receiving emails from oVirt with
> > EngineUnexpectedDown (attached picture) on a daily basis more or less,
> but
> > the engine seems to be working fine and my vm's are up and running
> normally.
> > I've never had any issue to access the User Interface to manage the vm's
> >
> > Today I run "yum update" on the nodes and realised that vdsm was
> outdated,
> > so I updated the kvm hosts and they are now , again, fully updated.
> >
> >
> > Reviewing the logs It seems to be an intermittent connectivity issue when
> > trying to access the gluster engine storage domain as you can see below.
> I
> > don't have any network issue in place and I'm 100% sure about it. I have
> > another oVirt Cluster using the same network and using a engine storage
> > domain on top of an iSCSI Storage Array with no issues.
> >
> > Here seems to be the issue:
> >
> > Thread-::INFO::2016-04-27
> > 23:01:27,864::fileSD::357::Storage.StorageDomain::(validate)
> > sdUUID=03926733-1872-4f85-bb21-18dc320560db
> >
> > Thread-::DEBUG::2016-04-27
> > 23:01:27,865::persistentDict::234::Storage.PersistentDict::(refresh) read
> > lines (FileMetadataRW)=[]
> >
> > Thread-::DEBUG::2016-04-27
> > 23:01:27,865::persistentDict::252::Storage.PersistentDict::(refresh)
> Empty
> > metadata
> >
> > Thread-::ERROR::2016-04-27
> > 23:01:27,865::task::866::Storage.TaskManager.Task::(_setError)
> > Task=`d2acf575-1a60-4fa0-a5bb-cd4363636b94`::Unexpected error
> >
> > Traceback (most recent call last):
> >
> >   File "/usr/share/vdsm/storage/task.py", line 873, in _run
> >
> > return fn(*args, **kargs)
> >
> >   File "/usr/share/vdsm/logUtils.py", line 49, in wrapper
> >
> > res = f(*args, **kwargs)
> >
> >   File "/usr/share/vdsm/storage/hsm.py", line 2835, in
> getStorageDomainInfo
> >
> > dom = self.validateSdUUID(sdUUID)
> >
> >   File "/usr/share/vdsm/storage/hsm.py", line 278, in validateSdUUID
> >
> > sdDom.validate()
> >
> >   File "/usr/share/vdsm/storage/fileSD.py", line 360, in validate
> >
> > raise se.StorageDomainAccessError(self.sdUUID)
> >
> > StorageDomainAccessError: Domain is either partially accessible or
> entirely
> > inaccessible: (u'03926733-1872-4f85-bb21-18dc320560db',)
> >
> > Thread-::DEBUG::2016-04-27
> > 23:01:27,865::task::885::Storage.TaskManager.Task::(_run)
> > Task=`d2acf575-1a60-4fa0-a5bb-cd4363636b94`::Task._run:
> > d2acf575-1a60-4fa0-a5bb-cd4363636b94
> > ('03926733-1872-4f85-bb21-18dc320560db',) {} failed - stopping task
> >
> > Thread-::DEBUG::2016-04-27
> > 23:01:27,865::task::1246::Storage.TaskManager.Task::(stop)
> > Task=`d2acf575-1a60-4fa0-a5bb-cd4363636b94`::stopping in state preparing
> > (force False)
> >
> > Thread-::DEBUG::2016-04-27
> > 23:01:27,865::task::993::Storage.TaskManager.Task::(_decref)
> > Task=`d2acf575-1a60-4fa0-a5bb-cd4363636b94`::ref 1 aborting True
> >
> > Thread-111

Re: [ovirt-users] Hosted engine on gluster problem

2016-04-15 Thread Luiz Claudio Prazeres Goncalves 
I'm not planning to move to ovirt 4 until it gets stable, so would be great
to backport to 3.6 or ,ideally, gets developed on the next release of 3.6
branch. Considering the urgency (its a single point of failure) x
complexity wouldn't be hard to make the proposed fix.

I'm using today a production environment on top of gluster replica 3 and
this is the only SPF I have.

Thanks
Luiz

Em sex, 15 de abr de 2016 03:05, Sandro Bonazzola <sbona...@redhat.com>
escreveu:

> On Thu, Apr 14, 2016 at 7:35 PM, Nir Soffer <nsof...@redhat.com> wrote:
>
>> On Wed, Apr 13, 2016 at 4:34 PM, Luiz Claudio Prazeres Goncalves
>> <luiz...@gmail.com> wrote:
>> > Nir, here is the problem:
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1298693
>> >
>> > When you do a hosted-engine --deploy and pick "glusterfs" you don't
>> have a
>> > way to define the mount options, therefore, the use of the
>> > "backupvol-server", however when you create a storage domain from the
>> UI you
>> > can, like the attached screen shot.
>> >
>> >
>> > In the hosted-engine --deploy, I would expect a flow which includes not
>> only
>> > the "gluster" entrypoint, but also the gluster mount options which is
>> > missing today. This option would be optional, but would remove the
>> single
>> > point of failure described on the Bug 1298693.
>> >
>> > for example:
>> >
>> > Existing entry point on the "hosted-engine --deploy" flow
>> > gluster1.xyz.com:/engine
>>
>> I agree, this feature must be supported.
>>
>
> It will, and it's currently targeted to 4.0.
>
>
>
>>
>> > Missing option on the "hosted-engine --deploy" flow :
>> > backupvolfile-server=gluster2.xyz.com
>> ,fetch-attempts=3,log-level=WARNING,log-file=/var/log/glusterfs/gluster_engine_domain.log
>> >
>> > Sandro, it seems to me a simple solution which can be easily fixed.
>> >
>> > What do you think?
>> >
>> > Regards
>> > -Luiz
>> >
>> >
>> >
>> > 2016-04-13 4:15 GMT-03:00 Sandro Bonazzola <sbona...@redhat.com>:
>> >>
>> >>
>> >>
>> >> On Tue, Apr 12, 2016 at 6:47 PM, Nir Soffer <nsof...@redhat.com>
>> wrote:
>> >>>
>> >>> On Tue, Apr 12, 2016 at 3:05 PM, Luiz Claudio Prazeres Goncalves
>> >>> <luiz...@gmail.com> wrote:
>> >>> > Hi Sandro, I've been using gluster with 3 external hosts for a while
>> >>> > and
>> >>> > things are working pretty well, however this single point of failure
>> >>> > looks
>> >>> > like a simple feature to implement,but critical to anyone who wants
>> to
>> >>> > use
>> >>> > gluster on production  . This is not hyperconvergency which has
>> other
>> >>> > issues/implications. So , why not have this feature out on 3.6
>> branch?
>> >>> > It
>> >>> > looks like just let vdsm use the 'backupvol-server' option when
>> >>> > mounting the
>> >>> > engine domain and make the property tests.
>> >>>
>> >>> Can you explain what is the problem, and what is the suggested
>> solution?
>> >>>
>> >>> Engine and vdsm already support the backupvol-server option - you can
>> >>> define this option in the storage domain options when you create a
>> >>> gluster
>> >>> storage domain. With this option vdsm should be able to connect to
>> >>> gluster
>> >>> storage domain even if a brick is down.
>> >>>
>> >>> If you don't have this option in engine , you probably cannot add it
>> with
>> >>> hosted
>> >>> engine setup, since for editing it you must put the storage domain in
>> >>> maintenance
>> >>> and if you do this the engine vm will be killed :-) This is is one of
>> >>> the issues with
>> >>> engine managing the storage domain it runs on.
>> >>>
>> >>> I think the best way to avoid this issue, is to add a DNS entry
>> >>> providing the addresses
>> >>> of all the gluster bricks, and use this address for the gluster
>> >>> storage domain. This way
>> >>> the glusterfs mount helper can mount the domain even if one of the
>> >>> gluster bricks
&

Re: [ovirt-users] Hosted engine on gluster problem

2016-04-14 Thread Luiz Claudio Prazeres Goncalves 
Sandro, any word here? Btw, I'm not talking about hyperconvergency in this
case, but 3 external gluster nodes using replica 3

Regards
Luiz

Em qua, 13 de abr de 2016 10:34, Luiz Claudio Prazeres Goncalves <
luiz...@gmail.com> escreveu:

> Nir, here is the problem:
> https://bugzilla.redhat.com/show_bug.cgi?id=1298693
>
> When you do a hosted-engine --deploy and pick "glusterfs" you don't have a
> way to define the mount options, therefore, the use of the
> "backupvol-server", however when you create a storage domain from the UI
> you can, like the attached screen shot.
>
>
> In the hosted-engine --deploy, I would expect a flow which includes not
> only the "gluster" entrypoint, but also the gluster mount options which is
> missing today. This option would be optional, but would remove the single
> point of failure described on the Bug 1298693.
>
> for example:
>
> Existing entry point on the "hosted-engine --deploy" flow
> gluster1.xyz.com:/engine
>
>
> Missing option on the "hosted-engine --deploy" flow :
> backupvolfile-server=gluster2.xyz.com
> ,fetch-attempts=3,log-level=WARNING,log-file=/var/log/glusterfs/gluster_engine_domain.log
>
> ​Sandro, it seems to me a simple solution which can be easily fixed.
>
> What do you think?
>
> Regards
> -Luiz​
>
>
>
> 2016-04-13 4:15 GMT-03:00 Sandro Bonazzola <sbona...@redhat.com>:
>
>>
>>
>> On Tue, Apr 12, 2016 at 6:47 PM, Nir Soffer <nsof...@redhat.com> wrote:
>>
>>> On Tue, Apr 12, 2016 at 3:05 PM, Luiz Claudio Prazeres Goncalves
>>> <luiz...@gmail.com> wrote:
>>> > Hi Sandro, I've been using gluster with 3 external hosts for a while
>>> and
>>> > things are working pretty well, however this single point of failure
>>> looks
>>> > like a simple feature to implement,but critical to anyone who wants to
>>> use
>>> > gluster on production  . This is not hyperconvergency which has other
>>> > issues/implications. So , why not have this feature out on 3.6 branch?
>>> It
>>> > looks like just let vdsm use the 'backupvol-server' option when
>>> mounting the
>>> > engine domain and make the property tests.
>>>
>>> Can you explain what is the problem, and what is the suggested solution?
>>>
>>> Engine and vdsm already support the backupvol-server option - you can
>>> define this option in the storage domain options when you create a
>>> gluster
>>> storage domain. With this option vdsm should be able to connect to
>>> gluster
>>> storage domain even if a brick is down.
>>>
>>> If you don't have this option in engine , you probably cannot add it
>>> with hosted
>>> engine setup, since for editing it you must put the storage domain in
>>> maintenance
>>> and if you do this the engine vm will be killed :-) This is is one of
>>> the issues with
>>> engine managing the storage domain it runs on.
>>>
>>> I think the best way to avoid this issue, is to add a DNS entry
>>> providing the addresses
>>> of all the gluster bricks, and use this address for the gluster
>>> storage domain. This way
>>> the glusterfs mount helper can mount the domain even if one of the
>>> gluster bricks
>>> are down.
>>>
>>> Again, we will need some magic from the hosted engine developers to
>>> modify the
>>> address of the hosted engine gluster domain on existing system.
>>>
>>
>> Magic won't happen without a bz :-) please open one describing what's
>> requested.
>>
>>
>>
>>>
>>> Nir
>>>
>>> >
>>> > Could you add this feature to the next release of 3.6 branch?
>>> >
>>> > Thanks
>>> > Luiz
>>> >
>>> > Em ter, 12 de abr de 2016 05:03, Sandro Bonazzola <sbona...@redhat.com
>>> >
>>> > escreveu:
>>> >>
>>> >> On Mon, Apr 11, 2016 at 11:44 PM, Bond, Darryl <db...@nrggos.com.au>
>>> >> wrote:
>>> >>>
>>> >>> My setup is hyperconverged. I have placed my test results in
>>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1298693
>>> >>>
>>> >>
>>> >> Ok, so you're aware about the limitation of the single point of
>>> failure.
>>> >> If you drop the host referenced in hosted engine configuration for the
>>> >> initial s

Re: [ovirt-users] Hosted engine on gluster problem

2016-04-12 Thread Luiz Claudio Prazeres Goncalves 
Hi Sandro, I've been using gluster with 3 external hosts for a while and
things are working pretty well, however this single point of failure looks
like a simple feature to implement,but critical to anyone who wants to use
gluster on production  . This is not hyperconvergency which has other
issues/implications. So , why not have this feature out on 3.6 branch? It
looks like just let vdsm use the 'backupvol-server' option when mounting
the engine domain and make the property tests.

Could you add this feature to the next release of 3.6 branch?

Thanks
Luiz

Em ter, 12 de abr de 2016 05:03, Sandro Bonazzola 
escreveu:

> On Mon, Apr 11, 2016 at 11:44 PM, Bond, Darryl 
> wrote:
>
>> My setup is hyperconverged. I have placed my test results in
>> https://bugzilla.redhat.com/show_bug.cgi?id=1298693
>>
>>
> Ok, so you're aware about the limitation of the single point of failure.
> If you drop the host referenced in hosted engine configuration for the
> initial setup it won't be able to connect to shared storage even if the
> other hosts in the cluster are up since the entry point is down.
> Note that hyperconverged deployment is not supported in 3.6.
>
>
>
>>
>> Short description of setup:
>>
>> 3 hosts with 2 disks each set up with gluster replica 3 across the 6
>> disks volume name hosted-engine.
>>
>> Hostname hosted-storage configured in /etc//hosts to point to the host1.
>>
>> Installed hosted engine on host1 with the hosted engine storage path =
>> hosted-storage:/hosted-engine
>>
>> Install first engine on h1 successful. Hosts h2 and h3 added to the
>> hosted engine. All works fine.
>>
>> Additional storage and non-hosted engine hosts added etc.
>>
>> Additional VMs added to hosted-engine storage (oVirt Reports VM and
>> Cinder VM). Additional VM's are hosted by other storage - cinder and NFS.
>>
>> The system is in production.
>>
>>
>> Engine can be migrated around with the web interface.
>>
>>
>> - 3.6.4 upgrade released, follow the upgrade guide, engine is upgraded
>> first , new Centos kernel requires host reboot.
>>
>> - Engine placed on h2 -  h3 into maintenance (local) upgrade and Reboot
>> h3 - No issues - Local maintenance removed from h3.
>>
>> - Engine placed on h3 -  h2 into maintenance (local) upgrade and Reboot
>> h2 - No issues - Local maintenance removed from h2.
>>
>> - Engine placed on h3 -h1 into mainteance (local) upgrade and reboot h1 -
>> engine crashes and does not start elsewhere, VM(cinder)  on h3 on same
>> gluster volume pauses.
>>
>> - Host 1 takes about 5 minutes to reboot (Enterprise box with all it's
>> normal BIOS probing)
>>
>> - Engine starts after h1 comes back and stabilises
>>
>> - VM(cinder) unpauses itself,  VM(reports) continued fine the whole time.
>> I can do no diagnosis on the 2 VMs as the engine is not available.
>>
>> - Local maintenance removed from h​1
>>
>>
>> I don't believe the issue is with gluster itself as the volume remains
>> accessible on all hosts during this time albeit with a missing server
>> (gluster volume status) as each gluster server is rebooted.
>>
>> Gluster was upgraded as part of the process, no issues were seen here.
>>
>>
>> I have been able to duplicate the issue without the upgrade by following
>> the same sort of timeline.
>>
>>
>> 
>> From: Sandro Bonazzola 
>> Sent: Monday, 11 April 2016 7:11 PM
>> To: Richard Neuboeck; Simone Tiraboschi; Roy Golan; Martin Sivak; Sahina
>> Bose
>> Cc: Bond, Darryl; users
>> Subject: Re: [ovirt-users] Hosted engine on gluster problem
>>
>>
>>
>> On Mon, Apr 11, 2016 at 9:37 AM, Richard Neuboeck > > wrote:
>> Hi Darryl,
>>
>> I'm still experimenting with my oVirt installation so I tried to
>> recreate the problems you've described.
>>
>> My setup has three HA hosts for virtualization and three machines
>> for the gluster replica 3 setup.
>>
>> I manually migrated the Engine from the initial install host (one)
>> to host three. Then shut down host one manually and interrupted the
>> fencing mechanisms so the host stayed down. This didn't bother the
>> Engine VM at all.
>>
>> Did you move the host one to maintenance before shutting down?
>> Or is this a crash recovery test?
>>
>>
>>
>> To make things a bit more challenging I then shut down host three
>> while running the Engine VM. Of course the Engine was down for some
>> time until host two detected the problem. It started the Engine VM
>> and everything seems to be running quite well without the initial
>> install host.
>>
>> Thanks for the feedback!
>>
>>
>>
>> My only problem is that the HA agent on host two and three refuse to
>> start after a reboot due to the fact that the configuration of the
>> hosted engine is missing. I wrote another mail to users@ovirt.org> users@ovirt.org>
>> about that.
>>
>> This is weird. Martin,  Simone can you please investigate on this?
>>
>>
>>
>>
>> Cheers
>>

[ovirt-users] oVirt 3.6.2 issue when updating to gluster 3.7.8

2016-02-17 Thread Luiz Claudio Prazeres Goncalves 
Hi, I realised that gluster 3.7.8 was released for GA. So I updated
manually using "yum -y install glusterfs*" gluster get's updated normally,
but  unfortunately things stopped to work completely.
ovirt_hosted_engine_ha was not able to connect to my gluster storage domain
(as you can see below). I'm not using ovirt + gluster in hyperconverged
way. I have 3 external gluster hosts.

As a workaround I've executed "*yum* downgrade glusterfs*" and after doing
this ovirt started to work again...but as a collateral effect now I can't
migrate my vm's anymore.  On the vdsm logs I can see the following errors
when trying to manually migrate a any VM Anyone knows how to fix it?

Thread-66055::DEBUG::2016-02-17
11:05:57,497::migration::453::virt.vm::(stop)
vmId=`05681896-a76a-4ae1-879e-8fe5d28634e1`::stopping migration downtime
thread

Thread-66055::ERROR::2016-02-17
11:05:57,497::migration::208::virt.vm::(_recover)
vmId=`05681896-a76a-4ae1-879e-8fe5d28634e1`::unable to connect to server at
'kvm2.brightsquid.com:49152': No route to host

Thread-66055::DEBUG::2016-02-17
11:05:57,497::stompreactor::389::jsonrpc.AsyncoreClient::(send) Sending
response

Thread-66056::DEBUG::2016-02-17
11:05:57,498::migration::450::virt.vm::(run)
vmId=`05681896-a76a-4ae1-879e-8fe5d28634e1`::migration downtime thread
exiting

Thread-66055::DEBUG::2016-02-17
11:05:57,540::__init__::206::jsonrpc.Notification::(emit) Sending event
{"params": {"notify_time": 4327804740,
"05681896-a76a-4ae1-879e-8fe5d28634e1": {"status": "Migration Source"}},
"jsonrpc": "2.0", "method":
"|virt|VM_status|05681896-a76a-4ae1-879e-8fe5d28634e1"}

Thread-66055::ERROR::2016-02-17
11:05:57,541::migration::310::virt.vm::(run)
vmId=`05681896-a76a-4ae1-879e-8fe5d28634e1`::Failed to migrate

Traceback (most recent call last):

  File "/usr/share/vdsm/virt/migration.py", line 294, in run

self._startUnderlyingMigration(time.time())

  File "/usr/share/vdsm/virt/migration.py", line 364, in
_startUnderlyingMigration

self._perform_migration(duri, muri)

  File "/usr/share/vdsm/virt/migration.py", line 403, in _perform_migration

self._vm._dom.migrateToURI3(duri, params, flags)

  File "/usr/share/vdsm/virt/virdomain.py", line 68, in f

ret = attr(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line
124, in wrapper

ret = f(*args, **kwargs)

  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1836, in
migrateToURI3

if ret == -1: raise libvirtError ('virDomainMigrateToURI3() failed',
dom=self)

libvirtError: unable to connect to server at 'kvm2.brightsquid.com:49152':
No route to host

Thread-68::DEBUG::2016-02-17
11:05:57,652::fileSD::173::Storage.Misc.excCmd::(getReadDelay)
/usr/bin/taskset --cpu-list 0-39 /usr/bin/dd
if=/rhev/data-center/mnt/gluster2.brightsquid.com:_home_export_iso/61827b7b-e255-44f5-a791-482a144be29f/dom_md/metadata
iflag=direct of=/dev/null bs=4096 count=1 (cwd None)

Thread-68::DEBUG::2016-02-17
11:05:57,662::fileSD::173::Storage.Misc.excCmd::(getReadDelay) SUCCESS:
 = '0+1 records in\n0+1 records out\n341 bytes (341 B) copied,
0.000713967 s, 478 kB/s\n';  = 0










Issue to connect to the gluster storage.
*
Feb 17 01:25:40 kvm2 ovirt-ha-agent:
INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Connecting
storage server
Feb 17 01:25:40 kvm2 ovirt-ha-agent:
INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Connecting
storage server
Feb 17 01:25:40 kvm2 journal: ovirt-ha-agent
ovirt_hosted_engine_ha.agent.agent.Agent ERROR Error: 'Connection to
storage server failed' - trying to restart agent
Feb 17 01:25:40 kvm2 ovirt-ha-agent:
ERROR:ovirt_hosted_engine_ha.agent.agent.Agent:Error: 'Connection to
storage server failed' - trying to restart agent
Feb 17 01:25:41 kvm2 ovirt-ha-broker:
INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection
established
Feb 17 01:25:41 kvm2 journal: ovirt-ha-broker
ovirt_hosted_engine_ha.broker.listener.ConnectionHandler ERROR Error
handling request, data: 'set-storage-domain FilesystemBackend
dom_type=glusterfs
sd_uuid=7d376952-312b-4539-b809-a8fa740f7883'#012Traceback (most recent
call last):#012  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py",
line 166, in handle#012data)#012  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py",
line 299, in _dispatch#012.set_storage_domain(client, sd_type,
**options)#012  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py",
line 66, in set_storage_domain#012self._backends[client].connect()#012
 File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py",
line 456, in connect#012self._dom_type)#012  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py",
line 108, in get_domain_path#012" in {1}".format(sd_uuid,

[ovirt-users] OVF_STORE issue after upgrading from 3.6.1 to 3.6.2

2016-01-26 Thread Luiz Claudio Prazeres Goncalves 
Hi, after upgrading from 3.6.1 to 3.6.2 I'm getting an error with
OVF_STORE. How can I recreate the OVF_STORE? In another post someone said
that i would be recreated after 1 hour, but not seems to be my case... Do I
have a way to manually regenerate ?

MainThread::WARNING::2016-01-26
12:07:56,734::ovf_store::105::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan)
Unable to find OVF_STORE

MainThread::ERROR::2016-01-26
12:07:56,735::config::234::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file)
Unable to get vm.conf from OVF_STORE, falling back to initial vm.conf

MainThread::INFO::2016-01-26
12:07:56,790::hosted_engine::464::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring)
Current state EngineUp (score: 3400)


Thanks

-Luiz
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] OVF_STORE issue after upgrading from 3.6.1 to 3.6.2

2016-01-26 Thread Luiz Claudio Prazeres Goncalves 
In fact the hosted-engine storage domain was not created on 3.6.1 and ,
therefore, that's the  OVF_STORE was not there.

It's a gluster storage where the engine is being stored, so how can I
"force" the generation of the hosted-engine storage domain ... it's not
being generated automatically, even waiting > 1 h.

Thanks
-Luiz

2016-01-26 11:17 GMT-02:00 Simone Tiraboschi <stira...@redhat.com>:

>
>
> On Tue, Jan 26, 2016 at 1:11 PM, Luiz Claudio Prazeres Goncalves <
> luiz...@gmail.com> wrote:
>
>> Hi, after upgrading from 3.6.1 to 3.6.2 I'm getting an error with
>> OVF_STORE. How can I recreate the OVF_STORE? In another post someone said
>> that i would be recreated after 1 hour, but not seems to be my case... Do I
>> have a way to manually regenerate ?
>>
>
> The engine will create the OVF_STORE only if it correctly imported the
> hosted-engine storage domain; can you please check that?
> If it's still not there and you are upgrading, maybe you have just a
> left-over from previous release where the auto-import of the hosted-engine
> storage domain wasn't that stable. Please trying manually cleaning it.
>
>
>> MainThread::WARNING::2016-01-26
>> 12:07:56,734::ovf_store::105::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan)
>> Unable to find OVF_STORE
>>
>> MainThread::ERROR::2016-01-26
>> 12:07:56,735::config::234::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file)
>> Unable to get vm.conf from OVF_STORE, falling back to initial vm.conf
>>
>> MainThread::INFO::2016-01-26
>> 12:07:56,790::hosted_engine::464::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring)
>> Current state EngineUp (score: 3400)
>>
>>
>> Thanks
>>
>> -Luiz
>>
>> ___
>> 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

Re: [ovirt-users] OVF_STORE issue after upgrading from 3.6.1 to 3.6.2

2016-01-26 Thread Luiz Claudio Prazeres Goncalves 
nyone know how to fix both
issues ? *


Thanks

-Luiz



2016-01-26 12:00 GMT-02:00 Luiz Claudio Prazeres Goncalves <
luiz...@gmail.com>:

> In fact the hosted-engine storage domain was not created on 3.6.1 and ,
> therefore, that's the  OVF_STORE was not there.
>
> It's a gluster storage where the engine is being stored, so how can I
> "force" the generation of the hosted-engine storage domain ... it's not
> being generated automatically, even waiting > 1 h.
>
> Thanks
> -Luiz
>
> 2016-01-26 11:17 GMT-02:00 Simone Tiraboschi <stira...@redhat.com>:
>
>>
>>
>> On Tue, Jan 26, 2016 at 1:11 PM, Luiz Claudio Prazeres Goncalves <
>> luiz...@gmail.com> wrote:
>>
>>> Hi, after upgrading from 3.6.1 to 3.6.2 I'm getting an error with
>>> OVF_STORE. How can I recreate the OVF_STORE? In another post someone said
>>> that i would be recreated after 1 hour, but not seems to be my case... Do I
>>> have a way to manually regenerate ?
>>>
>>
>> The engine will create the OVF_STORE only if it correctly imported the
>> hosted-engine storage domain; can you please check that?
>> If it's still not there and you are upgrading, maybe you have just a
>> left-over from previous release where the auto-import of the hosted-engine
>> storage domain wasn't that stable. Please trying manually cleaning it.
>>
>>
>>> MainThread::WARNING::2016-01-26
>>> 12:07:56,734::ovf_store::105::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan)
>>> Unable to find OVF_STORE
>>>
>>> MainThread::ERROR::2016-01-26
>>> 12:07:56,735::config::234::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file)
>>> Unable to get vm.conf from OVF_STORE, falling back to initial vm.conf
>>>
>>> MainThread::INFO::2016-01-26
>>> 12:07:56,790::hosted_engine::464::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring)
>>> Current state EngineUp (score: 3400)
>>>
>>>
>>> Thanks
>>>
>>> -Luiz
>>>
>>> ___
>>> 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