I had the same problem when booting vm's in ovirt 4.4.0 .
The legacy bios could not detect the disk to boot up and yes as suspected was
a storage problem with gluster.
After upgrade to ovirt 4.4.1 and run again "Optimize for virt store " i dont
see this boot problem anymore, but maybe is
June 17, 2020 8:11 AM, "Krutika Dhananjay" wrote:
> Yes, so the bug has been fixed upstream and the backports to release-7 and
> release-8 of gluster
> pending merge. The fix should be available in the next .x release of
> gluster-7 and 8. Until then
> like Nir suggested, please turn off
Krutika Dhananjay wrote:
Yes, so the bug has been fixed upstream and the backports to release-7
and release-8 of gluster pending merge. The fix should be available in
the next .x release of gluster-7 and 8. Until then like Nir suggested,
please turn off performance.stat-prefetch on your
Yes, so the bug has been fixed upstream and the backports to release-7 and
release-8 of gluster pending merge. The fix should be available in the next
.x release of gluster-7 and 8. Until then like Nir suggested, please turn
off performance.stat-prefetch on your volumes.
-Krutika
On Wed, Jun 17,
On Mon, Jun 8, 2020 at 3:10 PM Joop wrote:
>
> On 3-6-2020 14:58, Joop wrote:
> > Hi All,
> >
> > Just had a rather new experience in that starting a VM worked but the
> > kernel entered grub2 rescue console due to the fact that something was
> > wrong with its virtio-scsi disk.
> > The message
Hey Nir,
in ovirt 4.3.something the default behaviour for Gluster changed from thin
to fully allocated.
My guess is that the shard xlator cannot catch up with the I/O.
Do you think that I should file a RFE to change the shard size ?
As far as I know RedHat support only 512MB shard size,
On Tue, Jun 16, 2020 at 11:01 PM Joop wrote:
>
> On 16-6-2020 19:44, Strahil Nikolov wrote:
> > Hey Joop,
> >
> > are you using fully allocated qcow2 images ?
> >
> > Best Regards,
> > Strahil Nikolov
> >
> I noticed that when I use import VM from an Export domain I see that it
> sometimes uses
On 16-6-2020 19:44, Strahil Nikolov wrote:
> Hey Joop,
>
> are you using fully allocated qcow2 images ?
>
> Best Regards,
> Strahil Nikolov
>
I noticed that when I use import VM from an Export domain I see that it
sometimes uses preallocated and sometimes thin-provisioned for the disk(s).
Don't
On Wed, Jun 10, 2020 at 6:32 PM Joop wrote:
>
> On 8-6-2020 19:55, Joop wrote:
> > On 8-6-2020 17:52, Strahil Nikolov wrote:
> >> Are you using ECC ram ?
> > No, but what are the chances that starting a VM by using Run directly vs
> > using the Boot wait menu and it hitting that bad bit each and
Hey Joop,
are you using fully allocated qcow2 images ?
Best Regards,
Strahil Nikolov
На 16 юни 2020 г. 20:23:17 GMT+03:00, Joop написа:
>On 3-6-2020 14:58, Joop wrote:
>> Hi All,
>>
>> Just had a rather new experience in that starting a VM worked but the
>> kernel entered grub2 rescue
On 3-6-2020 14:58, Joop wrote:
> Hi All,
>
> Just had a rather new experience in that starting a VM worked but the
> kernel entered grub2 rescue console due to the fact that something was
> wrong with its virtio-scsi disk.
> The message is Booting from Hard Disk
> error:
On 8-6-2020 19:55, Joop wrote:
> On 8-6-2020 17:52, Strahil Nikolov wrote:
>> Are you using ECC ram ?
> No, but what are the chances that starting a VM by using Run directly vs
> using the Boot wait menu and it hitting that bad bit each and every time?
> BTW: this setup worked perfectly for over 9
On 8-6-2020 19:56, Stephen Panicho wrote:
> I ended up making a BZ about this same issue a few weeks ago, but
> misdiagnosed the root cause. Maybe we could add to that?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1839598
And maybe change the title to something else.
I'm ok with my logs/mail
I ended up making a BZ about this same issue a few weeks ago, but
misdiagnosed the root cause. Maybe we could add to that?
https://bugzilla.redhat.com/show_bug.cgi?id=1839598
On Mon, Jun 8, 2020, 11:54 AM Strahil Nikolov via Users
wrote:
> Are you using ECC ram ?
>
> Best Regards,
> Strahil
On 8-6-2020 17:52, Strahil Nikolov wrote:
> Are you using ECC ram ?
No, but what are the chances that starting a VM by using Run directly vs
using the Boot wait menu and it hitting that bad bit each and every time?
BTW: this setup worked perfectly for over 9 months using 4.3.X.
Joop
> Best
Are you using ECC ram ?
Best Regards,
Strahil Nikolov
На 8 юни 2020 г. 15:06:22 GMT+03:00, Joop написа:
>On 3-6-2020 14:58, Joop wrote:
>> Hi All,
>>
>> Just had a rather new experience in that starting a VM worked but the
>> kernel entered grub2 rescue console due to the fact that something
> On 4 Jun 2020, at 13:08, Joop wrote:
>
> On 3-6-2020 22:13, Strahil Nikolov wrote:
>> Is it UEFI based or the lagacy bios ?
> Legacy BIOS.
>
> Hi,
it is indeed weird and I’m afraid there’s no clear indication where to start.
maybe try with different guests?
create a different VM and
On 3-6-2020 22:13, Strahil Nikolov wrote:
> Is it UEFI based or the lagacy bios ?
Legacy BIOS.
Joop
>
> Best Regards,
> Strahil Nikolov
>
> На 3 юни 2020 г. 19:00:48 GMT+03:00, Marco Fais написа:
>> Hi Joop
>>
>> I am having the same problem -- thought initially was due to the VM
>> import
>>
Is it UEFI based or the lagacy bios ?
Best Regards,
Strahil Nikolov
На 3 юни 2020 г. 19:00:48 GMT+03:00, Marco Fais написа:
>Hi Joop
>
>I am having the same problem -- thought initially was due to the VM
>import
>but it is now happening even on newly created VMs.
>Rebooting (e.g.
Hi Joop
I am having the same problem -- thought initially was due to the VM import
but it is now happening even on newly created VMs.
Rebooting (e.g. ctrl-alt-del) the machine a couple of times solves the
issue, but a power off / power on might cause it again...
Not sure how best to capture this
On 3-6-2020 14:58, Joop wrote:
> Hi All,
>
> Just had a rather new experience in that starting a VM worked but the
> kernel entered grub2 rescue console due to the fact that something was
> wrong with its virtio-scsi disk.
> The message is Booting from Hard Disk
> error:
21 matches
Mail list logo
