Guest VM get shutdown since last update

[MatthK]

I have a Ubuntu 20.04 LTS server that runs VirtualBox 6.1.40 r154048 (Qt5.12.8). The machine has been running flawlessly for a few months when I ran a

Code: Select all

sudo apt update && sudo apt upgrade

Since then, my two Virtual Machines keep getting shut down in less than an hour. The log file always states that it received

Code: Select all

VBoxHeadless: received singal 15

(including the typo). However, I can't figure out who or what would send the signal 15 for the VMs to shutdown.

Part of one of the log files is shown below, with the end of the boot log, and then the beginning of the shutdown. Is there a way to figure out where the signal 15 is coming from to understand why this is happening?

Code: Select all

00:00:08.392951 AHCI#0: Reset the HBA
00:00:08.392969 VD#0: Cancelling all active requests
00:00:08.411135 Enabling different vbva mode
00:00:08.414807 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=00007f9fbf000000 w=800 h=600 bpp=32 cbLine=0xC80 flags=0x1 origin=0,0
00:00:08.716410 AHCI#0: Port 1 reset
00:00:08.717739 VD#0: Cancelling all active requests
00:00:15.418694 VMMDev: Guest Additions information report: Version 6.1.38 r153438 '6.1.38_Ubuntu'
00:00:15.418724 VMMDev: Guest Additions information report: Interface = 0x00010004 osType = 0x00053100 (Linux >= 2.6, 64-bit)
00:00:15.418810 VMMDev: Guest Additions capability report: (0x0 -> 0x0) seamless: no, hostWindowMapping: no, graphics: no
00:00:15.418831 VMMDev: vmmDevReqHandler_HeartbeatConfigure: No change (fHeartbeatActive=false)
00:00:15.418848 VMMDev: Heartbeat flatline timer set to trigger after 4 000 000 000 ns
00:00:15.418862 VMMDev: Guest Log: vgdrvHeartbeatInit: Setting up heartbeat to trigger every 2000 milliseconds
00:00:15.419403 VMMDev: Guest Additions capability report: (0x0 -> 0x0) seamless: no, hostWindowMapping: no, graphics: no
00:00:15.423278 VMMDev: Guest Log: vboxguest: Successfully loaded version 6.1.38_Ubuntu r153438
00:00:15.423294 VMMDev: Guest Log: vboxguest: misc device minor 59, IRQ 20, I/O port d040, MMIO at 00000000f0400000 (size 0x400000)
00:00:15.700512 AC97: Reset
00:00:15.700554 AC97: Mixer reset (EAID=0x809, EACS=0x9)
00:00:15.700560 AC97: Record select to left=mic, right=mic
00:00:15.700843 AC97: Reset
00:00:15.700848 AC97: Mixer reset (EAID=0x809, EACS=0x9)
00:00:15.700852 AC97: Record select to left=mic, right=mic
00:00:15.704295 AC97: Record select to left=mic, right=mic
00:23:28.732404 VBoxHeadless: received singal 15
00:23:28.732462 VBoxHeadless: processEventQueue: VINF_INTERRUPTED, termination requested
00:23:28.734283 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Running, InUninit=1)
00:23:28.734313 Console: Machine state changed to 'Stopping'
00:23:28.734477 Changing the VM state from 'RUNNING' to 'POWERING_OFF'
00:23:28.734511 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={The object is not ready}, preserve=false aResultDetail=0
00:23:28.734891 ****************** Guest state at power off for VCpu 3 ******************
00:23:28.734919 Guest CPUM (VCPU 3) state: 
00:23:28.734924 rax=ffffffff8e6f7c70 rbx=0000000000000003 rcx=0000000000000001 rdx=000000000031cfb6
00:23:28.734929 rsi=0000000000000087 rdi=0000000000000003 r8 =0000000000000003 r9 =0000000000022f80
00:23:28.734932 r10=ffff9d8757b9c848 r11=0000000000000000 r12=0000000000000003 r13=ffff9d8756a7de00
00:23:28.734936 r14=0000000000000000 r15=0000000000000000
00:23:28.734937 rip=ffffffff8e6f805e rsp=ffffae39c0093e70 rbp=ffffae39c0093e90 iopl=0         nv up ei pl nz na po nc
00:23:28.734941 cs={0010 base=0000000000000000 limit=ffffffff flags=0000a09b}
00:23:28.734943 ds={0000 base=0000000000000000 limit=ffffffff flags=0001c000}
00:23:28.734945 es={0000 base=0000000000000000 limit=ffffffff flags=0001c000}
00:23:28.734946 fs={0000 base=0000000000000000 limit=ffffffff flags=0001c000}
00:23:28.734947 gs={0000 base=ffff9d8757b80000 limit=ffffffff flags=0001c000}
00:23:28.734949 ss={0018 base=0000000000000000 limit=ffffffff flags=0000c093}
00:23:28.734950 cr0=0000000080050033 cr2=00007fe32cd69400 cr3=0000000212452005 cr4=00000000000606e0
00:23:28.734953 dr0=0000000000000000 dr1=0000000000000000 dr2=0000000000000000 dr3=0000000000000000
00:23:28.734955 dr4=0000000000000000 dr5=0000000000000000 dr6=00000000ffff0ff0 dr7=0000000000000400
00:23:28.734956 gdtr=fffffe00000ac000:007f  idtr=fffffe0000000000:0fff  eflags=00000246
00:23:28.734959 ldtr={0000 base=00000000 limit=ffffffff flags=0001c000}
00:23:28.734961 tr  ={0040 base=fffffe00000ae000 limit=0000206f flags=0000008b}
00:23:28.734963 SysEnter={cs=0010 eip=ffffffff8e801720 esp=fffffe00000ae000}
00:23:28.734965 xcr=0000000000000007 xcr1=0000000000000000 xss=0000000000000000 (fXStateMask=0000000000000007)
00:23:28.734968 FCW=037f FSW=0000 FTW=0000 FOP=0000 MXCSR=00001fa5 MXCSR_MASK=0000ffff
00:23:28.734971 FPUIP=00000000 CS=0000 Rsrvd1=0000  FPUDP=00000000 DS=0000 Rsvrd2=0000
00:23:28.734974 ST(0)=FPR0={0000'00000000'00000000} t0 +0.0000000000000000000000 * 2 ^ -16383 (*)
00:23:28.734979 ST(1)=FPR1={0000'00000000'00000000} t0 +0.0000000000000000000000 * 2 ^ -16383 (*)
00:23:28.734982 ST(2)=FPR2={0000'00000000'00000000} t0 +0.0000000000000000000000 * 2 ^ -16383 (*)
00:23:28.734984 ST(3)=FPR3={0000'00000000'00000000} t0 +0.0000000000000000000000 * 2 ^ -16383 (*)
00:23:28.734987 ST(4)=FPR4={0000'00000000'00000000} t0 +0.0000000000000000000000 * 2 ^ -16383 (*)
00:23:28.734989 ST(5)=FPR5={0000'00000000'00000000} t0 +0.0000000000000000000000 * 2 ^ -16383 (*)
00:23:28.734991 ST(6)=FPR6={0000'00000000'00000000} t0 +0.0000000000000000000000 * 2 ^ -16383 (*)
00:23:28.734993 ST(7)=FPR7={0000'00000000'00000000} t0 +0.0000000000000000000000 * 2 ^ -16383 (*)

[scottgus1]

According to a quick web-search,

SIGTERM (signal 15) is used in Unix-based operating systems, such as Linux, to terminate a process.

Since the VBoxHeadless process received signal 15, I'd supposed as a guess that something on the host is asking VboxHeadless to kill the VM. I'd look into any logging info Linux might have on what is ordering the signal 15. It does not appear to be coming from Virtualbox or the VM.

[MatthK]

Thanks for the reply.

Surprisingly after the two VMs have failed multiple times, I rebooted the host and since then the two VMs have run through the whole weekend without a glitch.

I did check the Syslog of the host before, but couldn't find anything that would point to the signal 15 trigger.

Hopefully it will remain stable again going forward.