[Users] Reboot causes poweroff of VM 3.4 Beta

[Michal Skrivanek]

On Jan 27, 2014, at 14:55 , Jonathan Archer <jon at rosslug.org.uk> wrote:

> On 27/01/2014 13:15, Michal Skrivanek wrote:
> 
>> On Jan 27, 2014, at 12:21 , Jonathan Archer <jon at rosslug.org.uk> wrote:
>>> On 27/01/2014 11:03, Michal Skrivanek wrote:
>>>> On Jan 27, 2014, at 11:59 , Jonathan Archer <jon at rosslug.org.uk> wrote:
>>>>> On 27/01/2014 10:56, Michal Skrivanek wrote:
>>>>>> On Jan 27, 2014, at 11:46 , Jonathan Archer <jon at rosslug.org.uk> wrote:
>>>>>>> On 25/01/2014 20:02, Roy Golan wrote:
>>>>>>>> Please attach engine.log and vdsm.log On Jan 25, 2014 5:59 PM, Jon Archer < jon at rosslug.org.uk> wrote:
>>>>>>>>> Hi, Seem to be suffering an issue in 3.4 where if a vm Hi,
>>>>>>>> Seem to be suffering an issue in 3.4 where if a vm is rebooted it actually shuts down, this occurs for all guests regardless of OS installed within. Anyone seen this? Jon _______________________________________________ Users mailing list Users at ovirt.org http://lists.ovirt.org/mailman/listinfo/users
>>>>>>> Attached is a sample of the engine.log and vdsm.log during a "reboot" the VM as previously stated shutdown rather than reboot,. There wasn't anything in the server.log around the time, the previous entry was at least 30 mins before.
>>>>>> Hi, your log doesn't contain the relevant part, there's no command logged, other than "Message: VM wcsmail01 is down. Exit message: User shut down" which means the guest was shut down from inside of the OS how did you trigger the reboot/shutdown? Thanks, michal
>>>>>>> Thanks <engine.out.txt><vdsm.out.txt>_______________________________________________ Users mailing list Users at ovirt.org http://lists.ovirt.org/mailman/listinfo/users
>>>>> The reboot was triggered using the reboot command at the console.
>>>> ok, makes sense there's nothing in the log
>>>>> I also have a windows 7 guest, which shuts down when the reboot option is selected.
>>>> what doesn't make sense is the behavior:) It should simply reboot, there's nothing oVirt is doing in this case…could it be your OS is configured(or has decided) to shutdown instead?
>>>>> Jon
>>> Hi, I'd be pointed towards the guest OS if it wasn't for 2 things: 1) this happens to all guests of both windows and Linux flavours 2) the guests are just plain vanilla installs with nothing special.
>> that is weird. Any special/non-default setting?
>> do you have libvirt/qemu logs? VDSM doesn't say much other than a clean user-initiated shutdown happened.
>> is ACPI enabled in the guest (unless you manually changed config it always is)
>> any logs from the guest?
>> 
>> Thanks,
>> michal
>> 
>>> Jon
> Yes it does seem to be weird, nothing special about my setup. Simple gluster setup converted from all-in-one.
> 
> As I mentioned the guests are vanilla with regard to configs.
> 
> Just had a look in the libvirt and qemu logs, nothin in the libvirt, and nothing exciting in the qemu log
> 
> 2014-01-27 13:37:16.842+0000: starting up
> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name wcssrv01 -S -M rhel6.5.0 -cpu Conroe,+vmx -enable-kvm -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 350e285d-8c3a-494b-b484-27784caae976 -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=6-5.el6.centos.11.2,serial=439CF517-D52F-11DF-BBDA-C0970C0278AC,uuid=350e285d-8c3a-494b-b484-27784caae976 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/wcssrv01.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2014-01-27T13:37:16,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/rhev/data-center/mnt/cauldron.arclab:_ISO__DOMAIN/abf4ff41-eb0a-4580-9ad0-bae53d56c6b0/images/11111111-1111-1111-1111-111111111111/CentOS-6.5-x86_64-minimal.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -drive file=/rhev/data-center/mnt/glusterSD/cauldron.arclab:_data/c074a6e3-87be-445e-890f-601c215ba320/images/24cf5dba-6b4a-430c-9a15-cfdebe0c1f09/9e47f51f-5bc5-47a0-8f98-c8a14626c393,if=none,id=drive-virtio-disk0,format=raw,serial=24cf5dba-6b4a-430c-9a15-cfdebe0c1f09,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=32 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:2d:98:0e,bus=pci.0,addr=0x3,bootindex=3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/350e285d-8c3a-494b-b484-27784caae976.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/350e285d-8c3a-494b-b484-27784caae976.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel2,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0 -spice port=5902,tls-port=5903,addr=192.168.1.107,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on -k en-us -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
> main_channel_link: add main channel client
> main_channel_handle_parsed: net test: latency 35.175000 ms, bitrate 6509005 bps (6.207471 Mbps) LOW BANDWIDTH
> inputs_connect: inputs channel client create
> red_dispatcher_set_cursor_peer:
> qemu: terminating on signal 15 from pid 2289
> 2014-01-27 13:51:53.582+0000: shutting down
> 
> Jon

the only other thing coming to my mind is that guest OS doesn't "see" the right ACPI support.
On reboot the QEMU process shouldn't die.

did you try different hw (e.g. without virtio-scsi), OS type?