- Devel - oVirt List Archives

oVirt Node Weekly Meeting Minutes -- 2014-05-20
by Fabian Deutsch 20 May '14

20 May '14

--=-MQdMonI9tuLhND8+cSl4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-20-13.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-20-13.00.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-20-13.00.log.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D #ovirt: oVirt Node Weekly Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Meeting started by fabiand at 13:00:01 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-20-13.00.log.html . Meeting summary --------------- * Agenda (fabiand, 13:00:30) * Build Status (3.0.5) (fabiand, 13:00:44) * Feature Status (3.5) (fabiand, 13:00:53) * Other Items (fabiand, 13:01:00) * Build Status (3.0.5) (fabiand, 13:04:14) * ovirt-node 3.0.5 base image passed sanity testing (fabiand, 13:05:14) * base image will be called ovirt-node-base-iso-* (fabiand, 13:07:04) * iso for engine will be called ovirt-node-* (fabiand, 13:07:14) * RC around the door. (fabiand, 13:08:47) * Feature status (3.5) (fabiand, 13:09:21) * generic-registration: Backend code is working, schema changes need to address some issues (fabiand, 13:13:08) * tight on time (fabiand, 13:13:16) * hosted-engine: Plugin posted up for review (fabiand, 13:13:32) * virtual-appliance: oVirt Virtual Appliance is in progress, based on oVirt pre-3.5 packages, builds in lmc now (fabiand, 13:14:12) * virtual-appliance: Wrapping in ova is pending (fabiand, 13:16:02) * Other Items (fabiand, 13:17:52) Meeting ended at 13:19:09 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * fabiand (70) * jboggs (7) * rbarry (5) * ovirtbot (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot --=-MQdMonI9tuLhND8+cSl4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJTe1a1AAoJEC9+uOgSHVGUKfoP/ikEI20FTTyrEnUTVhCBgPAZ maetbswOxD6qbcD3SToxxRwifBNsXCCOvy/J/6OSnf1puovj9m0lFZwxioekddDN P0QfuP71Yf5Jmu1uyxc4x5DaldRpboI1+luK/+pWvsgApF5PFf/7vtk3jCqB+4Su kuXgxz+uaPMuq7URpNOp5l0/Zc1GS93F96bhwsEymlv48yZi5R9VyRWYOWImPYza cUU59V9PlDRgKfwVZh6muyX2SffG9yBBW4aXR6oi6GQ1K2Hj5lXjvYHNkdbbsMwZ MglxCeQDtH7hrKDiLAl+fz69wWHc89o8VZF9GT8LUfKF2SUy9EU/dvqeQsW6EMw5 SjEl7YFpLn64oGR5A2wVH6vn/gKYzvDLpghQQdbIE4QJfmSjPyXtf+U4vfJrexTR Du8voIv6r0rc6t0ApEtbSZtWfLco7obFWMK4lJ1aL72397OKgJiNbT8DnnN/NT8C Nos085J7TgvtcX0vQosbfS70hjag6BiD7f++kxKB9s+jNbdFeWQ7Rt7mcloMyxnd 1KnR1tjfaY5zkGtYORIEitm/OmdkjdTMNIoYLh3lw6OW9WGJEuDFIk3MuvKBjEDJ WebA1SZQfgF501eWUGQtRydANF4OWSgjrr+m4rNP55TldSb3ISfrzy9B+/Bp45LD Ww3Gr0ySTz3r+1JLhwHc =z++f -----END PGP SIGNATURE----- --=-MQdMonI9tuLhND8+cSl4--

1 0

Call for Papers Deadline in 1 week: OSCON Open Cloud Day
by Brian Proffitt 20 May '14

20 May '14

Conference: OSCON Open Cloud Day Information: The Open Cloud Day at OSCON is a look at the “state of cloud” in 2014, gathering industry practitioners to give their take on the state of public and private cloud, IaaS, and PaaS platforms, and where the industry is going in 2014 and beyond. Date: July 21, 2014 Location: Portland, OR Call for Papers Deadline: May 27, 2014 Call for Papers URL: http://www.oscon.com/oscon2014/public/cfp/337 -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

Call for Papers Deadline in 10 days: PostgresOpen 2014
by Brian Proffitt 20 May '14

20 May '14

Conference: PostgresOpen 2014 Information: PostgresOpen 2014 will be held on September 17 - 19th in Chicago at the Hotel Sax. It will cover topics for PostgreSQL users, developers and contributors, as well as decision and policy makers. Date: Sept 17-19, 2014 Location: Chicago, IL Website: https://postgresopen.org/2014/ Call for Papers Deadline: May 30, 2014 Call for Papers URL: https://postgresopen.org/2014/callforpapers/ -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

Call for Papers Deadline on Sunday: DevOps Enterprise Summit
by Brian Proffitt 20 May '14

20 May '14

