- Devel - oVirt List Archives

Re: [ovirt-devel] [vdsm] pep8 issue
by Dan Kenigsberg 15 May '14

15 May '14

On Tue, May 13, 2014 at 05:22:15PM -0300, Amador Pahim wrote: > Building vdsm/master in F20, I've got: > > ./vdsm/virt/migration.py:223:19: E225 missing whitespace around operator > > In vdsm/virt/migration.py: > > 218 e.err = (libvirt.VIR_ERR_OPERATION_ABORTED, # error code$ > 219 libvirt.VIR_FROM_QEMU, # error > domain$ > 220 'operation aborted', # error > message$ > 221 libvirt.VIR_ERR_WARNING, # error > level$ > 222 '', '', '', # str1, str2, > str3,$ > 223 -1, -1) # int1, int2$ > 224 raise e$ > > pep8 is not accepting negative integer. Instead, it is handling the > minus sign as an operator. Quick workaround is change -1 to int(-1). > Is this a known? Now it is ;-) > > I'm using python-pep8-1.5.4-1.fc20.noarch It seems like a bug in pep8 tool, and I see that it does not reproduce with v1.5.6 thereof. I'm adding Matthias who may agree to backport the fix to Fedora 20 (or upgrade completely to 1.5.6)

3 6

spacing fix with PatternFly and tables
by Greg Sheremeta 15 May '14

15 May '14

Hi, With the PatternFly look and feel patch applied, GWT's spacing attribute is no longer reliable. When GWT renders a table with this, it puts "cellspacing='10'" into the table. This no longer works, probably because we changed to border-box model. The alternative: .some-table { border-spacing: 10px; border-collapse: separate; } Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

1 1

GFS2 mount via symlink problem
by Enrico Tagliavini 15 May '14

15 May '14

Hi, this issues i described on Red Hat bugzilla entry #888711 [1], but I'll recap here since there is come confusion (mostly my fault, sorry!) in the bug. System setup: CentOS 6.5 fully up to date SGI IS5000 SAS storage with 2 servers connected oVirt is 3.4.0 The Storage configured in oVirt is PosixFS, vfs type is gfs2 gfs2 is on top of CLVM Red Hat Cluster Manager (cman) is used to manage CLVM The issue is summarized by: [root@fionn-virt1 ~]# grep virtstorage /etc/fstab /dev/mapper/vg_is5000-lv_virtstorage /gfs2/virtstorage gfs2 noatime,nodiratime,nobarrier 0 0 [root@fionn-virt1 ~]# grep virtstorage /proc/mounts /dev/dm-13 /gfs2/virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 /dev/dm-13 /rhev/data-center/mnt/_dev_mapper_vg__is5000-lv__virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 [root@fionn-virt1 ~]# grep virtstorage /etc/mtab /dev/mapper/vg_is5000-lv_virtstorage /gfs2/virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 /dev/mapper/vg_is5000-lv_virtstorage /rhev/data-center/mnt/_dev_mapper_vg__is5000-lv__virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 The storage is mounted twice, first by the gfs2 init script and then by ovirt. As you can see even if both ovirt and gfs2 init script used the /dev/mapper/name symlink, in proc mounts there is the real device specified, the one the symlink is pointing to. I have no clue why only GFS2 does that (at least ext* FS are not, didn't checked anything else TBO, I have only ext* FS on other LVM volumes on the same system). In this case oVirt fails to check if the FS is mounted, since there is no entry in /proc/mounts matching the device name specified (the /dev/mapper/name one). I my example above I already applied a fix for that, so it is actually working. I've submitted a fix to ovirt gerrit, see [2], [3] and [4] (the latter is a unit test for checking gfs2). Note that [2] alone is not correct, it needs [3] as well to not break some other setup. Dan Kenigsberg of Red Hat suggested to move the discussion here, since this is a weird issue (why just GFS2 resolves the symlink?). I'm looking for advise, comments to the fix I proposed, but also about if this is actually the better fix? Like fixing GFS2 in the first place. That said I still think this should be handled by ovirt. It doesn't really matter if in /proc/mounts you have the symlink or the real device, it is the same mount Kind regards Enrico [1] https://bugzilla.redhat.com/show_bug.cgi?id=888711 [2] http://gerrit.ovirt.org/27321 [3] http://gerrit.ovirt.org/27425 [4] http://gerrit.ovirt.org/27514

