[SLV] Cauldron VM sessions crashing back to the login screen

[epp]

I have Cauldron installed in a virtual machine through virt-manager (host OS is Mageia 8) and today, the sessions have crashed five times so far, going straight back to the login screen. At the time of each of the crashes, I was using either Firefox (102.0esr) or Chromium (103.0.5060.53), normal web browsing, scrolling through a page, when everything just freezes, crashes (screen goes to black) and eventually displays the login screen.

As to the comment in the log: "your system is too slow", the host CPU is an AMD Athlon II X2 260 (2) @ 3.200GHz with 8 Gb of RAM. I allocated 4 Gb for the virtual machine. Both the host and virtual machine are running the LXQt desktop. Host GPU is: AMD ATI Radeon 3000 (RS780L)

Neofetch reports the virtual machine CPU, GPU and memory as:

Code: Select all

CPU: AMD Opteron 23xx (Gen 3 Class Opteron) (2) @ 3.200GHz
GPU: 00:01.0 Red Hat, Inc. QXL paravirtual graphic card
Memory: 946MiB / 3932MiB

I looked at the Xorg.0.log.old file which terminated at this last crash and the end of the log is below, from where the problem begins. If I need to report this as a bug, I'm not sure under which package.

Code: Select all

[  2852.120] (EE) event5  - spice vdagent tablet: client bug: event processing lagging behind by 22ms, your system is too slow
[  3209.372] (EE) qxl(0): error doing QXL_ALLOC
[  3209.372] (EE)
[  3209.372] (EE) Backtrace:
[  3209.372] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x5a5b99]
[  3209.374] (EE) 1: /lib64/libc.so.6 (__sigaction+0x50) [0x7fa121e4e3a0]
[  3209.375] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  3209.375] (EE) 2: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7fa12165caff]
[  3209.376] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  3209.376] (EE) 3: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7fa12165d2ae]
[  3209.380] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  3209.380] (EE) 4: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7fa12165e47f]
[  3209.380] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  3209.380] (EE) 5: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7fa12166aab4]
[  3209.380] (EE) 6: /usr/libexec/Xorg (miCopyRegion+0x93) [0x5838f3]
[  3209.380] (EE) 7: /usr/libexec/Xorg (miDoCopy+0x44c) [0x58402c]
[  3209.381] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  3209.381] (EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7fa121669cd5]
[  3209.381] (EE) 9: /usr/libexec/Xorg (DamageRegionAppend+0x3280) [0x519010]
[  3209.381] (EE) 10: /usr/libexec/Xorg (SendGraphicsExpose+0x2b6) [0x43b7b6]
[  3209.382] (EE) 11: /usr/libexec/Xorg (SendErrorToClient+0x3b4) [0x43f804]
[  3209.382] (EE) 12: /usr/libexec/Xorg (InitFonts+0x3ac) [0x44363c]
[  3209.382] (EE) 13: /lib64/libc.so.6 (__libc_start_call_main+0x67) [0x7fa121e3b177]
[  3209.383] (EE) 14: /lib64/libc.so.6 (__libc_start_main+0x85) [0x7fa121e3b235]
[  3209.383] (EE) 15: /usr/libexec/Xorg (_start+0x21) [0x42d9b1]
[  3209.383] (EE)
[  3209.383] (EE) Segmentation fault at address 0x0
[  3209.383] (EE)
Fatal server error:
[  3209.383] (EE) Caught signal 11 (Segmentation fault). Server aborting
[  3209.383] (EE)
[  3209.383] (EE)
Please consult the Mageia support
         at https://bugs.mageia.org
 for help.
[  3209.383] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[  3209.383] (EE)
[  3209.406] (EE) Server terminated with error (1). Closing log file.


Thank you for any help.

[sturmvogel]

