Multiple qemu nodes freezes at grub if started together

[luizluca]

Describe the bug
I have dozens of qemu nodes (openwrt). If I start all of them together, many of them freezes at the grub menu. Some of them before and some after the countdown message appears:

" The highlighted entry will be executed automatically in 5s."

GNS3 version and operating system (please complete the following information):

• OS: Linux
• GNS3 version 2.1.28 (but it has been happening for years)
• I'm running GNS3 server in a VBox (nodes runs with nested virtualization)

To Reproduce
Steps to reproduce the behavior:

1. Create multiple qemu nodes (e.g. openwrt)
2. Click to start all nodes

Screenshots or videos
There is no visual clue it is frozen but the frozen serial output:

                             GNU GRUB  version 2.02

 +----------------------------------------------------------------------------+
 |*OpenWrt                                                                    | 
 | OpenWrt (failsafe)                                                         |
 |                                                                            |
 |                                                                            |
 |                                                                            |
 |                                                                            |
 |                                                                            |
 |                                                                            |
 |                                                                            |
 |                                                                            |
 |                                                                            | 
 +----------------------------------------------------------------------------+

      Use the ^ and v keys to select which entry is highlighted.          
      Press enter to boot the selected OS, `e' to edit the commands       
      before booting or `c' for a command-line. ESC to return             
      previous menu.                                                      
   The highlighted entry will be executed automatically in 5s.        

Additional context
It might be a Vbox bug or even a grub bug but gns3 is a pretty good way to trigger it.

[luizluca]

I've opened a forum thread 2 years ago with no answer.
https://gns3.com/community/featured/gns3-nodes-qemu-running-in-a-vm-nested-with-virtualbox-hangs-at-boot-grub-when-started-all-together

[luizluca]

This is qemu log:

Execution log:
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
KVM: entry failed, hardware error 0x80000021

If you're running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.

EAX=00000010 EBX=0000c866 ECX=00040000 EDX=0ff8f7c0
ESI=0ff8f760 EDI=00000005 EBP=00001ff0 ESP=00001ff0
EIP=000082fd EFL=00010006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     00008280 00000027
IDT=     00000000 000003ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=ef 82 00 00 08 00 66 b8 10 00 8e d8 8e c0 8e e0 8e e8 8e d0 <8b> 04 24 a3 f0 1f 00 00 a1 64 82 00 00 89 c4 89 c5 a1 f0 1f 00 00 89 04 24 31 c0 0f 01 0d

The "qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]" also appears when the machine does work. The following error that is specific for when the machine crashes. And it is unrelated as we can workaround it using '-host cpu' while the crash still happens.

[spikefishjohn]

I’m going to guess this is a virtual box bug with qemu. I remember there was a big bug posting about nested VM support with virtual box that I think is still open. On May 4, 2022, at 2:03 PM, Luiz Angelo Daros de Luca ***@***.***> wrote:  This is qemu log: Execution log: qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] KVM: entry failed, hardware error 0x80000021 If you're running a guest on an Intel machine without unrestricted mode support, the failure can be most likely due to the guest entering an invalid state for Intel VT. For example, the guest maybe running in big real mode which is not supported on less recent Intel processors. EAX=00000010 EBX=0000c866 ECX=00040000 EDX=0ff8f7c0 ESI=0ff8f760 EDI=00000005 EBP=00001ff0 ESP=00001ff0 EIP=000082fd EFL=00010006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 00008280 00000027 IDT= 00000000 000003ff CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=ef 82 00 00 08 00 66 b8 10 00 8e d8 8e c0 8e e0 8e e8 8e d0 <8b> 04 24 a3 f0 1f 00 00 a1 64 82 00 00 89 c4 89 c5 a1 f0 1f 00 00 89 04 24 31 c0 0f 01 0d The "qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]" also appears when the machine does work. The following error that is specific for when the machine crashes. — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_GNS3_gns3-2Dgui_issues_3330-23issuecomment-2D1117646432&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FE37reF58EJ068QV2lxJ8DremMjgvfNGe2chbX6QsUA&m=wabghSd88xMbgSFdwaQurluGiJqipK3QTbspeYUOsVk&s=4AxgOLOWGJq7uUd7sRFeaijaPn09ztXhnuAjw0KfuB8&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AHRRFIGUEJFIKK6C7FA6YJDVIK3U7ANCNFSM5VCWP64A&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FE37reF58EJ068QV2lxJ8DremMjgvfNGe2chbX6QsUA&m=wabghSd88xMbgSFdwaQurluGiJqipK3QTbspeYUOsVk&s=X97TbfCYhPfgDnj9b1HmKmdU59vLaP3CGRQCPtok29A&e=>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[grossmj]

It would be worth to try using VMware workstation player just to confirm this is a bug in VirtualBox.

[grossmj]

Unfortunately I don't think we can do much about this issue.