2 2

limiting gwt compiler threads to 1
by Greg Sheremeta 15 May '14

15 May '14

Hi, On Fedora 20, I sometimes get GWT compiler crashes due to OutOfMemory. So I tried limiting to 1 thread like so: make clean install-dev PREFIX=$HOME/ovirt-engine DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari" BUILD_UT=0 DEV_EXTRA_BUILD_FLAGS="-Dgwt.jjs.maxThreads=1 -Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactory" When the two compiler threads spawn, they seem to fire at the same time. [INFO] Compiling 2 permutations [INFO] Compiling permutation 0... [INFO] Compiling permutation 1... I would expect there to be a delay while 1 waits for 0: [INFO] Compiling 2 permutations [INFO] Compiling permutation 0... <30 second pause...> <done> [INFO] Compiling permutation 1... <30 second pause...> <done> Do I have the options wrong? Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

3 4

vdsm sync meeting minutes May 13, 2014
by danken＠redhat.com 15 May '14

15 May '14

Vdsm sync call May 13, 2014 =========================== (Join us every other week, 14:30 GMT, on https://bluejeans.com/35386075901 or https://www.intercallonline.com/listNumbersByCode.action?confCode=353860759… ) =========================== - We had a long descussion about multiple graphic devices http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:gr… - fromani to figure out whether libvirt intends to provide an "alias" for graphics devices. Without it, it would be next-to-impossible to support multiple spice devices. It's already cumbersome to tell spice from vnc devices. - On input, Vdsm must accept both legacy display definitions (in vm.conf) and new-style ones (in vm.conf['devices']). If both exist, legacy ones are to be ignored. - writeable floppies. We believe that they were never used. Currently, vdsm makes floppies writable based on the writability of their filesystem imagea, and checks it in an unsafe manner. So we intend to make all floppies read-only. Actually, it would be nicer to expose a "readonly" flag, so that the client can use in case it really needs to write on the floppy (such as for saving Doom I game state). - live merge Saggi to review Adam's patches, and see if their use of task id is acceptable to him, and would follow the devel(a)ovirt.org thread on the matter. I'm still worried about Engine trusting the vdsm mapping of taskid to (vmid,volumeid), as Vdsm can crash and disappear. - unified network persistence. recently, unified persistence has become the default on the master branch http://gerrit.ovirt.org/25784 this may cause breakage to post-boot network connectivity, in case vdsm fails to start. - To avoid this fragility, we plan to have a leaner standalone service to configure networking on boot. - As a stopgap measure, the management network would be set as ONBOOT=yes, so that most setup would keep their connectivity. please report other problems! - ioprocess integration There's a worry regarding the path of replacing remote-file-handler with ioprocess. Currently, ioprocess is mimicking rfh semantics, while it is more reasonable to align with the future, and make the current rfh implementation mimick ioprocess. When network decided to move away from ifcfg to iproute2, we refactor the code to support both (with configurators), implemented iproute2, and only recently - moved to use it by default. This path ensures that we're not stuck with a convoluted code that matches no implementation. Have I forgotten anything? Dan.

2 1

ovirt-engine on F20
by Sandro Bonazzola 14 May '14

14 May '14

Hi, I'm looking at Bug 1055604 - "Failed to execute stage 'Setup validation': Cannot find Jboss at /usr/share/jboss-as" while running engine-setup on Fedora 20 I haven't seen news about wildfly support on engine side so I'm thinking about workarounds. What about providing jboss-as-7.1.1-11 for F20 as we do for el6? BTW, Juan, can you push spec file used for jboss-as to releng-tools repo? http://resources.ovirt.org/pub/ovirt-3.4-snapshot-static/rpm/el6/x86_64/jbo… If it can conflict somehow with wildfly, what about having it in /opt and configure the engine for using jboss from there? Comments? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

Re: [ovirt-devel] oVirt Node ISO rpm-wrapper update
by Sandro Bonazzola 14 May '14

14 May '14

Il 12/05/2014 13:00, Fabian Deutsch ha scritto: > Hey, > > the "wrapper rpm" I am going to talk about is an rpm which contains the > Node ISO image which can be used easily with oVirt Engine. > yum can be used to update this rpm and retrieve the latest oVirt Node > iso for easy consumption. > > For some time we did not deliver Node for Engine in a wrapper rpm > because a lot of things have changed (see below for the full story). > > To get this working again I've been cleaning up the repo and the > contained spec. > > Th repo layout is now: > node-3.0 branch: > Builds the base image from scratch > > ovirt-3.4 branch: > Builds the iso for Engine using edit-node and the base image > > Open issues: A repo file needs to be generated on each build which > contains all the relevant oVirt repositories. > > Sandro, do you have an idea how we can retrieve all list of all relevant > oVirt repositories using some curl oneliner? No, no curl onliner available for that. If you need one, we can provide it. > The repositories are needed by edit-node to pull in the dependencies of > ovirt-node-plugin-vdsm (vdsm, gluster, ...). > > The changes are _slightly_ tested, and once they are in a better shape > we can update Jenkins to use these repos to build the image and rpm for > Engine. > > > Technical background story: > The problem was that the basic way of how the oVirt Node for Engine ISO > was build was dramatically changed. > > Originally the vdsm packages were part of Node's build process. > You build the Node and it was usable with Engine. > > Now - After we introduced plugins, vdsm was migrated into a plugin > (ovirt-node-plugin-vdsm) and the plugin is not part of Node's build > process. ISOs we build these days do not contain vdsm specific bits and > are called "base images". > So if you build Node these days, it is _not_ usable with Engine. > Don't Panic. > > The ovirt-node-plugin-vdsm is added to the "base image" in a second step > using edit-node. This process is now used in ovirt-3.4 branch, where > also the spec file for the wrapper-rpm resides. > > - fabian > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

[QE] oVirt 3.4.2 RC status
by Sandro Bonazzola 14 May '14

14 May '14

Hi, We're going to start composing oVirt 3.4.2 RC on 2014-05-27 08:00 UTC from 3.4 branches. The bug tracker [1] shows no blocking bugs for the release There are still 75 bugs [2] targeted to 3.4.2. Excluding node and documentation bugs we still have 47 bugs [3] targeted to 3.4.2. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.4.2 should not be released without them fixed. - Please update the target to any next release for bugs that won't be in 3.4.2: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] - If you're going to test this release, please add yourself to the test page [5] [1] http://bugzilla.redhat.com/1095370 [2] http://red.ht/1oqLLlr [3] http://red.ht/1nIAZXO [4] http://www.ovirt.org/OVirt_3.4.2_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.4.2_Testing Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

