On Jan 27, 2014, at 14:55 , Jonathan Archer <j...@rosslug.org.uk> wrote:
> On 27/01/2014 13:15, Michal Skrivanek wrote: > >> On Jan 27, 2014, at 12:21 , Jonathan Archer <j...@rosslug.org.uk> wrote: >>> On 27/01/2014 11:03, Michal Skrivanek wrote: >>>> On Jan 27, 2014, at 11:59 , Jonathan Archer <j...@rosslug.org.uk> wrote: >>>>> On 27/01/2014 10:56, Michal Skrivanek wrote: >>>>>> On Jan 27, 2014, at 11:46 , Jonathan Archer <j...@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 < j...@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@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@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? _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
