getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up]
Actually it seems that today datacenter comes up but starting a windows XP vm remains in "waiting for launch" Yesterday I ran an update that impied gluster but I don't think it is relevant in my environment... yum.log contains: May 10 21:24:20 Updated: openstack-java-client-3.0.4-1.fc19.noarch May 10 21:24:20 Updated: audit-libs-2.3.6-1.fc19.x86_64 May 10 21:24:20 Updated: libjpeg-turbo-1.3.1-2.fc19.x86_64 May 10 21:24:20 Installed: rsyslog-mmjsonparse-7.2.6-1.fc19.x86_64 May 10 21:24:21 Updated: glusterfs-libs-3.5.0-3.fc19.x86_64 May 10 21:24:21 Updated: glusterfs-3.5.0-3.fc19.x86_64 May 10 21:24:21 Updated: openstack-java-quantum-model-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-glance-model-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-keystone-model-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-keystone-client-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-glance-client-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-quantum-client-3.0.4-1.fc19.noarch May 10 21:24:22 Updated: glusterfs-fuse-3.5.0-3.fc19.x86_64 May 10 21:24:22 Updated: glusterfs-api-3.5.0-3.fc19.x86_64 May 10 21:24:22 Updated: glusterfs-rdma-3.5.0-3.fc19.x86_64 May 10 21:24:22 Updated: glusterfs-cli-3.5.0-3.fc19.x86_64 May 10 21:24:22 Updated: libjpeg-turbo-devel-1.3.1-2.fc19.x86_64 May 10 21:24:22 Updated: audit-2.3.6-1.fc19.x86_64 May 10 21:24:22 Updated: audit-libs-python-2.3.6-1.fc19.x86_64 May 10 21:24:23 Updated: openstack-java-resteasy-connector-3.0.4-1.fc19.noarch May 10 21:24:23 Updated: 2:microcode_ctl-2.0-7.fc19.x86_64 May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: htop-1.0.3-1.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64 May 10 21:24:28 Updated: kmod-nvidia-304xx-3.13.11-100.fc19.x86_64-304.119-2.fc19.11.x86_64 May 10 21:24:28 Updated: audit-libs-2.3.6-1.fc19.i686 In my engine.log I see error about getting capabilities... 2014-05-11 10:15:26,759 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W orker-67) Failed in GetCapabilitiesVDS method 2014-05-11 10:15:26,759 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W orker-67) Command org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand return value org.ovirt.engine.core.vdsbroker.vdsbroker.VDSInfoReturnForXmlRpc@792fc59f 2014-05-11 10:15:26,760 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W orker-67) HostName = local_host 2014-05-11 10:15:26,760 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W orker-67) Command GetCapabilitiesVDSCommand(HostName = local_host, HostId = aab9571f-da17-4c3c-9e6b-d0224b84c31e, vds=Host[lo cal_host]) execution failed. Exception: VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesV DS, error = Unexpected exception, code = 16 2014-05-11 10:15:26,771 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-67) Failed to refre sh VDS , vds = aab9571f-da17-4c3c-9e6b-d0224b84c31e : local_host, error = org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesVDS, error = Unexpected exception, code = 16, continuing.: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesVDS, error = Unexpected exception, code = 16 at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createDefaultConcreteException(VdsBrokerCommand.java:61) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.createException(BrokerCommandBase.java:199) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:186) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand.executeVdsBrokerCommand(GetCapabilitiesVDSCommand.java:16) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:96) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:56) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:537) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.beforeFirstRefreshTreatment(VdsUpdateRunTimeInfo.java:888) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refreshVdsRunTimeInfo(VdsUpdateRunTimeInfo.java:499) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refresh(VdsUpdateRunTimeInfo.java:337) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:236) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) [:1.7.0_55] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55] at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:60) [scheduler.jar:] at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:] at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz.jar:] [root@tekkaman ovirt-engine]# vdsClient -s 0 getVdsCapabilities Unexpected exception the qemu command line is qemu 8470 1 5 09:58 ? 00:00:57 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name winxp -S -machine pc-1.0,accel=kvm,usb=off -cpu Opteron_G3 -m 2048 -realtime mlock=off -smp 1,maxcpus=160,sockets=160,cores=1,threads=1 -uuid 2981b979-a363-4ab9-a251-439b5774b04d -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=19-8,serial=E0E1001E-8C00-002A-6F9A-90E6BAC9F1E1,uuid=2981b979-a363-4ab9-a251-439b5774b04d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2014-05-11T09:58:34,driftfix=slew -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/mnt/_DATA/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/d4fa7785-8a89-4d13-9082-52556ab0b326,if=none,id=drive-virtio-disk0,format=raw,serial=75c54716-5222-4ad6-91f2-8b312eacc4b4,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=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:a8:01:52,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/2981b979-a363-4ab9-a251-439b5774b04d.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/2981b979-a363-4ab9-a251-439b5774b04d.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 tls-port=5900,addr=0,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 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x4 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 [root@tekkaman ovirt-engine]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X4 630 Processor stepping : 2 microcode : 0x10000db cpu MHz : 2800.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save bogomips : 5600.37 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate ...
This is a multi-part message in MIME format. --------------070107070004020308040103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/11/2014 11:22 AM, Gianluca Cecchi wrote:
Actually it seems that today datacenter comes up but starting a windows XP vm remains in "waiting for launch"
Yesterday I ran an update that impied gluster but I don't think it is relevant in my environment...
yum.log contains: May 10 21:24:20 Updated: openstack-java-client-3.0.4-1.fc19.noarch May 10 21:24:20 Updated: audit-libs-2.3.6-1.fc19.x86_64 May 10 21:24:20 Updated: libjpeg-turbo-1.3.1-2.fc19.x86_64 May 10 21:24:20 Installed: rsyslog-mmjsonparse-7.2.6-1.fc19.x86_64 May 10 21:24:21 Updated: glusterfs-libs-3.5.0-3.fc19.x86_64 May 10 21:24:21 Updated: glusterfs-3.5.0-3.fc19.x86_64 May 10 21:24:21 Updated: openstack-java-quantum-model-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-glance-model-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-keystone-model-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-keystone-client-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-glance-client-3.0.4-1.fc19.noarch May 10 21:24:21 Updated: openstack-java-quantum-client-3.0.4-1.fc19.noarch May 10 21:24:22 Updated: glusterfs-fuse-3.5.0-3.fc19.x86_64 May 10 21:24:22 Updated: glusterfs-api-3.5.0-3.fc19.x86_64 May 10 21:24:22 Updated: glusterfs-rdma-3.5.0-3.fc19.x86_64 May 10 21:24:22 Updated: glusterfs-cli-3.5.0-3.fc19.x86_64 May 10 21:24:22 Updated: libjpeg-turbo-devel-1.3.1-2.fc19.x86_64 May 10 21:24:22 Updated: audit-2.3.6-1.fc19.x86_64 May 10 21:24:22 Updated: audit-libs-python-2.3.6-1.fc19.x86_64 May 10 21:24:23 Updated: openstack-java-resteasy-connector-3.0.4-1.fc19.noarch May 10 21:24:23 Updated: 2:microcode_ctl-2.0-7.fc19.x86_64 May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: htop-1.0.3-1.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64 May 10 21:24:28 Updated: kmod-nvidia-304xx-3.13.11-100.fc19.x86_64-304.119-2.fc19.11.x86_64 May 10 21:24:28 Updated: audit-libs-2.3.6-1.fc19.i686
In my engine.log I see error about getting capabilities...
2014-05-11 10:15:26,759 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W orker-67) Failed in GetCapabilitiesVDS method 2014-05-11 10:15:26,759 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W orker-67) Command org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand return value org.ovirt.engine.core.vdsbroker.vdsbroker.VDSInfoReturnForXmlRpc@792fc59f 2014-05-11 10:15:26,760 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W orker-67) HostName = local_host 2014-05-11 10:15:26,760 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W orker-67) Command GetCapabilitiesVDSCommand(HostName = local_host, HostId = aab9571f-da17-4c3c-9e6b-d0224b84c31e, vds=Host[lo cal_host]) execution failed. Exception: VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesV DS, error = Unexpected exception, code = 16 2014-05-11 10:15:26,771 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-67) Failed to refre sh VDS , vds = aab9571f-da17-4c3c-9e6b-d0224b84c31e : local_host, error = org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesVDS, error = Unexpected exception, code = 16, continuing.: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesVDS, error = Unexpected exception, code = 16 at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createDefaultConcreteException(VdsBrokerCommand.java:61) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.createException(BrokerCommandBase.java:199) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:186) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand.executeVdsBrokerCommand(GetCapabilitiesVDSCommand.java:16) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:96) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:56) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:537) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.beforeFirstRefreshTreatment(VdsUpdateRunTimeInfo.java:888) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refreshVdsRunTimeInfo(VdsUpdateRunTimeInfo.java:499) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refresh(VdsUpdateRunTimeInfo.java:337) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:236) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) [:1.7.0_55] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55] at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:60) [scheduler.jar:] at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:] at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz.jar:]
[root@tekkaman ovirt-engine]# vdsClient -s 0 getVdsCapabilities Unexpected exception
the qemu command line is
qemu 8470 1 5 09:58 ? 00:00:57 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name winxp -S -machine pc-1.0,accel=kvm,usb=off -cpu Opteron_G3 -m 2048 -realtime mlock=off -smp 1,maxcpus=160,sockets=160,cores=1,threads=1 -uuid 2981b979-a363-4ab9-a251-439b5774b04d -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=19-8,serial=E0E1001E-8C00-002A-6F9A-90E6BAC9F1E1,uuid=2981b979-a363-4ab9-a251-439b5774b04d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2014-05-11T09:58:34,driftfix=slew -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/mnt/_DATA/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/d4fa7785-8a89-4d13-9082-52556ab0b326,if=none,id=drive-virtio-disk0,format=raw,serial=75c54716-5222-4ad6-91f2-8b312eacc4b4,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=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:a8:01:52,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/2981b979-a363-4ab9-a251-439b5774b04d.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/2981b979-a363-4ab9-a251-439b5774b04d.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 tls-port=5900,addr=0,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 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x4 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
[root@tekkaman ovirt-engine]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X4 630 Processor stepping : 2 microcode : 0x10000db cpu MHz : 2800.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save bogomips : 5600.37 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate ...
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
The vm will stay in "Waiting.." as the getVdsCaps is failing and the monitoring of Vms will not take place. need to fix this "Unexpected error" first. is it a matter of ssl enabled configuration for host communication? i.e. can you try vdsClient -s 0 getVdsCaps ? --------------070107070004020308040103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 05/11/2014 11:22 AM, Gianluca Cecchi wrote:<br> </div> <blockquote cite="mid:CAG2kNCw83h2=ziFG_-RPPxtU02cHxLCv=+Nq_G2369mBh9JJFA@mail.gmail.com" type="cite"> <div dir="ltr"> <div> <div> <div>Actually it seems that today datacenter comes up but starting a windows XP vm remains in "waiting for launch"<br> <br> </div> Yesterday I ran an update that impied gluster but I don't think it is relevant in my environment...<br> <br> </div> yum.log contains:<br> May 10 21:24:20 Updated: openstack-java-client-3.0.4-1.fc19.noarch<br> May 10 21:24:20 Updated: audit-libs-2.3.6-1.fc19.x86_64<br> May 10 21:24:20 Updated: libjpeg-turbo-1.3.1-2.fc19.x86_64<br> May 10 21:24:20 Installed: rsyslog-mmjsonparse-7.2.6-1.fc19.x86_64<br> May 10 21:24:21 Updated: glusterfs-libs-3.5.0-3.fc19.x86_64<br> May 10 21:24:21 Updated: glusterfs-3.5.0-3.fc19.x86_64<br> May 10 21:24:21 Updated: openstack-java-quantum-model-3.0.4-1.fc19.noarch<br> May 10 21:24:21 Updated: openstack-java-glance-model-3.0.4-1.fc19.noarch<br> May 10 21:24:21 Updated: openstack-java-keystone-model-3.0.4-1.fc19.noarch<br> May 10 21:24:21 Updated: openstack-java-keystone-client-3.0.4-1.fc19.noarch<br> May 10 21:24:21 Updated: openstack-java-glance-client-3.0.4-1.fc19.noarch<br> May 10 21:24:21 Updated: openstack-java-quantum-client-3.0.4-1.fc19.noarch<br> May 10 21:24:22 Updated: glusterfs-fuse-3.5.0-3.fc19.x86_64<br> May 10 21:24:22 Updated: glusterfs-api-3.5.0-3.fc19.x86_64<br> May 10 21:24:22 Updated: glusterfs-rdma-3.5.0-3.fc19.x86_64<br> May 10 21:24:22 Updated: glusterfs-cli-3.5.0-3.fc19.x86_64<br> May 10 21:24:22 Updated: libjpeg-turbo-devel-1.3.1-2.fc19.x86_64<br> May 10 21:24:22 Updated: audit-2.3.6-1.fc19.x86_64<br> May 10 21:24:22 Updated: audit-libs-python-2.3.6-1.fc19.x86_64<br> May 10 21:24:23 Updated: openstack-java-resteasy-connector-3.0.4-1.fc19.noarch<br> May 10 21:24:23 Updated: 2:microcode_ctl-2.0-7.fc19.x86_64<br> May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64<br> May 10 21:24:23 Updated: htop-1.0.3-1.fc19.x86_64<br> May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64<br> May 10 21:24:28 Updated: kmod-nvidia-304xx-3.13.11-100.fc19.x86_64-304.119-2.fc19.11.x86_64<br> May 10 21:24:28 Updated: audit-libs-2.3.6-1.fc19.i686<br> <br> <br> </div> In my engine.log I see error about getting capabilities...<br> <div><br> 2014-05-11 10:15:26,759 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W<br> orker-67) Failed in GetCapabilitiesVDS method<br> 2014-05-11 10:15:26,759 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W<br> orker-67) Command org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand return value <br> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSInfoReturnForXmlRpc@792fc59f<br> 2014-05-11 10:15:26,760 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W<br> orker-67) HostName = local_host<br> 2014-05-11 10:15:26,760 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_W<br> orker-67) Command GetCapabilitiesVDSCommand(HostName = local_host, HostId = aab9571f-da17-4c3c-9e6b-d0224b84c31e, vds=Host[lo<br> cal_host]) execution failed. Exception: VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesV<br> DS, error = Unexpected exception, code = 16<br> 2014-05-11 10:15:26,771 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-67) Failed to refre<br> sh VDS , vds = aab9571f-da17-4c3c-9e6b-d0224b84c31e : local_host, error = org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesVDS, error = Unexpected exception, code = 16, continuing.: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetCapabilitiesVDS, error = Unexpected exception, code = 16<br> at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createDefaultConcreteException(VdsBrokerCommand.java:61) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.createException(BrokerCommandBase.java:199) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:186) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand.executeVdsBrokerCommand(GetCapabilitiesVDSCommand.java:16) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:96) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:56) [vdsbroker.jar:]<br> at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:]<br> at org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:537) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.beforeFirstRefreshTreatment(VdsUpdateRunTimeInfo.java:888) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refreshVdsRunTimeInfo(VdsUpdateRunTimeInfo.java:499) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refresh(VdsUpdateRunTimeInfo.java:337) [vdsbroker.jar:]<br> at org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:236) [vdsbroker.jar:]<br> at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) [:1.7.0_55]<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55]<br> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55]<br> at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:60) [scheduler.jar:]<br> at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]<br> at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz.jar:]<br> <br> [root@tekkaman ovirt-engine]# vdsClient -s 0 getVdsCapabilities<br> Unexpected exception<br> <br> </div> <div>the qemu command line is <br> <br> qemu 8470 1 5 09:58 ? 00:00:57 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name winxp -S -machine pc-1.0,accel=kvm,usb=off -cpu Opteron_G3 -m 2048 -realtime mlock=off -smp 1,maxcpus=160,sockets=160,cores=1,threads=1 -uuid 2981b979-a363-4ab9-a251-439b5774b04d -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=19-8,serial=E0E1001E-8C00-002A-6F9A-90E6BAC9F1E1,uuid=2981b979-a363-4ab9-a251-439b5774b04d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2014-05-11T09:58:34,driftfix=slew -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/mnt/_DATA/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/d4fa7785-8a89-4d13-9082-52556ab0b326,if=none,id=drive-virtio-disk0,format=raw,serial=75c54716-5222-4ad6-91f2-8b312eacc4b4,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=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:a8:01:52,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/2981b979-a363-4ab9-a251-439b5774b04d.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/2981b979-a363-4ab9-a251-439b5774b04d.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 tls-port=5900,addr=0,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 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x4 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8<br> <br> <br> [root@tekkaman ovirt-engine]# cat /proc/cpuinfo<br> processor : 0<br> vendor_id : AuthenticAMD<br> cpu family : 16<br> model : 5<br> model name : AMD Athlon(tm) II X4 630 Processor<br> stepping : 2<br> microcode : 0x10000db<br> cpu MHz : 2800.000<br> cache size : 512 KB<br> physical id : 0<br> siblings : 4<br> core id : 0<br> cpu cores : 4<br> apicid : 0<br> initial apicid : 0<br> fpu : yes<br> fpu_exception : yes<br> cpuid level : 5<br> wp : yes<br> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save<br> bogomips : 5600.37<br> TLB size : 1024 4K pages<br> clflush size : 64<br> cache_alignment : 64<br> address sizes : 48 bits physical, 48 bits virtual<br> power management: ts ttp tm stc 100mhzsteps hwpstate<br> ...<br> <br> <br> </div> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> The vm will stay in "Waiting.." as the getVdsCaps is failing and the monitoring of Vms will not take place.<br> need to fix this "Unexpected error" first. is it a matter of ssl enabled configuration for host communication? i.e. can you try vdsClient -s 0 getVdsCaps ?<br> <br> </body> </html> --------------070107070004020308040103--
On Sun, May 11, 2014 at 4:10 PM, Roy Golan <rgolan@redhat.com> wrote:
The vm will stay in "Waiting.." as the getVdsCaps is failing and the monitoring of Vms will not take place. need to fix this "Unexpected error" first. is it a matter of ssl enabled configuration for host communication? i.e. can you try vdsClient -s 0 getVdsCaps ?
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
I didn't change anything on this server. It is an all-in-one config so both engine and vdsm host are on it. Yesterday and every previous day I was able to start the system and start the VM; I only applied the yum update command yeseterday (with --exclude=sos due to the opened bug) and then I made shutdown of the system. Today after startup I got this problem. [root@tekkaman vdsm]# vdsClient -s 0 getVdsCaps Unexpected exception it seems the error in vdsm.log when I run the command above is of this type: Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com>wrote:
On Sun, May 11, 2014 at 4:10 PM, Roy Golan <rgolan@redhat.com> wrote:
The vm will stay in "Waiting.." as the getVdsCaps is failing and the monitoring of Vms will not take place. need to fix this "Unexpected error" first. is it a matter of ssl enabled configuration for host communication? i.e. can you try vdsClient -s 0 getVdsCaps ?
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
I didn't change anything on this server. It is an all-in-one config so both engine and vdsm host are on it. Yesterday and every previous day I was able to start the system and start the VM; I only applied the yum update command yeseterday (with --exclude=sos due to the opened bug) and then I made shutdown of the system. Today after startup I got this problem.
[root@tekkaman vdsm]# vdsClient -s 0 getVdsCaps Unexpected exception
it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those? vdsm-4.14.6-0.fc19.x86_64 May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64 I can also try to rollback and see...
On Sun, May 11, 2014 at 8:41 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com>wrote:
On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi < gianluca.cecchi@gmail.com> wrote:
On Sun, May 11, 2014 at 4:10 PM, Roy Golan <rgolan@redhat.com> wrote:
The vm will stay in "Waiting.." as the getVdsCaps is failing and the monitoring of Vms will not take place. need to fix this "Unexpected error" first. is it a matter of ssl enabled configuration for host communication? i.e. can you try vdsClient -s 0 getVdsCaps ?
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
I didn't change anything on this server. It is an all-in-one config so both engine and vdsm host are on it. Yesterday and every previous day I was able to start the system and start the VM; I only applied the yum update command yeseterday (with --exclude=sos due to the opened bug) and then I made shutdown of the system. Today after startup I got this problem.
[root@tekkaman vdsm]# vdsClient -s 0 getVdsCaps Unexpected exception
it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users... [root@tekkaman log]# vdsClient -s 0 getVdsCaps Unexpected exception [root@tekkaman log]# yum downgrade python-lxml python-ethtool Loaded plugins: fastestmirror, langpacks, refresh-packagekit, versionlock Dropbox | 951 B 00:00:00 adobe-linux-x86_64 | 951 B 00:00:00 fedora-virt-preview | 2.9 kB 00:00:00 google-chrome | 951 B 00:00:00 livna | 1.3 kB 00:00:00 ovirt-3.3.3 | 2.9 kB 00:00:00 ovirt-stable | 2.9 kB 00:00:00 rpmfusion-free-updates | 3.3 kB 00:00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00:00 updates/19/x86_64/metalink | 28 kB 00:00:00 Loading mirror speeds from cached hostfile * fedora: mirror.netcologne.de * livna: rpm.livna.org * rpmfusion-free: mirror.switch.ch * rpmfusion-free-updates: mirror.switch.ch * rpmfusion-nonfree: mirror.switch.ch * rpmfusion-nonfree-updates: mirror.switch.ch * updates: mirror.netcologne.de Resolving Dependencies --> Running transaction check ---> Package python-ethtool.x86_64 0:0.8-1.fc19 will be a downgrade ---> Package python-ethtool.x86_64 0:0.9-2.fc19 will be erased ---> Package python-lxml.x86_64 0:3.2.1-1.fc19 will be a downgrade ---> Package python-lxml.x86_64 0:3.3.5-1.fc19 will be erased --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================================================================== Package Arch Version Repository Size ====================================================================================================================================================== Downgrading: python-ethtool x86_64 0.8-1.fc19 fedora 32 k python-lxml x86_64 3.2.1-1.fc19 fedora 752 k Transaction Summary ====================================================================================================================================================== Downgrade 2 Packages Total download size: 785 k Is this ok [y/d/N]: Downloading packages: (1/2): python-ethtool-0.8-1.fc19.x86_64.rpm | 32 kB 00:00:00 (2/2): python-lxml-3.2.1-1.fc19.x86_64.rpm | 752 kB 00:00:02 ------------------------------------------------------------------------------------------------------------------------------------------------------ Total 317 kB/s | 785 kB 00:00:02 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : python-lxml-3.2.1-1.fc19.x86_64 1/4 Installing : python-ethtool-0.8-1.fc19.x86_64 2/4 Cleanup : python-lxml-3.3.5-1.fc19.x86_64 3/4 Cleanup : python-ethtool-0.9-2.fc19.x86_64 4/4 Verifying : python-ethtool-0.8-1.fc19.x86_64 1/4 Verifying : python-lxml-3.2.1-1.fc19.x86_64 2/4 Verifying : python-ethtool-0.9-2.fc19.x86_64 3/4 Verifying : python-lxml-3.3.5-1.fc19.x86_64 4/4 Removed: python-ethtool.x86_64 0:0.9-2.fc19 python-lxml.x86_64 0:3.3.5-1.fc19 Installed: python-ethtool.x86_64 0:0.8-1.fc19 python-lxml.x86_64 0:3.2.1-1.fc19 Complete! [root@tekkaman log]# vdsClient -s 0 getVdsCaps Unexpected exception [root@tekkaman log]# systemctl restart vdsmd [root@tekkaman log]# systemctl status vdsmd vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: active (running) since Sun 2014-05-11 23:44:52 CEST; 16s ago Process: 13935 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh --post-stop (code=exited, status=0/SUCCESS) Process: 13939 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=0/SUCCESS) Main PID: 14003 (vdsm) CGroup: name=systemd:/system/vdsmd.service ├─14003 /usr/bin/python /usr/share/vdsm/vdsm ├─14074 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 32 30 ├─14081 rpc.statd --no-notify ├─14103 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 34 32 ├─14105 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 41 40 ├─14106 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 48 46 ├─14107 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 54 48 ├─14108 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 41 40 ├─14121 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 50 41 ├─14123 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 66 65 ├─14125 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 71 50 ├─14129 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 75 71 ├─14131 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 81 75 ├─14135 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 92 89 ├─14137 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 75 65 └─14138 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 89 75 May 11 23:44:53 tekkaman.localdomain.local vdsm[14003]: vdsm vds WARNING Unable to load the json rpc server module. Please make sure it is installed. May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 2 May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 parse_server_challenge() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 ask_user_info() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 2 May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 ask_user_info() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 make_client_response() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 3 May 11 23:44:57 tekkaman.localdomain.local rpc.statd[14081]: Version 1.2.7 starting May 11 23:44:57 tekkaman.localdomain.local rpc.statd[14081]: Flags: TI-RPC [root@tekkaman log]# vdsClient -s 0 getVdsCaps HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:e6aa759a959'}]} ISCSIInitiatorName = 'iqn.1994-05.com.redhat:e6aa759a959' bondings = {'bond0': {'addr': '', 'cfg': {}, 'hwaddr': '9a:0f:68:19:0f:87', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}} bridges = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'gateway': '', 'ipv6addrs': [], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '', 'ports': [], 'stp': 'off'}, 'ovirtmgmt': {'addr': '192.168.1.101', 'cfg': {'BOOTPROTO': 'none', 'DELAY': '0', 'DEVICE': 'ovirtmgmt', 'GATEWAY': '192.168.1.1', 'IPADDR': '192.168.1.101', 'NETMASK': '255.255.255.0', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge'}, 'gateway': '192.168.1.1', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['p10p1'], 'stp': 'off'}} clusterLevels = ['3.0', '3.1', '3.2', '3.3', '3.4'] cpuCores = '4' cpuFlags = 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,3dnowext,3dnow,constant_tsc,rep_good,nopl,nonstop_tsc,extd_apicid,pni,monitor,cx16,popcnt,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,ibs,skinit,wdt,hw_pstate,npt,lbrv,svm_lock,nrip_save,model_athlon,model_Opteron_G3,model_Opteron_G1,model_phenom,model_Opteron_G2' cpuModel = 'AMD Athlon(tm) II X4 630 Processor' cpuSockets = '1' cpuSpeed = '2800.000' cpuThreads = '4' emulatedMachines = ['pc', 'pc-q35-1.4', 'pc-q35-1.5', 'q35', 'isapc', 'pc-0.10', 'pc-0.11', 'pc-0.12', 'pc-0.13', 'pc-0.14', 'pc-0.15', 'pc-1.0', 'pc-1.1', 'pc-1.2', 'pc-1.3', 'pc-i440fx-1.4', 'pc-i440fx-1.5', 'none'] guestOverhead = '65' hooks = {} kvmEnabled = 'true' lastClient = '192.168.1.101' lastClientIface = 'ovirtmgmt' management_ip = '0.0.0.0' memSize = '16048' netConfigDirty = 'False' networks = {'ovirtmgmt': {'addr': '192.168.1.101', 'bridged': True, 'cfg': {'BOOTPROTO': 'none', 'DELAY': '0', 'DEVICE': 'ovirtmgmt', 'GATEWAY': '192.168.1.1', 'IPADDR': '192.168.1.101', 'NETMASK': '255.255.255.0', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge'}, 'gateway': '192.168.1.1', 'iface': 'ovirtmgmt', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['p10p1'], 'stp': 'off'}} nics = {'p10p1': {'addr': '', 'cfg': {'BRIDGE': 'ovirtmgmt', 'DEVICE': 'p10p1', 'HWADDR': '90:e6:ba:c9:f1:e1', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes'}, 'hwaddr': '90:e6:ba:c9:f1:e1', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'mtu': '1500', 'netmask': '', 'speed': 100}} operatingSystem = {'name': 'Fedora', 'release': '8', 'version': '19'} packages2 = {'kernel': {'buildtime': 1398276657.0, 'release': '100.fc19.x86_64', 'version': '3.13.11'}, 'libvirt': {'buildtime': 1387094943, 'release': '1.fc19', 'version': '1.1.3.2'}, 'mom': {'buildtime': 1391183561, 'release': '1.fc19', 'version': '0.4.0'}, 'qemu-img': {'buildtime': 1384762225, 'release': '2.fc19', 'version': '1.6.1'}, 'qemu-kvm': {'buildtime': 1384762225, 'release': '2.fc19', 'version': '1.6.1'}, 'spice-server': {'buildtime': 1383130020, 'release': '3.fc19', 'version': '0.12.4'}, 'vdsm': {'buildtime': 1395804204, 'release': '0.fc19', 'version': '4.14.6'}} reservedMem = '321' rngSources = ['random'] software_revision = '0' software_version = '4.14' supportedENGINEs = ['3.0', '3.1', '3.2', '3.3', '3.4'] supportedProtocols = ['2.2', '2.3'] uuid = 'E0E1001E-8C00-002A-6F9A-90E6BAC9F1E1' version_name = 'Snow Man' vlans = {} vmTypes = ['kvm'] And I'm now able to start and connect to my VM again. HIH, Gianluca
Hi, ----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Roy Golan" <rgolan@redhat.com> Cc: "users" <users@ovirt.org> Sent: Sunday, May 11, 2014 11:49:06 PM Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] [...] it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users...
Unfortunately, you are been hit by https://bugzilla.redhat.com/show_bug.cgi?id=1078312 It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1 Bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
Il 12/mag/2014 08:33 "Francesco Romani" <fromani@redhat.com> ha scritto:
Unfortunately, you are been hit by
https://bugzilla.redhat.com/show_bug.cgi?id=1078312
It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1
Bests,
So you are telling I can try to update my AIO to to 3.4.1 and as it will provide (after updating vdsm too) vdsm-4.14.8.1-0.fc19.x86_64.rpm the problem should go away? Gianluca
Hi, ----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Francesco Romani" <fromani@redhat.com> Cc: "users" <users@ovirt.org>, "Roy Golan" <rgolan@redhat.com> Sent: Monday, May 12, 2014 9:56:33 AM Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up]
Il 12/mag/2014 08:33 "Francesco Romani" <fromani@redhat.com> ha scritto:
Unfortunately, you are been hit by
https://bugzilla.redhat.com/show_bug.cgi?id=1078312
It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1
Bests,
So you are telling I can try to update my AIO to to 3.4.1 and as it will provide (after updating vdsm too)
vdsm-4.14.8.1-0.fc19.x86_64.rpm
the problem should go away?
Yes, it should. Just replacing VDSM should be enough, however. Bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
Hi,
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Roy Golan" <rgolan@redhat.com> Cc: "users" <users@ovirt.org> Sent: Sunday, May 11, 2014 11:49:06 PM Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] [...] it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users...
Unfortunately, you are been hit by https://bugzilla.redhat.com/show_bug.cgi?id=1078312
It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1
Too bad that we did not manage to add a "Conflicts: vdsm <= 4.18.6" to that release of python-ethtool-0.9-2.fc19.x86_64. But now that it is out, there is not much that one can do but to upgrade to a new Vdsm or roll back python-ethtool. The propblem was due to Vdsm-proper using libnl1 while that version of python-ethtool starting to use linbnl3 and solved by http://gerrit.ovirt.org/26514. Backporting this to the now-unsupported ovirt-3.3 is not really viable, I a m afraid. Dan.
Hi, I'd like to talk again about the "support" for the available ovirt versions. I have recently read some times that 3.3. is not supported anymore, e.g.: Am 12.05.2014 12:28, schrieb Dan Kenigsberg:
Backporting this to the now-unsupported ovirt-3.3 is not really viable, I a m afraid.
By "support" I guess you mean the following: There will be no updates (e.g. 3.3.6.) anymore Is this correct? Is there any way to determine how long a given x.y.z. release will get .z updates ? It would be good if there is some consistency in that, so users can better plan their own release management of new versions. e.g. (made up numbers by me): there will always be 3 z releases if a regression is found there will always be a .z release which fixes it. how many y. releases will get .z patches at the same time? I know you can't expect a totally planned support, if you need it, you could buy some well known downstream product. But at the moment it seems very random (at least to me) how long a given release is out and gets patches and when it stops getting patches. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
On May 12, 2014, at 13:26 , Sven Kieske <S.Kieske@mittwald.de> wrote:
Hi,
I'd like to talk again about the "support" for the available ovirt versions.
I have recently read some times that 3.3. is not supported anymore, e.g.:
Am 12.05.2014 12:28, schrieb Dan Kenigsberg:
Backporting this to the now-unsupported ovirt-3.3 is not really viable, I a m afraid.
By "support" I guess you mean the following:
There will be no updates (e.g. 3.3.6.) anymore
Is this correct?
Is there any way to determine how long a given x.y.z. release will get .z updates ?
It would be good if there is some consistency in that, so users can better plan their own release management of new versions.
e.g. (made up numbers by me):
there will always be 3 z releases if a regression is found there will always be a .z release which fixes it.
how many y. releases will get .z patches at the same time?
I know you can't expect a totally planned support, if you need it, you could buy some well known downstream product.
But at the moment it seems very random (at least to me) how long a given release is out and gets patches and when it stops getting patches.
It typically stops after the next .y release is out. So after 3.4 is GA the need for next 3.3.z is less important. I'd say after 3.4 is GA you can expect at most one or two more 3.3.z for urgent/security fixes, and by the time of 3.4.1 or 3.4.2 the updates on 3.3 would stop I think we don't deviate from this that much. The actual number of .z depends on the length of the development of next release as well as number of issues, so that varies. Thanks, michal
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 12.05.2014 14:02, Michal Skrivanek wrote: Hi Michal,
It typically stops after the next .y release is out. So after 3.4 is GA the need for next 3.3.z is less important. I'd say after 3.4 is GA you can expect at most one or two more 3.3.z for urgent/security fixes, and by the time of 3.4.1 or 3.4.2 the updates on 3.3 would stop
I think we don't deviate from this that much. The actual number of .z depends on the length of the development of next release as well as number of issues, so that varies.
Another question in this context: How long do you plan to support operating systems like RHEL6/CentOS6 with new oVirt releases/updates? Is it planned to support RHEL6 with new oVirt releases after the general availability of RHEL7? Best regards, Morten
On May 12, 2014, at 14:42 , Morten Stevens <mstevens@fedoraproject.org> wrote:
On 12.05.2014 14:02, Michal Skrivanek wrote:
Hi Michal,
It typically stops after the next .y release is out. So after 3.4 is GA the need for next 3.3.z is less important. I'd say after 3.4 is GA you can expect at most one or two more 3.3.z for urgent/security fixes, and by the time of 3.4.1 or 3.4.2 the updates on 3.3 would stop
I think we don't deviate from this that much. The actual number of .z depends on the length of the development of next release as well as number of issues, so that varies.
Another question in this context: How long do you plan to support operating systems like RHEL6/CentOS6 with new oVirt releases/updates? Is it planned to support RHEL6 with new oVirt releases after the general availability of RHEL7?
I expect EL6 compatibility will be there for quite some time, though I don't know, someone from integration better answer, each release has some overhead to maintain. Thanks, michal
Best regards,
Morten
On 12/05/14 12:28, Dan Kenigsberg wrote:
On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
Hi,
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Roy Golan" <rgolan@redhat.com> Cc: "users" <users@ovirt.org> Sent: Sunday, May 11, 2014 11:49:06 PM Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] [...] it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users...
Unfortunately, you are been hit by https://bugzilla.redhat.com/show_bug.cgi?id=1078312
It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1
Too bad that we did not manage to add a "Conflicts: vdsm <= 4.18.6" to that release of python-ethtool-0.9-2.fc19.x86_64. But now that it is out, there is not much that one can do but to upgrade to a new Vdsm or roll back python-ethtool.
The propblem was due to Vdsm-proper using libnl1 while that version of python-ethtool starting to use linbnl3 and solved by http://gerrit.ovirt.org/26514. Backporting this to the now-unsupported ovirt-3.3 is not really viable, I a m afraid.
Sorry about that! I honestly forgot about this when I had a discussion with Antoni Segura Puimedon last week. And we discovered some other ugly issues too, where we need a dependency on a not yet released libnl3 version to fully fix some libnl connection conflicts with vdsm. I tried to remove this update in the last minute. But it obviously slipped through anyway :( Not sure if I'm able to revert to an older version now in Koji. -- kind regards, David Sommerseth
On Mon, May 12, 2014 at 05:34:34PM +0200, David Sommerseth wrote:
On 12/05/14 12:28, Dan Kenigsberg wrote:
On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
Hi,
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Roy Golan" <rgolan@redhat.com> Cc: "users" <users@ovirt.org> Sent: Sunday, May 11, 2014 11:49:06 PM Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] [...] it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users...
Unfortunately, you are been hit by https://bugzilla.redhat.com/show_bug.cgi?id=1078312
It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1
Too bad that we did not manage to add a "Conflicts: vdsm <= 4.18.6" to that release of python-ethtool-0.9-2.fc19.x86_64. But now that it is out, there is not much that one can do but to upgrade to a new Vdsm or roll back python-ethtool.
The propblem was due to Vdsm-proper using libnl1 while that version of python-ethtool starting to use linbnl3 and solved by http://gerrit.ovirt.org/26514. Backporting this to the now-unsupported ovirt-3.3 is not really viable, I a m afraid.
Sorry about that! I honestly forgot about this when I had a discussion with Antoni Segura Puimedon last week. And we discovered some other ugly issues too, where we need a dependency on a not yet released libnl3 version to fully fix some libnl connection conflicts with vdsm.
Could you (or Toni) add more information regrading the last sentence? Is there a known issue with ovirt-3.4.1's vdsm?
I tried to remove this update in the last minute. But it obviously slipped through anyway :( Not sure if I'm able to revert to an older version now in Koji.
On 12/05/14 19:27, Dan Kenigsberg wrote:
On Mon, May 12, 2014 at 05:34:34PM +0200, David Sommerseth wrote:
On 12/05/14 12:28, Dan Kenigsberg wrote:
On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
Hi,
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Roy Golan" <rgolan@redhat.com> Cc: "users" <users@ovirt.org> Sent: Sunday, May 11, 2014 11:49:06 PM Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] [...] it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users...
Unfortunately, you are been hit by https://bugzilla.redhat.com/show_bug.cgi?id=1078312
It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1
Too bad that we did not manage to add a "Conflicts: vdsm <= 4.18.6" to that release of python-ethtool-0.9-2.fc19.x86_64. But now that it is out, there is not much that one can do but to upgrade to a new Vdsm or roll back python-ethtool.
The propblem was due to Vdsm-proper using libnl1 while that version of python-ethtool starting to use linbnl3 and solved by http://gerrit.ovirt.org/26514. Backporting this to the now-unsupported ovirt-3.3 is not really viable, I a m afraid.
Sorry about that! I honestly forgot about this when I had a discussion with Antoni Segura Puimedon last week. And we discovered some other ugly issues too, where we need a dependency on a not yet released libnl3 version to fully fix some libnl connection conflicts with vdsm.
Could you (or Toni) add more information regrading the last sentence? Is there a known issue with ovirt-3.4.1's vdsm?
AFAIU, it's the same old issue, which caused some regression from the tests we've done earlier, due to vdsm using libnl-1.x while python-ethtool uses libnl3. When vdsm in addition uses py-ethtool, the socket py-ethtool module gets closed by itself, which it uses to query the kernel's netlink interface. The result is that py-ethtool gets in a useless state is not able to re-establish a new socket and cannot query the system for any useful information. Thomas Haller (libnl developer) have provided patches to libnl3 which fixes the connection handling - which should help avoiding this issue. I missed the detail that the libnl3 fixes hadn't been pushed out in a release. So when py-ethool got updated, it broke vdsm due to this libnl1/libnl3 issue. With an updated libnl3 + updated py-ethtool, I believe things should be better also for the older vdsm versions. The change in py-ethtool is primarily improving error handling if libnl3 isn't able to establish a netlink socket to the kernel. -- kind regards, David Sommerseth
On Mon, May 12, 2014 at 12:28 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
Hi,
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Roy Golan" <rgolan@redhat.com> Cc: "users" <users@ovirt.org> Sent: Sunday, May 11, 2014 11:49:06 PM Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] [...] it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users...
Unfortunately, you are been hit by https://bugzilla.redhat.com/show_bug.cgi?id=1078312
It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1
Too bad that we did not manage to add a "Conflicts: vdsm <= 4.18.6" to that release of python-ethtool-0.9-2.fc19.x86_64. But now that it is out, there is not much that one can do but to upgrade to a new Vdsm or roll back python-ethtool.
The propblem was due to Vdsm-proper using libnl1 while that version of python-ethtool starting to use linbnl3 and solved by http://gerrit.ovirt.org/26514. Backporting this to the now-unsupported ovirt-3.3 is not really viable, I a m afraid.
Dan. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
So, this was I was able to verify on my All-In-One environment based on Fedora 19. 1) yum update python-lxml verified that the only problem was related to python-ethtool and thisn work ok with python-lxml-3.3.5-1.fc19.x86_64 2) update vdsmd systemctl stop vdsmd yum localinstall http://resources.ovirt.org/pub/yum-repo/ovirt-release34.rpm yum remove ovirt-release (BTW: nice that 3.4.1 brings in ovirt-3.4-dependencies.repo file and removes (aka renames in .rpmsave) the explicit fedora-virt-preview.repo) yum update vdsm Now vdsm is at vdsm-4.14.8.1-0.fc19.x86_64 systemctl start vdsmd --> ok 3) update python-ethtool and verify new version of vdsm systemctl stop vdsmd yum update python-ethtool Now it is at version python-ethtool-0.9-2.fc19.x86_64 systemctl start vdsmd --> ok vdsClient -s 0 getVdsCaps doesn't return the unexpected exception any more 4) problem with ovirt-engine that apparently doesnt' start after the vdsm update also tried to reboot in this AIO system with only vdsmd updated I got - in engine.log 2014-05-13 00:02:30,480 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-6) Could not parse option AutoRecoveryAllowedTypes value. 2014-05-13 00:02:30,482 INFO [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-6) Running ovirt-engine 3.4.0-1.fc19 - in server.log 2014-05-13 00:02:28,358 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named Scheduler in deployment unit subdeployment "scheduler.jar" of deployment "engine.ear" are as follows: java:global/engine/scheduler/Scheduler!org.ovirt.engine.core.utils.timer.SchedulerUtil java:app/scheduler/Scheduler!org.ovirt.engine.core.utils.timer.SchedulerUtil java:module/Scheduler!org.ovirt.engine.core.utils.timer.SchedulerUtil java:global/engine/scheduler/Scheduler java:app/scheduler/Scheduler java:module/Scheduler 2014-05-13 00:02:29,011 ERROR [org.apache.catalina.startup.ContextConfig] (MSC service thread 1-2) Cannot configure an authenticator for method NONE 2014-05-13 00:02:29,011 INFO [org.jboss.web] (MSC service thread 1-8) JBAS018210: Registering web context: /ovirt-engine/services 2014-05-13 00:02:29,014 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018210: Registering web context: 2014-05-13 00:02:29,012 ERROR [org.jboss.web] (MSC service thread 1-2) JBAS018206: Webapp [/ovirt-engine/api] is unavailable due to startup errors 2014-05-13 00:02:29,015 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-2) Context [/ovirt-engine/api] startup failed due to previous errors 2014-05-13 00:02:29,048 INFO [org.jboss.web] (MSC service thread 1-6) JBAS018210: Registering web context: /api 2014-05-13 00:02:29,120 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.web.deployment.default-host./ovirt-eng ine/api: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./ovirt-engine/api: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:95) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] .... 2014-05-13 00:05:54,546 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMGetAllTasksInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [4356795b] -- executeIrsBrokerCommand: Attempting on storage pool 65c9777e-23f1-4f04-8cea-e7c8871dc88b 2014-05-13 00:05:54,558 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [4356795b] START, HSMGetAllTasksInfoVDSCommand(HostName = local_host, HostId = aab9571f-da17-4c3c-9e6b-d0224b84c31e), log id: 3cd3caa0 2014-05-13 00:05:54,565 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [4356795b] FINISH, HSMGetAllTasksInfoVDSCommand, return: [], log id: 3cd3caa0 2014-05-13 00:05:54,566 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMGetAllTasksInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [4356795b] FINISH, SPMGetAllTasksInfoVDSCommand, return: [], log id: 6e4451df 2014-05-13 00:05:54,566 INFO [org.ovirt.engine.core.bll.AsyncTaskManager] (org.ovirt.thread.pool-6-thread-11) [4356795b] Discovered no tasks on Storage Pool local_datacenter ... 2014-05-13 00:05:59,801 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment ovirt-engine-reports.war in 757ms complete server.log for this part here: https://drive.google.com/file/d/0BwoPbcrMv8mvYllLTUg1eTlhZnc/edit?usp=sharin... complete engine.log for this part here: https://drive.google.com/file/d/0BwoPbcrMv8mvWmVuMXF0ZjEzRk0/edit?usp=sharin... 5) decided to update to 3.4.1 overall also for the engine part All went ok and smooth, also the dwh and reports part. And I'm able to start and use a Windows Xp vm. Gianluca
On Tue, May 13, 2014 at 12:59:40AM +0200, Gianluca Cecchi wrote:
On Mon, May 12, 2014 at 12:28 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
Hi,
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Roy Golan" <rgolan@redhat.com> Cc: "users" <users@ovirt.org> Sent: Sunday, May 11, 2014 11:49:06 PM Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] [...] it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users...
Unfortunately, you are been hit by https://bugzilla.redhat.com/show_bug.cgi?id=1078312
It is fixed on gerrit, but you'll need VDSM >= 4.14.8.1
Too bad that we did not manage to add a "Conflicts: vdsm <= 4.18.6" to that release of python-ethtool-0.9-2.fc19.x86_64. But now that it is out, there is not much that one can do but to upgrade to a new Vdsm or roll back python-ethtool.
The propblem was due to Vdsm-proper using libnl1 while that version of python-ethtool starting to use linbnl3 and solved by http://gerrit.ovirt.org/26514. Backporting this to the now-unsupported ovirt-3.3 is not really viable, I a m afraid.
Dan. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
So, this was I was able to verify on my All-In-One environment based on Fedora 19.
1) yum update python-lxml verified that the only problem was related to python-ethtool and thisn work ok with python-lxml-3.3.5-1.fc19.x86_64
2) update vdsmd
systemctl stop vdsmd yum localinstall http://resources.ovirt.org/pub/yum-repo/ovirt-release34.rpm yum remove ovirt-release (BTW: nice that 3.4.1 brings in ovirt-3.4-dependencies.repo file and removes (aka renames in .rpmsave) the explicit fedora-virt-preview.repo) yum update vdsm Now vdsm is at vdsm-4.14.8.1-0.fc19.x86_64
systemctl start vdsmd --> ok
3) update python-ethtool and verify new version of vdsm systemctl stop vdsmd yum update python-ethtool Now it is at version python-ethtool-0.9-2.fc19.x86_64 systemctl start vdsmd --> ok
vdsClient -s 0 getVdsCaps doesn't return the unexpected exception any more
4) problem with ovirt-engine that apparently doesnt' start after the vdsm update also tried to reboot in this AIO system with only vdsmd updated I got
- in engine.log 2014-05-13 00:02:30,480 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-6) Could not parse option AutoRecoveryAllowedTypes value. 2014-05-13 00:02:30,482 INFO [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-6) Running ovirt-engine 3.4.0-1.fc19
- in server.log 2014-05-13 00:02:28,358 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named Scheduler in deployment unit subdeployment "scheduler.jar" of deployment "engine.ear" are as follows:
java:global/engine/scheduler/Scheduler!org.ovirt.engine.core.utils.timer.SchedulerUtil
java:app/scheduler/Scheduler!org.ovirt.engine.core.utils.timer.SchedulerUtil
java:module/Scheduler!org.ovirt.engine.core.utils.timer.SchedulerUtil java:global/engine/scheduler/Scheduler java:app/scheduler/Scheduler java:module/Scheduler
2014-05-13 00:02:29,011 ERROR [org.apache.catalina.startup.ContextConfig] (MSC service thread 1-2) Cannot configure an authenticator for method NONE 2014-05-13 00:02:29,011 INFO [org.jboss.web] (MSC service thread 1-8) JBAS018210: Registering web context: /ovirt-engine/services 2014-05-13 00:02:29,014 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018210: Registering web context: 2014-05-13 00:02:29,012 ERROR [org.jboss.web] (MSC service thread 1-2) JBAS018206: Webapp [/ovirt-engine/api] is unavailable due to startup errors 2014-05-13 00:02:29,015 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-2) Context [/ovirt-engine/api] startup failed due to previous errors 2014-05-13 00:02:29,048 INFO [org.jboss.web] (MSC service thread 1-6) JBAS018210: Registering web context: /api 2014-05-13 00:02:29,120 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.web.deployment.default-host./ovirt-eng ine/api: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./ovirt-engine/api: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:95) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] .... 2014-05-13 00:05:54,546 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMGetAllTasksInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [4356795b] -- executeIrsBrokerCommand: Attempting on storage pool 65c9777e-23f1-4f04-8cea-e7c8871dc88b 2014-05-13 00:05:54,558 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [4356795b] START, HSMGetAllTasksInfoVDSCommand(HostName = local_host, HostId = aab9571f-da17-4c3c-9e6b-d0224b84c31e), log id: 3cd3caa0 2014-05-13 00:05:54,565 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [4356795b] FINISH, HSMGetAllTasksInfoVDSCommand, return: [], log id: 3cd3caa0 2014-05-13 00:05:54,566 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMGetAllTasksInfoVDSCommand] (org.ovirt.thread.pool-6-thread-11) [4356795b] FINISH, SPMGetAllTasksInfoVDSCommand, return: [], log id: 6e4451df 2014-05-13 00:05:54,566 INFO [org.ovirt.engine.core.bll.AsyncTaskManager] (org.ovirt.thread.pool-6-thread-11) [4356795b] Discovered no tasks on Storage Pool local_datacenter ... 2014-05-13 00:05:59,801 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment ovirt-engine-reports.war in 757ms
complete server.log for this part here: https://drive.google.com/file/d/0BwoPbcrMv8mvYllLTUg1eTlhZnc/edit?usp=sharin...
complete engine.log for this part here: https://drive.google.com/file/d/0BwoPbcrMv8mvWmVuMXF0ZjEzRk0/edit?usp=sharin...
5) decided to update to 3.4.1 overall also for the engine part
All went ok and smooth, also the dwh and reports part. And I'm able to start and use a Windows Xp vm.
That's good, but let's not forget point 4. Engine-3.4.0 must work properly with an updated vdsm. Can someone from Engine (Yair?) look at these logs?
participants (8)
-
Dan Kenigsberg -
David Sommerseth -
Francesco Romani -
Gianluca Cecchi -
Michal Skrivanek -
Morten Stevens -
Roy Golan -
Sven Kieske