[Users] Reboot causes poweroff of VM 3.4 Beta

Mon Jan 27 13:55:09 UTC 2014

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 [1]
 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 [1]
 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 

Links:
------
[1] http://lists.ovirt.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140127/02a6b161/attachment-0001.html>