Did you search Bugzilla or dev ML for this problem (as recommended in https://wiki.mageia.org/en/Cauldron)? Also if you google, there are many reports that Xorg crashes with "error doing QXL_ALLOC" running on libvirt, qemu, qxl and spice, kvm. Also your CPU and IGP is not the best choise for running VM's on it (power and performance wise).
I also made some experiences with virt-manager the last days. I'm absoutely unsatisfied with the performance, reliability and predictability of vm' s with virt-manager. What works in one session, won't work anymore in the next one, internet connection won't work on reboot of vm and similar stuff.....So i removed virt-manager again and stick to Virtualbox for testing of cauldron, and other test scenarios....

Can you repeat the same behaviour if you fire up a MGA8 guest on this MGA8 host in virt-manager?

[epp]

I joined dev ML yesterday, I'll copy and paste the info to the list and will also install MGA8 in its on VM.

My only experience creating and using VM's is with virt-manager and with Gnome Boxes on a distro I used in the past. most of this experience was with virt-manager. Between the two, Gnome Boxes was easier to use.

Thanks.

[epp]

I have created a VM with Mageia 8 in it and will test it.

As for bug reports, I found two, one each at Red Hat (2020633) and Debian (1004154). The Red Hat report offered a suggestion to change the video from QXL to Virtio, which would make it run slower. The Debian report suggested increasing the vram. In both reports, the same individual reported downgrading the kernel from 5.15.0 to 5.10.0 fixed the problem. I do not see a vram option in virt-manager, only for the total amount of memory, I could increase it by 256Mb to see if it makes a difference. The other video selections in addition to QXL and Virtio, are Bochs, Ramfb and VGA.

[epp]

The Cauldron VM will only boot up to a login screen with the video on QXL. I tried VGA, Virtio and Ramfb, staring at a blank screen on all three. Did not try Bochs. I increased the amount of memory by 256Mb to see if that makes a difference. With LXQt running in the background and only Chromium open along with QTerminal, neofetch is reporting: Memory: 741MiB / 4178MiB.

The Mageia 8 VM was created with a full 4Gb of memory.

[Bequimao]

The theme is too complex to follow your post even for someone who uses Mageia and Virt-Manager.
Which guide did you follow basically?

First question: Is IOMMU activated in the kernel parameters of the host?

Best regards,
Bequimao

[sturmvogel]

The theme is too complex to follow your post even for someone who uses Mageia and Virt-Manager.

Why do you believe so? The topic was properly placed at the dev ML and for people who uses cauldron/testing/backports and other technically interested people not hard to follow.

Is IOMMU activated in the kernel parameters of the host?

How should this be related to the problem? epp's vm start and run and after some time Xorg/graphics crashes (the cauldron one).

[epp]

I have since expanded the amount of vram for the VM from the default (64Mb) to 256Mb and the VM has so far not crashed. It's been running fine since the change.

[sturmvogel]

This sounds reasonable. 64Mb are really low even for a "light" desktop environment like Lxqt.

[epp]

It does seem low. I looked at one of the XML files for another VM and that also had 64Mb for vram, so that appears to be the virt-manager default for a new VM once it's created. It's been running for almost an hour and a half now, no crashes.

[epp]

It was the vram setting at 64 MiB that was causing the crashes. With 256 MiB for vram (video memory), not one crash.

To benefit others, from a terminal (as root/superuser) type:

Code: Select all

virsh edit DOMAIN

where DOMAIN is the name of the virtual machine chosen when it was created. vim will launch and open the associated XML file.

Scroll down until you find

Code: Select all

vram

It should show:

Code: Select all

'65536'

remove the 65536 and replace with:

Code: Select all

262144

between single quotes, it should now show:

Code: Select all

'262144'

Then save the file. When it exits, there will be a message in the terminal that the configuration was changed.

[epp]

I found https://www.ovirt.org/develop/internal/video-ram.html yesterday evening, which has an excellent explanation of the memory settings of the <video> attribute in the libvirt domain XML.

I switched the memory entries for <ram> and <vram> (primary and secondary memory bars), so that 512 MiB (524288) is now the primary memory and 64 MiB (65536) is the secondary. The third setting <vgamem>, has a default of 16 MiB (16384) and changing that setting will affect the video, this was left as is.

The Cauldron VM has been running for five hours now (at this writing) and although Firefox eventually became (mostly) unresponsive (until I killed its PID), X has not crashed.

Once I relaunched Firefox, I noticed that the Hardware Acceleration option was checked, I unchecked this and will review/change the same setting in Chromium.

[epp]

I switched the memory entries for <ram> and <vram> (primary and secondary memory bars), so that 512 MiB (524288) is now the primary memory and 64 MiB (65536) is the secondary. The third setting <vgamem>, has a default of 16 MiB (16384) and changing that setting will affect the video, this was left as is.

The above settings in the XML file resvolved the crashes. Not one crash since. Marking the thread SOLVED.

[morgano]

Great
Is this general enough it should be noted in our wiki?
Somewhere... https://wiki.mageia.org/en/Category:Virtualisation

[epp]

Great
Is this general enough it should be noted in our wiki?
Somewhere... https://wiki.mageia.org/en/Category:Virtualisation

It wouldn't hurt. From what I was able to determine, the higher the <ram> entry, the better. I would suggest that if using a web browser in a VM (Firefox/Chromium), that hardware acceleration be turned off in the settings.

I am still trying to figure out why Firefox and Chromium will occasionally freeze (but not crash). In Firefox's config (about:config), toggling fission.autostart to false, brings back the Content Process Limit pull-down in Firefox 102's Settings and I have now set this to 4 to see if it makes any difference. The Content Process Limit can otherwise be changed directly in about:config, by changing the value of dom.ipc.processCount to anything between 1 and 8.

I looked at the virt-manager link on the above page. Regarding Shorewall, I only had to add

Code: Select all

net    <virtual interface ID>        detect

to /etc/shorewall/interfaces and all the VM's have worked fine.

[sturmvogel]

In Firefox's config (about:config), toggling fission.autostart to false,

Im strongly against putting this into our wiki. You are willingly disabling safety features of firefox with this setting! Have a read here: https://wiki.mozilla.org/Project_Fission

As already noted at another point i still believe that your computer is a little bit to weak/old to power VM's. Your host needs ressources and your quest requires also ressources at the same time ...really weak IGP, old CPU, ...leads to "hangs". Thats propably the reason why you have problems with your VM's.

[epp]

In Firefox's config (about:config), toggling fission.autostart to false,

Im strongly against putting this into our wiki. You are willingly disabling safety features of firefox with this setting! Have a read here: https://wiki.mozilla.org/Project_Fission

Thanks for the link, in full agreement. I'm reversing that change now.

[epp]

As already noted at another point i still believe that your computer is a little bit to weak/old to power VM's. Your host needs ressources and your quest requires also ressources at the same time ...really weak IGP, old CPU, ...leads to "hangs". Thats propably the reason why you have problems with your VM's.

The only remaining issue is with the web browsers freezing. In virt-manager, there is an option to switch the CPU, but it's only accessible while the VM is actually running. One of the options in the pull-down list is host-passthrough. I switched it from the virtual default (Opteron 3) and rebooted it. Neofetch is now displaying that the VM is using the host CPU. I have added a widget included with LXQt (host desktop) that can be set to monitor the CPU temperature (in C° on this PC) and there is no issue with the temperature, showing 35°C currently, it indicates there is a max of 70°C and critical is 200°C.

I can certainly understand a virtual CPU being inadequate.

[epp]

The only remaining issue is with the web browsers freezing. In virt-manager, there is an option to switch the CPU, but it's only accessible while the VM is actually running. One of the options in the pull-down list is host-passthrough. I switched it from the virtual default (Opteron 3) and rebooted it. Neofetch is now displaying that the VM is using the host CPU. I have added a widget included with LXQt (host desktop) that can be set to monitor the CPU temperature (in C° on this PC) and there is no issue with the temperature, showing 35°C currently, it indicates there is a max of 70°C and critical is 200°C.

I can certainly understand a virtual CPU being inadequate.

Switching the CPU setting to host-passthrough, has resolved the issue of Firefox and Chromium freezing. The default virtual GPU (Opteron G3 setting) wasn't adequate and with both of them now using the host CPU, zero crashes, zero problems with them. And I have changed the Content Process Limit in Firefox back to the default 8.

Thank you all for the replies, advice and suggestions.

[epp]

I may have found the cause of the browsers freezing in the VM's, it may be the LX* desktops. I am aware that both share a common code base.

Once I added the Xfce desktop to the virtual machine, the browsers stopped freezing.