On Mon, Feb 24, 2020 at 4:39 PM Gianluca Cecchi
wrote:
>
> Hi,
> I'm noticing that after upgrading to 4.3.8, sometimes the dashboard is very
> slow and it takes minutes to display and to let me work, even if I'm not
> interested at all to the dashboard for the activities I have to do.
> As a
On February 24, 2020 7:50:15 PM GMT+02:00, Hesham Ahmed
wrote:
>In my case I am continuing with oVirt node 4.3.8 based gluster 6.7 for
>the
>time being. I have resolved the issue by manually copying all disk
>images
>to a new gluster volume which took days specially since disks on
>gluster
In my case I am continuing with oVirt node 4.3.8 based gluster 6.7 for the
time being. I have resolved the issue by manually copying all disk images
to a new gluster volume which took days specially since disks on gluster
still don't support sparse file copy. But the threat of a temporary network
Hey,
I do not have the faulty cluster anymore; It's a production environment
with HA requirements so I really cant take it down for days or even
worse, weeks.
I am now running of CentOS7 (manual install) with manual Gluster 7.0
installation and current ovirt. So far so good.
Time will
On February 24, 2020 5:10:40 PM GMT+02:00, Hesham Ahmed
wrote:
>My issue is with Gluster 6.7 (the default with oVirt 4.3.7) as is the
>case
>with Christian. I still have the failing volume and disks and can share
>any
>information required.
>
>On Mon, Feb 24, 2020 at 6:21 PM Strahil Nikolov
My issue is with Gluster 6.7 (the default with oVirt 4.3.7) as is the case
with Christian. I still have the failing volume and disks and can share any
information required.
On Mon, Feb 24, 2020 at 6:21 PM Strahil Nikolov
wrote:
> On February 24, 2020 1:55:34 PM GMT+02:00, Hesham Ahmed
> wrote:
Hi,
I'm noticing that after upgrading to 4.3.8, sometimes the dashboard is very
slow and it takes minutes to display and to let me work, even if I'm not
interested at all to the dashboard for the activities I have to do.
As a consequence it becomes a bottleneck.
On engine I see that during these
On February 24, 2020 1:55:34 PM GMT+02:00, Hesham Ahmed
wrote:
>Were you ever able to find a fix for this? I am facing the same problem
>and
>the case is similar to yours. We have a 6 node distributed-replicated
>Gluster, due to a network issue all servers got disconnected and upon
>recover one
we use the stats API in the engine, currently only to check if the
backend is accessible, we have plans to use it for monitoring and
validations but it is not implemented yet
On Mon, Feb 24, 2020 at 3:35 PM Nir Soffer wrote:
>
> On Mon, Feb 24, 2020 at 3:03 PM Gorka Eguileor wrote:
> >
> > On
Thanks for the clarification on this. I've realised my mistake now - I need to
configure the storage array to report the LUNs as larger than they physically
are (to account for the expected de-dup ratio). I was expecting oVirt to
magaically know about this, which when thinking it through is
On Mon, Feb 24, 2020 at 3:03 PM Gorka Eguileor wrote:
>
> On 22/02, Nir Soffer wrote:
> > On Sat, Feb 22, 2020, 13:02 Alan G wrote:
> > >
> > > I'm not really concerned about the reporting aspect, I can look in the
> > > storage vendor UI to see that. My concern is: will oVirt stop
> > >
Were you ever able to find a fix for this? I am facing the same problem and
the case is similar to yours. We have a 6 node distributed-replicated
Gluster, due to a network issue all servers got disconnected and upon
recover one of the volumes started giving the same IO error. The files can
be read
Good Day
I desperately need assistance/advice.
I am not seeing any specific reason in the logs why I am having this issue.
I tried migrating a VM again to day and basicly got the same results in the
log:
Engine Log:
2020-02-24 10:26:16,105Z INFO
13 matches
Mail list logo
