getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up]
11:22 a.m.
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
...
5:10 p.m.
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(a)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://...
</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--
9:18 p.m.
On Sun, May 11, 2014 at 4:10 PM, Roy Golan <rgolan(a)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(a)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
9:41 p.m.
On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com>wrote:
On Sun, May 11, 2014 at 4:10 PM, Roy Golan <rgolan(a)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(a)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...
12:49 a.m.
On Sun, May 11, 2014 at 8:41 PM, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com>wrote:
On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi <
gianluca.cecchi(a)gmail.com> wrote:
> On Sun, May 11, 2014 at 4:10 PM, Roy Golan <rgolan(a)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(a)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
9:33 a.m.
Hi,
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com>
To: "Roy Golan" <rgolan(a)redhat.com>
Cc: "users" <users(a)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
10:56 a.m.
Il 12/mag/2014 08:33 "Francesco Romani" <fromani(a)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
11:04 a.m.
Hi,
----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com>
To: "Francesco Romani" <fromani(a)redhat.com>
Cc: "users" <users(a)ovirt.org>, "Roy Golan"
<rgolan(a)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(a)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
1:28 p.m.
On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
Hi,
----- Original Message -----
> From: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com>
> To: "Roy Golan" <rgolan(a)redhat.com>
> Cc: "users" <users(a)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.
2:26 p.m.
New subject: "supported" versions of ovirt (again)
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
3:02 p.m.
New subject: "supported" versions of ovirt (again)
On May 12, 2014, at 13:26 , Sven Kieske <S.Kieske(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3:42 p.m.
New subject: "supported" versions of ovirt (again)
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
4:11 p.m.
New subject: "supported" versions of ovirt (again)
On May 12, 2014, at 14:42 , Morten Stevens <mstevens(a)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
6:34 p.m.
New subject: AIO 3.4 on fedora 19 initial errors before coming up
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(a)gmail.com>
>> To: "Roy Golan" <rgolan(a)redhat.com>
>> Cc: "users" <users(a)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
8:27 p.m.
New subject: AIO 3.4 on fedora 19 initial errors before coming up
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(a)gmail.com>
>>> To: "Roy Golan" <rgolan(a)redhat.com>
>>> Cc: "users" <users(a)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.
9:10 p.m.
New subject: AIO 3.4 on fedora 19 initial errors before coming up
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(a)gmail.com>
>>>> To: "Roy Golan" <rgolan(a)redhat.com>
>>>> Cc: "users" <users(a)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
1:59 a.m.
On Mon, May 12, 2014 at 12:28 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
> Hi,
>
> ----- Original Message -----
> > From: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com>
> > To: "Roy Golan" <rgolan(a)redhat.com>
> > Cc: "users" <users(a)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(a)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=sha...
complete engine.log for this part here:
https://drive.google.com/file/d/0BwoPbcrMv8mvWmVuMXF0ZjEzRk0/edit?usp=sha...
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
12:04 p.m.
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(a)redhat.com> wrote:
> On Mon, May 12, 2014 at 02:33:52AM -0400, Francesco Romani wrote:
> > Hi,
> >
> > ----- Original Message -----
> > > From: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com>
> > > To: "Roy Golan" <rgolan(a)redhat.com>
> > > Cc: "users" <users(a)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(a)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=sha...
complete engine.log for this part here:
https://drive.google.com/file/d/0BwoPbcrMv8mvWmVuMXF0ZjEzRk0/edit?usp=sha...
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?
3846
days inactive
3848
days old
17 comments
8 participants
participants (8)
-
Dan Kenigsberg -
David Sommerseth -
Francesco Romani -
Gianluca Cecchi -
Michal Skrivanek -
Morten Stevens -
Roy Golan -
Sven Kieske