My KVM guest shuts down automatically

Hello:

KVM guest shuts down automatically during some period (aprox each two days), this is very annoying. I’m using KVM host (openSUSE 13.1 x86_64 Kernel 3.11.10 ) and guest (Windows 7 - 32 bits). I search in some forums and later I installed acpi and acpid packages, but nothing.

I don’t know how to fix this in KVM.

The log is (is rare that the log file not show the today register):


2014-08-18 13:20:28.328+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name numerabilis -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 827d3874-1848-97de-d992-d4f211c8e965 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/numerabilis.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/numerabilis.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:4e:9e:09,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device VGA,id=video0,bus=pci.0,addr=0x2 -device usb-host,hostbus=5,hostaddr=2,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
char device redirected to /dev/pts/0 (label charserial0)
qemu: terminating on signal 15 from pid 1829
2014-08-22 12:59:01.305+0000: shutting down
2014-08-22 13:04:09.592+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name numerabilis -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 827d3874-1848-97de-d992-d4f211c8e965 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/numerabilis.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/numerabilis.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:4e:9e:09,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device VGA,id=video0,bus=pci.0,addr=0x2 -device usb-host,hostbus=5,hostaddr=2,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
char device redirected to /dev/pts/0 (label charserial0)

First, you should identify which log you are posting… I suspect this is a QEMU or KVM log on the Host, but cannot be sure. It’s definitely not the systlog.

The problem with the log you posted is that it only reports that a process issued a signal 15, but the process id will vary every time the process is initiated.

Possibly the syslog will be more informative, the next time your machine shuts down on its own, you can run the following on the Host which displays the last 50 lines

tail -n=50 /var/log/messages

You can also see if something useful might be in the Guest syslog, but at this point I doubt it because I suspect the command to kill the Guest is coming from outside the Guest.

There are various Google hits on the query “qemu: terminating on signal 15 from pid” but I don’t see any results I believe truly provide a solution.

TSU

Thanks for your response. The log flie “/var/log/messages” doesn’t exist. I try again but this time I created another VM (with WinXP SP3) and after two days, both VM are off. This is a critical bug, but I only use stable repositories, so I don’t know how to fix this.

Maybe KVM is garbage.

:slight_smile:
/var/log/messages does exist. Always exists in nearly every distro, is the fundamental log for many distros including openSUSE.
My guess is that you’re not running the command as root. Open a regular console, then type “su” followed by your password. Then run the command again.

I doubt there is a widespread KVM issue, else it would be seen and reported by many people. So, need to figure out what is unique with your setup.

Also, to display some basic information about your machine… As long as you should have a root console open you should also run the following command and post the result

cat /etc/*release | grep PRETTY_NAME= && uname -a

TSU

I know, but really, the file does not exist.

I’m root.

Linux zenki 3.11.10-17-default #1 SMP Mon Jun 16 15:28:13 UTC 2014 (fba7c1f) x86_64 x86_64 x86_64 GNU/Linux

Note: I try in two VM, one created by VirtualMachineManager 0.9.5 and another created in the terminal(vm-install), the result is the same.

It will only exist and logged to if you have a syslog daemon installed and running, which might not be done by default, at least not if you do a “minimal server” install.

The logging is normally done via systemd-journald nowadays which uses binary files in /var/log/journal/ that can be accessed via “journalctl”.

If you install a syslog daemon, journald will pass on the log messages to it, which in turn will write them to /var/log/messages and other files.

So install e.g. “rsyslog” to have your logs go to /var/log/messages.

Absolutely right, /var/log/messages may either not exist (in my JeOS images) or exists but is empty (in my minimal server images).
Just shows how few problems I’ve had running those systems (and I’ve been running many of them).

So, you should use “journalctl” instead of the reference to “messages” in my suggested commands, eg
The following should display the last 10 entries

journalctl | tail

And the following should list the entries including time your most recent bootups (which should logically follow a shutdown of any sort whether intentional or not)

journalctl | grep boot

The command about system information is more useful about your HostOS (not your Guest) although in some situations might be useful in the Guest as well.
This is because the hardware and HostOS setup can vary greatly but the Guests will be pretty much standardized because of the virtualization environment.

TSU

Thanks. I want to clarify something: My host machine always is running, BUT the guest machine (VM) have the problem (shutdown each two days aprox).

I used journalctl I can see many “reverse mapping” from unknown hosts, so I disabled the wan interface and my VM is running since 3 days ago.

I don’t know how the “automated attack on SSH” can shutdown my VM, very strange.

My journalctl | grep boot only have one line, of course:


ago 29 21:41:56 zenki kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.10-17-default root=UUID=c098f140-0d78-46e0-80fe-9d75df459f6b resume=/dev/disk/by-id/scsi-3600508b1001037383941424344450600-part2 splash=silent quiet showopts

I uploaded my filejournal output in mega: https://mega.co.nz/#!h14EUawa!1IAY-q0TZMH42YQnlq4Jv0B-Ol9XG4oQgATCjOL1l0A

[QUOTE=zchronos;2662912]Thanks. I want to clarify something: My host machine always is running, BUT the guest machine (VM) have the problem (shutdown each two days aprox).

I used journalctl I can see many “reverse mapping” from unknown hosts, so I disabled the wan interface and my VM is running since 3 days ago.

I don’t know how the “automated attack on SSH” can shutdown my VM, very strange.

/QUOTE]

Maybe time to consider an auto-blocking script.
I can’t remember what I’ve installed in openSUSE before (been many years since I’ve had to deal with ssh attacks),
A quick search turns of the the following I’ve never heard of before
http://www.pettingers.org/code/sshblack.html

The bootup entry by itself isn’t going to be useful, it’s only to locate the exact time of the bootup so you can read the preceding entries that led to the shutdown.

You may also want to re-tune your Host to accomodate Guests if this is its sole function. By default, practically all Linux distros (except possibly the distros labeled “Enterprise”) are tuned very conservatively to run on limited hardware. You will probably want to re-allocate resources from general purpose apps to networking on a high traffic Host. Instructions can be found on a writeup I did years ago but still relevant to this type of scenario
https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection

Re-allocating resources won’t likely solve any attack issues, but it can enable your machine to be more resilient.

TSU