On Tue, Jun 16, 2020 at 11:01 PM Joop <jvdwege(a)xs4all.nl> 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 preallocated and sometimes thin-provisioned for the disk(s).
Don't know why and I don't think there is a pattern.
Maybe the system selects a different storage domain? On block storage the
default is preallocated, but on file based storage the default is thin.
Old VMs from 3.3 or
new ones from 4.2/3, its mixed.
I almost always use thin-provisioned but one or two could have been
preallocated by accident.
How do I check?
If the question was about creating images with:
qemu-img create -f qcow2 -o preallocation=metadata ...
Then it is easy, ovirt does not create such images.
Joop
>
> На 16 юни 2020 г. 20:23:17 GMT+03:00, Joop <jvdwege(a)xs4all.nl> написа:
>> 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: ../../grub-core/kern/dl.c:266:invalid arch-independent ELF
>> maginc.
>>> entering rescue mode...
>>>
>>> Doing a CTRL-ALT-Del through the spice console let the VM boot
>>> correctly. Shutting it down and repeating the procedure I get a disk
>>> problem everytime. Weird thing is if I activate the BootMenu and then
>>> straight away start the VM all is OK.
>>> I don't see any ERROR messages in either vdsm.log, engine.log
>>>
>>> If I would have to guess it looks like the disk image isn't connected
>>> yet when the VM boots but thats weird isn't it?
>>>
>> As a follow up I tried a couple of other things:
>> - installed CentOS-7 and oVirt 4.3.10 using HCI and same problem
>> (the previous install of 4.3 was a upgraded version. Don't know the
>> start versie)
>> - did some testing with copying large files into the engine gluster
>> volume through /rhev/datacenter using 'cp' and no problems
>> - used qemu-img convert with the engine gluster volume as destination
>> --> problems
>> - had a good look through lots of logfiles and stumbled across an error
>> about missing shard which aligned with qemu-img errors
>> - turned features.shard off on the volume and restarted the volume
>> - reran the tests with qemu-img --> no problems any more.
>> - reinstalled Centos8.2 + oVirt-4.0, turned off sharding before
>> starting
>> the engine install
>> --> no problems installing, no problems importing, no problems starting
>> vms, sofar
>>
>> I need to install another server tomorrow, so I'll do that with
>> sharding
>> enabled and see if it crashes too and then get the logs some place
>> safe.
>>
>> Regards,
>>
>> Joop
>>
>> _______________________________________________
>> Users mailing list -- users(a)ovirt.org
>> To unsubscribe send an email to users-leave(a)ovirt.org
>> Privacy Statement:
https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>>
https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>>
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6TNJYNVBJWC...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7BPONTX2FDD...