Hi Jiffin,
I'm observing the same behaviour like last time .This time after upgrading from
gluster v 7.0 to 7.2 as follows:
[2020-01-30 23:42:26.039822] T [MSGID: 0] [posix.c:2994:pl_lookup]
0-stack-trace: stack-address: 0x7f7b50003958, winding from data_fast-locks to
data_fast-access-control
whatever the default is -- since I can't get it to start up I'm not sure
how to check (this is my first attempt at Ovirt). If I could figure out how
to increase it, I suspect that would solve the problem.
On Thu, Jan 30, 2020 at 2:04 PM Strahil Nikolov
wrote:
> On January 30, 2020 7:21:55 PM
Hi,
On Thu, January 30, 2020 10:38 am, Sandro Bonazzola wrote:
>> Quick question. My engine is currently running 4.3.6. My host is still
>> at 4.1.x. I was planning (this weekend) to just yum upgrade the host
>> system to bring it up to 4.3.x.
>>
>> Is it okay for the host to be at 4.3.8
On January 30, 2020 7:21:55 PM GMT+02:00, Steve Watkins
wrote:
>> Yes that's what usually happens the VM will be paused when the
>backing storage starts
>> running out of space, try deleting the ISO from where you uploaded it
>to.
>>
>> Regards,
>>
>> Paul S.
>>
>>
On January 30, 2020 12:20:06 PM GMT+02:00, "Goorkate, B.J."
wrote:
>Hi,
>
>Thanks for the info!
>
>I tried the full heal and the stat, but the unsynced entries still
>remain.
>
>Just to be sure: the find/stat command needs to be done on files in the
>fuse-mount, right?
>Or on the brick-mount
> Yes that's what usually happens the VM will be paused when the backing
> storage starts
> running out of space, try deleting the ISO from where you uploaded it to.
>
> Regards,
>
> Paul S.
>
>
> From: Steve Watkins Sent: 29 January 2020 00:13
> To:
Once upon a time, Sandro Bonazzola said:
> I would recommend to use the engine for upgrading the hosts. It can use the
> cluster upgrade ansible role (
> https://github.com/oVirt/ovirt-ansible-cluster-upgrade/blob/master/README.md)
> and save you some time.
I guess this is the same ansible as
Il giorno gio 30 gen 2020 alle ore 16:20 Derek Atkins ha
scritto:
> Hi,
>
> Sandro Bonazzola writes:
>
> > The oVirt Project is pleased to announce the general availability of
> oVirt
> > 4.3.8 as of January 27th, 2020.
>
> First, congrats on the release.
>
> Quick question. My engine is
Hi,
Sandro Bonazzola writes:
> The oVirt Project is pleased to announce the general availability of oVirt
> 4.3.8 as of January 27th, 2020.
First, congrats on the release.
Quick question. My engine is currently running 4.3.6. My host is still
at 4.1.x. I was planning (this weekend) to just
The oVirt Team has just released a new version of ovirt-engine-metrics
package that
fixes the deployment of the metrics solution when using foreman/satellite.
The deployment was previously failing on missing rhsub_orgid in
vars.yaml.template.
We recommend to update ovirt-engine-metrics if you're
The oVirt Project is pleased to announce the availability of the oVirt
4.3.9 First Release Candidate for testing, as of January 30th, 2020.
This update is a release candidate of the nineth in a series of
stabilization updates to the 4.3 series.
This is pre-release software. This pre-release
Hi,
Thanks for the info!
I tried the full heal and the stat, but the unsynced entries still remain.
Just to be sure: the find/stat command needs to be done on files in the
fuse-mount, right?
Or on the brick-mount itself?
And other than 'gluster volume heal vmstore1 statistics', I cannot
Hi Joseph.
Yes you are pretty right.
Thanks again.
Regards,
Eugène NG
Le jeu. 30 janv. 2020 à 09:02, Joseph Goldman a
écrit :
> oVirt isn't an OS manager, it is a hardware manager. It manages the
> virtual task of plugging a hard drive in.
>
> The OS then needs to manage its hardware within
oVirt isn't an OS manager, it is a hardware manager. It manages the virtual
task of plugging a hard drive in.
The OS then needs to manage its hardware within the virtual machine. You
manage the OS.
You may set up templates and scripts that automate and roll this stuff out
for you in future.
14 matches
Mail list logo