vdsm disabling logical volumes
by Jiri Moskovcak 14 May '14

14 May '14

Greetings vdsm developers! While working on adding ISCSI support to the hosted engine tools, I ran into a problem with vdms. It seems that when stopped vdsm deactivates ALL logical volumes in it's volume group and when it starts it reactivates only specific logical volumes. This is a problem for hosted engine tools as they create logical volumes in the same volume group and when vdsm deactivates the LVs the hosted engine tools don't have a way to reactivate it, because the services drop the root permissions and are running as vdsm and apparently only root can activate LVs. So far the only suitable solution seems to be to change vdsm to only deactivate/activate it's own LVs. I would be grateful for any hints. Thank you, Jirka

6 26

latest python-lxml python-ethtool break VDSM on f19
by Roy Golan 14 May '14

14 May '14

This is a multi-part message in MIME format. --------------020703020706020607050801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit FYI and please guide Gianluca against what to open a BZ -------- Original Message -------- Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] Date: Sun, 11 May 2014 23:49:06 +0200 From: Gianluca Cecchi <gianluca.cecchi(a)gmail.com> To: Roy Golan <rgolan(a)redhat.com> CC: users <users(a)ovirt.org> On Sun, May 11, 2014 at 8:41 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote: On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote: On Sun, May 11, 2014 at 4:10 PM, Roy Golan <rgolan(a)redhat.com <mailto: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(a)ovirt.org <mailto: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 <http://mirror.netcologne.de> * livna: rpm.livna.org <http://rpm.livna.org> * rpmfusion-free: mirror.switch.ch <http://mirror.switch.ch> * rpmfusion-free-updates: mirror.switch.ch <http://mirror.switch.ch> * rpmfusion-nonfree: mirror.switch.ch <http://mirror.switch.ch> * rpmfusion-nonfree-updates: mirror.switch.ch <http://mirror.switch.ch> * updates: mirror.netcologne.de <http://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 --------------020703020706020607050801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> FYI and please guide Gianluca against what to open a BZ <div class="moz-forward-container"> -------- Original Message -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject: </th> <td>Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up]</td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th> <td>Sun, 11 May 2014 23:49:06 +0200</td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th> <td>Gianluca Cecchi <a class="moz-txt-link-rfc2396E" href="mailto:gianluca.cecchi@gmail.com"><gianluca.cecchi(a)gmail.com></a></td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th> <td>Roy Golan <a class="moz-txt-link-rfc2396E" href="mailto:rgolan@redhat.com"><rgolan(a)redhat.com></a></td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">CC: </th> <td>users <a class="moz-txt-link-rfc2396E" href="mailto:users@ovirt.org"><users(a)ovirt.org></a></td> </tr> </tbody> </table> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Sun, May 11, 2014 at 8:41 PM, Gianluca Cecchi <<a moz-do-not-send="true" href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi(a)gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div> <div class="h5"> <div class="gmail_quote">On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi <<a moz-do-not-send="true" href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi(a)gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div> <div class="gmail_extra"> <div class="gmail_quote">On Sun, May 11, 2014 at 4:10 PM, Roy Golan <<a moz-do-not-send="true" href="mailto:rgolan@redhat.com" target="_blank">rgolan(a)redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div bgcolor="#FFFFFF" text="#000000"> 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 ? </div> _______________________________________________ Users mailing list <a moz-do-not-send="true" href="mailto:Users@ovirt.org" target="_blank">Users(a)ovirt.org</a> <a moz-do-not-send="true" href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a> </blockquote> </div> </div> </div> <div class="gmail_extra">I didn't change anything on this server. It is an all-in-one config so both engine and vdsm host are on it. </div> <div class="gmail_extra">Yesterday and every previous day I was able to start the system and start the VM; I only applied the yum update command yeseterday </div> <div class="gmail_extra">(with --exclude=sos due to the opened bug) and then I made shutdown of the system. </div> <div class="gmail_extra">Today after startup I got this problem. [root@tekkaman vdsm]# vdsClient -s 0 getVdsCaps Unexpected exception </div> <div class="gmail_extra">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 </div> </div> </blockquote> </div> </div> </div> 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 <div class=""> May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 </div> May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64 </div> <div class="gmail_extra">I can also try to rollback and see... </div> </div> </blockquote> </div> I was right. </div> <div class="gmail_extra">Against what to bugzilla? </div> <div class="gmail_extra">This is a show stopper for fedora 19 ovirt users... </div> <div class="gmail_extra"> [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: <a moz-do-not-send="true" href="http://mirror.netcologne.de">mirror.netcologne.de</a> * livna: <a moz-do-not-send="true" href="http://rpm.livna.org">rpm.livna.org</a> * rpmfusion-free: <a moz-do-not-send="true" href="http://mirror.switch.ch">mirror.switch.ch</a> * rpmfusion-free-updates: <a moz-do-not-send="true" href="http://mirror.switch.ch">mirror.switch.ch</a> * rpmfusion-nonfree: <a moz-do-not-send="true" href="http://mirror.switch.ch">mirror.switch.ch</a> * rpmfusion-nonfree-updates: <a moz-do-not-send="true" href="http://mirror.switch.ch">mirror.switch.ch</a> * updates: <a moz-do-not-send="true" href="http://mirror.netcologne.de">mirror.netcologne.de</a> 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'] </div> <div class="gmail_extra">And I'm now able to start and connect to my VM again. </div> <div class="gmail_extra"> HIH, Gianluca </div> </div> </div> </body> </html> --------------020703020706020607050801--

4 3