Conference: DevOps Enterprise Summit Information: DevOps Enterprise will assemble some of the best practitioners and leaders in the DevOps space, who are transforming how software and services are delivered in large, complex organizations Date: Oct 21-23, 2014 Location: San Francisco Bay Area, CA Website: http://devopsenterprisesummit.com/ Call for Papers Deadline: May 25, 2014 Call for Papers URL: https://docs.google.com/a/proffitt.org/forms/d/13-4lAYwcUmNeIS5tLRK0hshHVh5… -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

Re: [ovirt-devel] latest python-lxml python-ethtool break VDSM on f19
by Douglas Schilling Landgraf 20 May '14

20 May '14

Hi, On 05/19/2014 01:47 PM, Douglas Schilling Landgraf wrote: > On 05/12/2014 03:46 AM, Antoni Segura Puimedon wrote: >> >> >> ----- Original Message ----- >>> From: "Roy Golan" <rgolan(a)redhat.com> >>> To: devel(a)ovirt.org, "Yaniv Bronheim" <ybronhei(a)redhat.com>, >>> "Francesco Romani" <fromani(a)redhat.com> >>> Cc: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com> >>> Sent: Monday, May 12, 2014 8:13:01 AM >>> Subject: [ovirt-devel] latest python-lxml python-ethtool break VDSM >>> on f19 >>> >>> FYI and please guide Gianluca against what to open a BZ >> >> I don't think python-lxml is related. I think it's only python-ethtool. >>> >>> >>> >>> -------- 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 >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > We have a higher version of VDSM as well available for F19, in case you would like to test: https://admin.fedoraproject.org/updates/vdsm-4.14.8.1-0.fc19 Karmas are welcome! -- Cheers Douglas

1 0

new ovirt-deps repo package
by Sven Kieske 19 May '14

19 May '14

Hi, I got a question regarding the newly introduced deps package which installs epel etc: https://bugzilla.redhat.com/show_bug.cgi?id=1082013 How does this handle already installed EPEL repositorys? would this conflict somehow? Looking at the code at: http://gerrit.ovirt.org/#/c/26330/8/ovirt-el-deps.repo you restrict the packages to those needed by ovirt. Maybe I don't know yum internals enough, but doesn't this break if other packages from epel are already installed? -- 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

2 1

Vdsm patches need review and merge
by Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) 16 May '14

16 May '14

--_000_08AA403C8399104A89AF710307FA78AE24404869G5W2743americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, Could you help to review these numa vdsm patches: http://gerrit.ovirt.org/#/c/27399/ http://gerrit.ovirt.org/#/c/27090/ http://gerrit.ovirt.org/#/c/27403/ http://gerrit.ovirt.org/#/c/26876/ You had already reviewed some of the patches, but after that I modified the= transferred data format because of the xmlrpc limitations. So could you pl= ease review them again? Hi Dan, I have modified your comments for some of the above patches. Could you plea= se take a look and merge those if no more comments? Thanks & Best Regards Shi, Xiao-Lei (Bruce) Hewlett-Packard Co., Ltd. HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86 18696583447 Email xiao-lei.shi(a)hp.com<mailto:shiguo.li@hp.com> --_000_08AA403C8399104A89AF710307FA78AE24404869G5W2743americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi Martin,<o:p></o:p> Could you help to review these numa vdsm patches:<o:= p></o:p> <a href=3D"http://gerrit.ovirt.org/#/c/27399/">http:= //gerrit.ovirt.org/#/c/27399/</a><o:p></o:p> <a href=3D"http://gerrit.ovirt.org/#/c/27090/">http:= //gerrit.ovirt.org/#/c/27090/</a><o:p></o:p> <a href=3D"http://gerrit.ovirt.org/#/c/27403/">http:= //gerrit.ovirt.org/#/c/27403/</a><o:p></o:p> <a href=3D"http://gerrit.ovirt.org/#/c/26876/">http:= //gerrit.ovirt.org/#/c/26876/</a><o:p></o:p> You had already reviewed some of the patches, but af= ter that I modified the transferred data format because of the xmlrpc limit= ations. So could you please review them again?<o:p></o:p> <o:p> </o:p> Hi Dan,<o:p></o:p> I have modified your comments for some of the above = patches. Could you please take a look and merge those if no more comments?<= o:p></o:p> <o:p> </o:p> Thanks & Best Regards<o:p></o:p> Shi, Xiao-Lei (Bruce)<o:p></o:p> <o:p> </o:p> Hewlett-Packard Co., Ltd. HP Servers Core Platform Software China <o:p></o:p> Telephone +86= 23 65683093<o:p></o:p> Mobile +86 18696583447<o:p></o:p><= /span> Email </b= ><a href=3D"mailto:shiguo.li@hp.com"><span= style=3D"color:blue">xiao-lei.shi(a)hp.com</a><o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_08AA403C8399104A89AF710307FA78AE24404869G5W2743americas_--

4 5

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