May 2014 - Devel - oVirt List Archives

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

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

Sortable columns in UI
by Vojtech Szocs 14 May '14

14 May '14

------=_Part_4640012_120094896.1399991871152 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hey guys, oVirt UI has been missing column sort functionality for quite a while now, but here's some good news. I've just merged patch [1] that adds support for both server-side and client-side sorting of table columns. This patch adds the necessary infra/API; column sorting must be enabled per-column for given table, just like with column resizing. [1] http://gerrit.ovirt.org/#/c/25910/ Currently, only TextColumnWithTooltip (and its subclasses) support sorting, however this can easily be changed in future by having the column class extend SortableColumn. To enable sorting: // Enables server-side sorting via search query // ... SORTBY name ASC|DESC column.makeSortable("name"); // consider using shared constant -or- // Enables client-side sorting using comparator column.makeSortable(comparator); In order for server-side sorting to work properly, corresponding SearchableListModel must apply the search options while executing "Search" query. For example, in DataCenterListModel: @Override public boolean supportsServerSideSorting() { // Default is false return true; } @Override protected void syncSearch() { // Append "SORTBY" clause to search query String search = applySortOptions(getSearchString()); ... } If a model doesn't support server-side sorting, client-side sorting will be used as fall back (assuming a comparator was provided). In general, all main tab list models in WebAdmin utilize "Search" query, so we can enable server-side sorting for columns that exist within main tab tables. As for sub tabs (whose list models generally don't use "Search" query, but also don't support paging at the moment), these can simply use client-side sorting, i.e. reuse existing comparators defined in Linq class. PS: I've attached a screenshot depicting sorted column in action. Regards, Vojtech ------=_Part_4640012_120094896.1399991871152 Content-Type: image/png; name=sorted-column.png Content-Disposition: attachment; filename=sorted-column.png Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAALQAAACnCAYAAAC4j3YHAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA B3RJTUUH3gUNDiIpMfRzFAAAGZdJREFUeJzt3XlcVdXC//HPOYBwFBQUUFIQTEUfkHKg6xPOYw5J kXWdbnYbsG6P1XPN1DQ1eyrU7OnavaXcX5mg3kckvQpqOOKAI45kmgoOCAKCosh44KzfH8iWg4Cc AaHder9eR8+e1lp7nS+bfTb7rKOZOHGiEEIghEB6tDQaDRqNRnkOKK+DfE0errr+szUYDEadKD0a Go0GIQQajQatVmvU9/I1ebia+s/Wy8uLsLCwBm7e79fMmTO5evUqWq0WKA+zl5cXf/rTn+jUqRO2 trYN3MLGqbS0lAsXLhAZGWnUf5rExETRs2fPBm7e79exY8f44osvjAL9/vvv4+Pj08At+224dOmS Uf/ZyjA3rIr+r3xq0b59+4Zqzm9ORV8ppxwN2RipXMW5YMVzGxubBm7Rb4eNjY1R/8lAN0LyjaD5 tA3dAEmyJhloSVVkoCVVqdM59IA/TleeN2vqQDdfb159aTidO7Src0Xrf0pg6Yp/E792semtvGfP odOs/HEHqddv0LKFI8P69eTPLw5TLtlYyhptbGg///wzO3fuJDs7G0dHR7p3786QIUOUPpo1axYA n3/+uUX1HDhwgJiYGIvLsTaTkhC/djHLPn2HjOxbTJ33DRcvp9d5272Hk0xuXGVHT59n/leraO3q zIblc+kV4Evk+p18H7XNonIrs7SNDe3ChQusWbMGZ2dnZs+eTadOndi9ezc7duywel1nzpyxepnW YPJVDs/H3Hhj3AhmL/6BiB93sGDaywCkpt/g65UbOXvhKgaDwM+3Pe+9+jyPtW5ldIQf8MfpxK9d XOv61YmK3YsQgonPDcKxmY6XQwZz5NQ5buflK+sUFesJX7OZ+EOnKSwqYUDvAP76egh2draUlpUx ZMJMWjo78V+Tg1m6YgP2TeyY8dZL9PDvVG0baytPX1rG0Inl5b0wog8ro7ez9OO/8O2qWC5eSscg BP/RyYuprwTj3a61SX1ccQnKVPv370cIwcCBA9HpdAwaNIjz58+Tn5//QJkV0zNnzgRQ/lpcefra tWts2bKFtLQ0hBB4eXkxZswYvvzyS6WcWbNmERYWhl6vZ+vWrSQlJVFcXExAQADPPfcctra2lJWV MXv2bJycnHj66afZuXMnb775ZrVlu7u7m7XvFcz6Xf1E1w4AnDqbosxb+G0Ux5IusGROKJ+8/zJH Tv7Kwm+jAIx+hVc8r2396ly+lgGAj2cbAFq7ubDumzlMe+MFZZ3wNZtZ/1MCoeNH8u6fn2Nr/FHW bd4HgO29a7t5+YWU6PVMn/Iimdm5/H1lTI1trK08O9vy8u7mF2Jna0vM9wv4+KtVnPolhWWfv8OS OW/w86+X+cfKTaZ1rgUyMzMBaN26/AfIxcWFWbNmERISYlZ5a9asISUlhalTp/L6669z5coVYmJi jG6VqHi+detWDhw4wDPPPENwcDCJiYns378fQLmuXlhYiK2tLfPmzauxbEuZdR3awaEJAPkFRcq8 v3/ytvK8RF8KwC8XrtRYhqnr594pPxLr7tVdnT33ThmCAv2w0WoJ+3Yt2/cfZ8JzA5V19PpS+gb6 08SufNevpmVZVF6JvpRh/Xpi38RO2Y/1W/fT9yl/Yr9fgJ2d6V1s7nXo/PzyPrKzs3toGVWXVzet 1+sBSEhIwM/Pj7lz52Jra2u0bsXzpKTyvuratStarZZ169Zx4sQJ+vfvr6xbWlpK9+7dsbW1rVPZ 5jAr0LfvhatF82bKvGNJF/j7yk2kpt+gzGAAQF9aVmMZpq7f0tmJzBu3KCwuoZnOodp17tw7/Xj2 1bnKvIwbtx5Yr1nT+9uXltVcZ13La+HUFIDpoWNZ+sNGNsQdYEPcAZya6Xj31ecZ0qd7jXVYk6Oj I7m5uej1euzt7S0uLyQkhJiYGA4ePMjBgwfR6XSMGTOGJ5988oF1CwoKAFiwYIEy79atB/uqadOm JpdtCrMCfeZ8+ZG0u9/jyrxFy6LIzM7l20+n0sHLg+F/+rDWMkxdv+vjnmTeuMWlqxn4+3qTnpnD 9M/+HwN6B/DG+BEAuLu6kJaRzbZVnytHYEvUtbyK89HePbrSu0dXrl3PZvfBk3y3No5/RMQ8skB7 enqSm5tLRkYG7du3JycnhxUrVtCtWzeGDx9e7TY2NjaUlZVRWlpKaWmp0bIuXbrQpUsXsrOzOX36 NNu3b2fz5s3Vhs7Z2ZmcnBw++eSTWu8QrOgrU8o2hcnn0JnZuaxYtw0HezsmPT9YmV9YXAJAkyZ2 bPgpAcdmOgAKCosBcLC3K9/+3hHuYetXNT54IFqtllUbdnI3v5DI9TtJy8jGxub+Lgx6urwzdh04 yalfUhg2aRazFn5f532r2kZTy5u18HtGvjKHgsIiBvR+AgDHZtX/NqlNxc39pj769euHVqtl9+7d FBYWsnv3bnJycpT7haueKgghcHV1BcqvkJw5cwY7Oztl+cqVK5k/fz5FRUV069YNAJ1OhxBCWe/W rVsIIQgICADg1KlTpKSk8NFHH7Fy5coa662tbFMfldnMnz9//sM6+Ifo7cr/m7YfxNPDjdlTJ9DJ +zFlHefmjvz862V+ik+kWxcf+gT6c+b8ZbbvP8Hzw4MoKCzmXMo14vYmMm7MgIeuX5WrS3N8O7Rj f+IZlq/ZQm5ePi+N6sfksUOVn3p/X2+KivWs37qfuD3HeKJrB957LUT5YanYj1deHFbtdNU2mlpe Ow9XLlxKZ/XGXcTuPIJf5/Z8MOUlWjo71dq/0dHRRjcnjRw58mEvSbWcnJxo27YtZ8+eJS4ujvz8 fIKCghg0aJCyzq5duwCUeS1btuTy5cskJSXh6+vLlStXKC4upn///ri6upKens6ePXs4evQoXl5e PP/88zg6OlJcXExaWhrHjx+nb9++eHl5odfrOXjwIMePH8fHx4dnn30WBweHautt1apVjWWbasuW Lfc/uSLknTANbty4cUb3Qy9durSBW/Tb8s4779y/H7qB2yJVo6yWN6pS7WSgGyHDvas+kulkoBuh imu0kulkoBshGWjzyUA3QlWvB0t1JwPdCFS+cUij0chzaBNV7j8Z6Eagffv2Rteh5RHaNJX7TxMW FiYAZsyY0aCNkiRrkB/BklRFBlpSFRloSVVkoCVVkYGWVEUGWlIVGWhJVWSgJVWRgZZURQZaUhUZ aElVzLo5qVevXixatMjow5e9evUiMTHRag2rq/Dw8AfmhYaGVrteaGio8r+16tRqtTg7O9O7d2/a tav74JWNRV37r77rtlY/mhXoJk2asHXrVvr06UOTJjWPZPSomPICVKwbHR3N2LFjLa7TYDCQmppK fHw8kyZNMru8hvSoAlxb3dbqR7MCrdfrGT9+PJGRkbz22mtGy1JTU5k3bx4XLlygQ4cOzJs3j1at WjF58mTWr1+PVquluLiYF198kaioKBwcHDAYDIwdO5YVK1bQokULs3emsqysLHbv3k1BQQGBgYHK /PDwcHx8fLh58ybh4eFMnjzZ4lGGDAaDMn7b7du3iY+PJycnBxcXFwYMGECLFi2IiIigW7du/Prr rwQFBXH9+nXOnTtHnz596NixI7m5ucTHx3Pz5k1cXFzo378/Op2O6OhoJk6ciFarxWAwsHr1asaO HUtJSckD9bi4uFi0H5VV1x5nZ2ciIyPx9fXlzJkzvPbaa+Tl5REfH09WVhbOzs7069cPNze3avvh Ye2zRj+aFWghBD169GDTpk1kZWUZjRgZFhbGpEmT6Nu3LwkJCSxcuJDly5cTEBBAfHw8gwYNIi4u jtu3bxMXF0dwcDB79+7F39/f7DBX/bUZGhrKoUOH8PPzw9fXl7NnzxotHzp0qMWnHuHh4djY2NC8 eXOaNm3KwIHl493t37+fgIAAvLy8SE1NZf/+/Tz77LPo9XqcnZ0ZOnQosbGx9O3bl9GjRxMbG0vH jh1JSEjAx8eH0aNH88svv3Dw4EFGjRqFm5sbaWlpeHp6cu3aNdzc3NDpdOzatavaeszdl8pCQ0Nr bE9JSQkODg688sorAOzbtw8vLy9GjBhBamoq+/btIyQkpMZ+qO9+tOgG/ylTprBs2TLmzr0/9tuJ Eyc4fPiwMl0x0MjYsWNZtmwZgwYNIjo6milTpvDjjz8SHBxMVFQUb775ptntqC6YOTk5jBgxAjs7 O7p27cqhQ4fMLr+mOs+dO4ezszNt2rRR5mdkZJCWlqZMVwyLJYTA29sbGxsb9Ho9Pj4+2NjYUFJS PoJUVlYWw4YNw9bWli5dunD8+HEAOnXqRHJyMp6enqSkpNCpU6da6zF3X6qqqT1CCPz8/JQjaUZG BkOHDsXW1hYfHx/l+xXr2j5r96NFgfbw8MDd3Z2TJ08q8+zt7dmxY4cyKF+FgIAAcnNz2bZtG4WF hYwfP54NGzawfft2cnNzlaGkrKXyV33V10eaunTpQkJCAk5OTjRrVj5wpY2NDS+//LIyVFZllb+u repXt1V81W9V3t7eHD58GL1eT1paGn369HloPdZQU3sAozprWs+U9lmzHy2+bDd58mQiIiKUN4dP PvkkkZGRFBUVsXHjRt566y1l3ZCQEMLCwggJCUGj0RASEsJnn33GCy+8UFPxZnNxceH8+fOUlpY+ cMoB5e+qCwsLLa4nMDCQw4cPK4PDtGnThlOnTlFaWsq5c+eIjY2tUznu7u6cO3dOaW/FaZyNjQ1t 27bl6NGjtGvXTjlSmVtPXdXUnqo8PDxISkpCr9eTnJzMunXrzGqftfrR4kDrdDqGDRumHPKnT5/O iRMnGDp0KKtXrzb6dTZy5EhsbW0ZPXo0AKNGjcLOzo4RI0ZY1Ibw8HCjB0Dv3r05ffo0kZGR2NjY PPCTHBQUxNq1ay2qF8qv+HTr1k05pQkKCiIjI4OIiAiSkpKo6zf1Pv300yQnJxMREcHly5cJCro/ vl/nzp05c+YMHTt2NGq/OfXUVW3tqSwoKIj09HQiIyM5fvw4/fr1M6t91upH+ZlCSVXkXwolVZGB llRFBlpSFRloSVVkoCVVkYGWVEUGWlIVGWhJVWSgJVWRgZZURQZaUhUZaElVlPuhz527iqO7W0O2 RZIsZnSDv5Od7pE34HraVTzaej3yeiV1kqcckqrIQEuqIgMtqYoMtKQqMtCSqshAS6oiAy2pigy0 pCoy0JKq/CYCHRO3nYKCgjqv79O+JT7tW5J0+oTRtKR+jT7QexMOcfT4SaI3bTZ526i16yktvT+d c8OKDZMapUYd6Cup19ixdy8guJhyiV17E+q8rb29A8eOJVBcaDyQ4JIvPuPp/+xG545tGDLoD+zf F09ZaSk+7VsS2NOX1atW0P2Jx+nRvRMb1q8lfPnXBPh784fArvz0UwwAt2/n8v60t+nRvRNPBnTg zdCXuXEjy5q7Lpmp0Qa6oKCAqH9vAgFCABqIT0jg0pUrddq+uLgIP7/uHD162Gj+tPc/ZMeOJLZt +4Xk5AvM+OA9DIbye7Ru3rwJwpElX37HrZs5zP5wGi2au/K/X/1AVlYmC+bPoaQYPprzPj9G/4u/ f/0vln69jri4WGZ/+AH1NMipZAKLhtOtT+s2xZJ39y5oNJQPiitAQPSmWN56dTKOzRwfWsaQIc+x bdt643KjVvPZp3PJzb0FQHr6Ve7eLV9mMJQxaNAYWriUd0thYQH9+4fQvEX5dEbGNfLzYcf2rQBM nDhMKffwob3k3wWn5pbtt2SZRnmE3rVvH8mXLoOA8n/unTZoIO9uPmv/HYNer39oOT16BHHi5CHs 7w26DhAW9jG5ubeIibk/prWh7P42TZrYo9PdH6nUzs4eXdPyaSEEhjLQNS0fw/jAgeskJt4kMfEm u3aloC8xd48la2l0gc7OucW5X1Nwd3OjjXtr3N1ccXN1xd3VFXc3V9q0dufu3QJ+vZjy0LK0Wi2B gX+guKhImae/N+zv2bOnlCF2i4qMx4m+N056jdMDBgwBYNu29VxITiAoyIMPZoynpaupeytZW6M7 5XBt5cJfXp9stfJGjXqOyIjvlOk3Qt/mm398RXz8Fv46bS7hy//GhAn9TCpz7rzPMBhsWLp0PiUl Rfyhd1/++72F5N0GJ+t855FkJmV86ODg8Q3yyZH6+sRKxSW6Vm6g18Od3PvThQXljyb2YGMDhYWg 1cC9weNp5fZgGVWnhYD8u6AvKX9uaweOjqA1HlddesQa3RHaWlpV+niknZ3xtK5p+aPy9MPKqDqt 0YCjk+XtlKyr0Z1DS5IlZKAlVZGBllRFBlpSFRloSVVkoCVVkYGWVEW5Du3o7kae3vKvCjZHQ9Ur qY8S6HYtH/24dgC0lOPaSdYjTzkkVZGBllRFBlpSFRloSVVkoCVVkYGWVEUGWlIVGWhJVVQbaE3V T7bWc5n1UV9tHnV9vxUmfQQrXKOhZ8+edV7/2LFjhArx8BUlyVrCwsJEWFiYqKvl5Z8JfehjOdS5 zMp27twp/P39hYODg/D19RVxcXHKsnXr1omOHTsKe3t74efnJ+Lj45VlZ8+eFd26dROurq4iJiZG UKn++iizqtqWXbt2TQwYMEA4OjqKvn37isuXLyvLbty4IUaOHCl0Op144oknxJEjR+rU7trq+z0z OdBCPDzU5oZZCCH8/PzE5s2bRVFRkfj++++Fj4+PsszV1VUcOXJElJSUiDVr1ogePXooy4KDg8X8 +fPFnTt3xMcff2z0gtdHmVXVtmzixIlixowZ4s6dO2LOnDli3LhxyrLJkyeLmTNniry8PLF+/Xqj +mtrtwx09cwKtBA1h9qSMFdVXFz8QDBnzpxpdISr4ObmJrKysoQQQqSlpdX4gtdHmULUHjAPDw+R kZEhhBAiMzNTPPbYY8oyd3d3kZmZWeO2NbVbBrp6Zr8pDBWC8Crzwu/Nt0R8fDyBgYE4OTmh0xnf ARgTE0N2djZPPfUU3bt3Z+/evcqy3NxcXFxcAHB1da33MjUaTZ3fmOXk5Cjbt2rViuzsbGXZrVu3 aNmy+rGra2u3VANzj9AVllv5yNymTRuxatUqcefOHZGXl1ftkchgMIjIyEjh6empzHN1dVWOplev XjXarj7KrKq2ZW3btlWOwpmZmaJt27bKMg8PD5GamlrtdrW1u7b6fs8svmxXcaS21tWMLl264Ovr S0lJCYsXL8bNzY2LFy8C0Lt3b6KioigtLaVDhw6Uld0fZTEwMJB//vOf3L17l++++87o6FkfZZpi yJAhLF26lPz8fJYsWcLgwYOVZSNHjmTRokXk5uYSFRWFv79/ndot1cDSI7S1JSYmChcXF+Ht7S22 b98u5s2bJ5o2bSqEECIuLk74+vqKJk2aiM6dO4vY2Fhlu1OnTomuXbuKVq1aiY0bNwqdTicMBkO9 lVkV94dJVR4V0tLSRP/+/YWjo6MYPHiwSEtLU5ZlZ2eL4cOHC3t7e+Hv7y8OHjxYp75AHqGrpYxt N2PGjIb7qZIkK1HtXwql3ycZaElVZKAlVZGBllRFBlpSFRloSVVkoCVVUe6HvnnrdkO2Q5KsQgl0 E12zhmyHJFmFPOWQVEUGWlIVGWhJVWSgJVWRgZZURQZaUhUZaElVGl2gnXR2yqN92zZM+OOL/JyU VKdtS0tLmffRbNxbNre4DRXGjHrGorKkR8ukkZPW6OxMHjlpQqHe5EblFeoxGAykXr3K6lURPDNs ENt2xPMffn61bpd27RpffrGI1OtZJtdZk4sXLlitLKn+mRToCYV61ujsCK3DuuH31jeXVqulvbc3 H86Zi1ar5fNPPyFyzf8BkJFxnSmvv8qhgwfo2SuQf0VF06KFMz2fLP+AqaeHO3mFevbE7+aD9/+b lORkPL28WLzkKwYPGQqUH4XzKrWv6jTAwH5BpKZexUlnx/QZs5g7f4HZ+yM9Giafckwo1D8wHkdV loa5qldefY19e/co0zPen4afnz8pV9LoFfgUH8/7CIDs3LsASjCnT3uPBf/zOdcysvnrtA94d+pf TKp3994EpTwZ5t8Gk47QFSYU6gmv4Uht7TADODu7cOfO/Zun4nfv4sjxkzRzdGTqu+8xsG9Qtdsd OXZKef7SuPG8NeV1q7ZLanzMflNY3ZG6PsIMcPnSJdzc3JXpvLw7dPT2xElnRwevtmRkXK92u317 99A/qDdt3Fxwc3GyerukxseiqxyVQ11fYQZYFfEDAwcPUabd3VtzPesmeYV68gr1yqlGVX9+eRJ/ mfoOF1Oukp6ZY7RMq9Wi15e3Nysrs17aLT16Fl+2qwh1fYQ5PT2NxQs/J2LlD3wwY5Yyf8iwYfzt qy8pKCgg4ocVjB4xrNrtO/v60qmzLyX6Er763yW4urqRkpwMQJs2HmzdEsvdvDz+9uUSbG2rP/t6 7LG2pCQnU1JSYvX9k6zPrHPoqqwd5orrwE2bNaNPn75s3baTDo8/riyfv+B/eGvKG3Ro3xZPT0/+ 9vU31Zbzadgixox8hhYtWvD1N8vQaDT851M9yMy5zdyPF/DO2+VvEsMWf4GjoxNCiAeG+4resInn g0dx5/YdLqWmW3U/JetTRk56+91pDd0WSbJYo/tLoSRZQgZaUhUZaElVZKAlVZGBllRFBlpSFRlo SVWUP6yUFOY3ZDskySqUQLd0adGQ7ZAkq5CnHJKqyEBLqiIDLamKDLSkKjLQkqrIQEuqIgMtqYoM tKQqMtCSqshAS6oiAy2pigy0pCoy0JKqyEBLqiIDLamKDLSkKjLQkqrIQEuqIgMtqYoMtKQqMtCS qshAS6oiAy2pigy0pCr/H+pGyQEKLWVgAAAAAElFTkSuQmCC ------=_Part_4640012_120094896.1399991871152--

4 4

[QE] oVirt 3.5.0 Alpha status
by Sandro Bonazzola 14 May '14

14 May '14

Hi, We're going to start composing oVirt 3.5.0 Alpha on 2014-05-16 08:00 UTC from master branches. The bug tracker [1] shows the following proposed blockers to be reviewed: Bug ID Whiteboard Status Summary 1001100 integration NEW Add log gathering for a new ovirt module (External scheduler) 1073944 integration ASSIGNED Add log gathering for a new ovirt module (External scheduler) 1060198 integration NEW [RFE] add support for Fedora 20 Feature freeze has been postponed to 2014-05-30 and the following features should be testable in 3.5.0 Alpha according to Features Status Table [2] Group oVirt BZ Title gluster 1096713 Monitoring (UI plugin) Dashboard (Integrated with Nagios monitoring) infra 1090530 [RFE] Please add host count and guest count columns to "Clusters" tab in webadmin infra 1054778 [RFE] Allow to perform fence operations from a host in another DC infra 1090803 [RFE] Change the "Slot" field to "Service Profile" when cisco_ucs is selected as the fencing type infra 1090511 [RFE] Improve fencing robustness by retrying failed attempts infra 1090794 [RFE] Search VMs based on MAC address from web-admin portal infra 1090793 consider the event type while printing events to engine.log infra 1090796 [RFE] Re-work engine ovirt-node host-deploy sequence infra 1090798 [RFE] Admin GUI - Add host uptime information to the "General" tab infra 1090808 [RFE] Ability to dismiss alerts and events from web-admin portal infra-api 1090797 [RFE] RESTAPI: Add /tags sub-collection for Template resource infra-dwh 1091686 prevent OutOfMemoryError after starting the dwh service. network 1078836 Add a warning when adding display network network 1079719 Display of NIC Slave/Bond fault on Event Log network 1080987 Support ethtool_opts functionality within oVirt storage 1054241 Store OVF on any domains storage 1083312 Disk alias recycling in web-admin portal ux 1064543 oVirt new look and feel [PatternFly adoption] - phase #1 virt 1058832 Allow to clone a (down) VM without snapshot/template virt 1031040 can't set different keymap for vnc via runonce option virt 1043471 oVirt guest agent for SLES virt 1083049 add progress bar for vm migration virt 1083065 EL 7 guest compatibility virt 1083059 "Instance types (new template handling) - adding flavours" virt Allow guest serial number to be configurable virt 1047624 [RFE] support BIOS boot device menu virt 1083129 allows setting netbios name, locale, language and keyboard settings for windows vm's virt 1038632 spice-html5 button to show debug console/output window virt 1080002 [RFE] Enable user defined Windows Sysprep file done Some more features may be included since they were near to be completed on last sync meeting. The table will be updated on next sync meeting scheduled for 2014-05-14. There are still 383 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 321 bugs [4] targeted to 3.5.0. Maintainers / Assignee: - Please remember to rebuild your packages before 2014-05-16 08:00 UTC if needed, otherwise nightly snapshot will be taken. - If you find a blocker bug please remember to add it to the tracker [1] - Please start filling release notes, the page has been created here [5] All users: - You're welcome to join us testing this alpha release and getting involved in oVirt Quality Assurance[6]! [1] http://bugzilla.redhat.com/1073943 [2] http://bit.ly/17qBn6F [3] http://red.ht/1pVEk7H [4] http://red.ht/1rLCJwF [5] http://www.ovirt.org/OVirt_3.5_Release_Notes [6] http://www.ovirt.org/OVirt_Quality_Assurance Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

improving VDSM error reporting
by Yoav Kleinberger 14 May '14

14 May '14

Hi all, This idea was born from this bug: https://bugzilla.redhat.com/730619 If, for example, creating a new storage domain fails because there's no space left, the user gets: "Error creating a storage domain" which is not very helpful, since the real problem (no space) is not reported. "Error creating a storage domain" [i] No space left on device Where [i] is some widget the user can open to see details, or other element the UX team find acceptable. Nir Soffer and I believe a good solution is the following: 1. Currently VDSM sends a dictionary {'status': {'code': code, 'message': msg}}. The code is some number that Engine recognizes and has a localized message for. The msg parameter is ignored by Engine, and contains a default, not informative, string like "Error creating a storage domain" 2. We suggest adding a new key to this dictionary, call it "details", which will contain the string representation of the actual exception thrown in Python (in this case, OSError with the string "[Errno 28] No space left on device" 3. The Engine will look for this key, and display the string inside a "details" section which will be added to the current dialog box. The user gets the usual error indication, but has a small "details" icon, which he can click to see more information. The advantages are: 1. Simple to implement 2. Will improve the situation for any error thrown from Python - the user will get a clearer message. 3. New VDSM with old Engine is not a problem, the engine will not look for this key at all 4. New Engine with old VDSM is also easy to handle: the engine will not display "details" if this key is absent. Disadvatage is that the "details" will be non-localized, but this is natural for technical details. Why not use the existing "msg" field? because a new engine with an old VDSM will display uninformative, duplicate messages for all errors (the current msg field is simply a duplicate of the engine error name). What do you think? Yoav K

4 10

[vdsm] pep8 issue
by Amador Pahim 13 May '14

13 May '14

Building vdsm/master in F20, I've got: ./vdsm/virt/migration.py:223:19: E225 missing whitespace around operator In vdsm/virt/migration.py: 223 -1, -1) # int1, int2$ pep8 is not accepting the negative integer. Instead, it is handling the minus sign as an operator. Quick workaround is change -1 to int("-1"). Is this a known issue? I'm using python-pep8-1.5.4-1.fc20.noarch -- Pahim

1 0

UI plugins :: SystemTreeSelectionChange event
by Vojtech Szocs 13 May '14

13 May '14

Hey guys, UI plugin API now supports SystemTreeSelectionChange event, which is fired whenever "System Tree" selection (currently selected tree node) is changed. Example usage: api.register({ SystemTreeSelectionChange: function(selectedNode) { // See SystemTreeItemType Java enum for all supported values var nodeType = selectedNode.type; // Defined only if selected node has an entity associated var associatedEntity = selectedNode.entity; var associatedEntityId = associatedEntity && associatedEntity.id; } }); More details in UI plugin wiki: http://www.ovirt.org/Features/UIPlugins#System_tree_node_selection Regards, Vojtech

1 0

All-in-one engine setup for 3.5
by Piotr Kliczewski 13 May '14

13 May '14

I tried to deploy all in one engine (built from master) and noticed engine setup failed with: 2014-05-13 12:42:40 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/all-in-one/vdsm.py", line 190, in _closeup **FILTERED**_api = self._waitEngineUp() File "/usr/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/all-in-one/vdsm.py", line 127, in _waitEngineUp except self._ovirtsdk_api.RequestError: AttributeError: 'module' object has no attribute 'RequestError' Can someone help me to understand how to fix this issue? Thanks, Piotr

1 1

Building log collector rpm
by Piotr Kliczewski 13 May '14

13 May '14

I want to build log collector rpm and noticed that is failing due to: + /usr/lib/rpm/redhat/brp-java-repack-jars Processing files: ovirt-log-collector-3.5.0-0.0.master.fc19.noarch error: File not found by glob: /home/pkliczewski/rpmbuild/BUILDROOT/ovirt-log-collector-3.5.0-0.0.master.fc19.x86_64/usr/lib/python2.7/site-packages/sos/plugins/*.py* I pulled the code from master few minutes ago. Can someone help to solve this issue? Thanks, Piotr

2 8

New repos request
by Sandro Bonazzola 13 May '14

13 May '14

Hi, can you please create the following repositories? ovirt-setup: will have ovirt-engine-setup python sources currently shipped within ovirt-engine in packaging/setup. Since it will be able to install dwh / reports / websocket on host where ovirt-engine is not installed I think that calling it ovirt-engine-setup doesn't make much sense. ovirt-lib-python: will have python common libraries currently shipped within ovirt-engine in packaging/pythonlib. python suffix is used following http://fedoraproject.org/wiki/Packaging:NamingGuidelines Comments are welcome. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Ovirt-jenkins-question] How to re-trigger the failed gerrit-triggered jobs
by Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) 13 May '14

13 May '14

Hi all, There is a findbugs build failure as below. But I checked the Jenkins console log of that job; it seems the failure is not caused by my code. I have rerun the job and it passed. My question is how can I re-trigger the failed Jenkins job and let it removed the "-1" review score on the gerrit. 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 -----Original Message----- From: oVirt Jenkins CI Server [mailto:gerrit2@gerrit.ovirt.org] Sent: Tuesday, May 13, 2014 5:21 AM To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Cc: Gilad Chaplik; automation(a)ovirt.org; Doron Fediuck; Roy Golan; Eli Mesika; Omer Frenkel; Arik Hadas; Martin Sivák; Eli Mesika; Jiří Moskovčák; Kobi Ianko; Vitor de Lima; Leonardo Bianconi; Gustavo Frederico Temple Pedrosa Subject: Change in ovirt-engine[master]: engine: Numa feature entities oVirt Jenkins CI Server has posted comments on this change. Change subject: engine: Numa feature entities ...................................................................... Patch Set 29: Code-Review-1 Verified-1 Build Unstable http://jenkins.ovirt.org/job/ovirt-engine_master_unit-tests_gerrit/7636/ : SUCCESS http://jenkins.ovirt.org/job/ovirt-engine_master_dao_unit_tests_gerrit/2253/ : SUCCESS http://jenkins.ovirt.org/job/ovirt-engine_master_find-bugs_gerrit/6944/ : The patch does not pass the findbugs http://jenkins.ovirt.org/job/ovirt_engine_master_compile_checkstyle_gerrit/… : SUCCESS -- To view, visit http://gerrit.ovirt.org/23702 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifefade432e7955503980bdc6fc5d73ea32818a95 Gerrit-PatchSet: 29 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Xiaolei Shi <xiao-lei.shi(a)hp.com> Gerrit-Reviewer: Arik Hadas <ahadas(a)redhat.com> Gerrit-Reviewer: Doron Fediuck <dfediuck(a)redhat.com> Gerrit-Reviewer: Eli Mesika <elimesika(a)gmail.com> Gerrit-Reviewer: Eli Mesika <emesika(a)redhat.com> Gerrit-Reviewer: Gilad Chaplik <gchaplik(a)redhat.com> Gerrit-Reviewer: Gustavo Frederico Temple Pedrosa <gustavo.pedrosa(a)eldorado.org.br> Gerrit-Reviewer: Jiří Moskovčák <jmoskovc(a)redhat.com> Gerrit-Reviewer: Kobi Ianko <kobi(a)redhat.com> Gerrit-Reviewer: Leonardo Bianconi <leonardo.bianconi(a)eldorado.org.br> Gerrit-Reviewer: Martin Sivák <msivak(a)redhat.com> Gerrit-Reviewer: Omer Frenkel <ofrenkel(a)redhat.com> Gerrit-Reviewer: Roy Golan <rgolan(a)redhat.com> Gerrit-Reviewer: Vitor de Lima <vitor.lima(a)eldorado.org.br> Gerrit-Reviewer: Xiaolei Shi <xiao-lei.shi(a)hp.com> Gerrit-Reviewer: automation(a)ovirt.org Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: No

2 1

Help debugging engine.log
by Sandro Bonazzola 12 May '14

12 May '14

the following lines appear after adding the first host to an engine running inside Hosted Engine VM. Can anybody tell what the following lines are meaning? 2014-04-18 17:21:57,223 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (pool-4-thread-5) [751509c7] FINISH, SetVdsStatusVDSCommand, log id: 6bb07f05 2014-04-18 17:21:57,223 INFO [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-4-thread-5) [751509c7] After Installation host hosted_engine_1, VDS 2014-04-18 17:21:57,243 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (pool-4-thread-5) [751509c7] Correlation ID: 751509c7, Job ID: c7abd67c-5655-4ea8-8226-c51eda9c9675, Call Stac k: null, Custom Event ID: -1, Message: Host hosted_engine_1 installed 2014-04-18 17:21:57,255 INFO [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-4-thread-5) [751509c7] Lock freed to object EngineLock [exclusiveLocks= key: f609e5f8-1676-4e87-98ec-9477afc27557 value: VDS , sharedLocks= ] 2014-04-18 17:21:58,764 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-3) START, GetHardwareInfoVDSCommand(HostName = hosted_engine_1, HostId = f609e5f 8-1676-4e87-98ec-9477afc27557, vds=Host[hosted_engine_1]), log id: 496d80d8 2014-04-18 17:21:58,834 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-3) FINISH, GetHardwareInfoVDSCommand, log id: 496d80d8 2014-04-18 17:21:58,944 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-3) START, GetHardwareInfoVDSCommand(HostName = hosted_engine_1, HostId = f609e5f8-1676-4e87-98ec-9477afc27557, vds=Host[hosted_engine_1]), log id: 36957393 2014-04-18 17:21:58,971 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-3) FINISH, GetHardwareInfoVDSCommand, log id: 36957393 2014-04-18 17:21:58,989 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-3) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: State was set to Up for host hosted_engine_1. 2014-04-18 17:21:59,058 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-3) START, FullListVdsCommand(HostName = hosted_engine_1, HostId = f609e5f8-1676-4e87-98ec-9477afc27557, vds=Host[hosted_engine_1], vmIds=[950f8a3a-82af-478e-8f99-9cd0556b9cfc]), log id: 16b792bc 2014-04-18 17:21:59,095 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-3) FINISH, FullListVdsCommand, return: [Ljava.util.HashMap;@3a6e1bc2, log id: 16b792bc 2014-04-18 17:21:59,096 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-3) Importing VM HostedEngine as HostedEngine, as it is running on the on Host, but does not exist in the engine. 2014-04-18 17:21:59,122 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-3) VDS::UpdateVmRunTimeInfo Error: found VM on a VDS that is not in the database! 2014-04-18 17:21:59,137 INFO [org.ovirt.engine.core.bll.InitVdsOnUpCommand] (DefaultQuartzScheduler_Worker-3) [3a5f7d19] Running command: InitVdsOnUpCommand internal: true. Entities affected : ID: 5849b030-626e-47cb-ad90-3ce782d831b3 Type: StoragePool 2014-04-18 17:21:59,144 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetMOMPolicyParametersVDSCommand] (DefaultQuartzScheduler_Worker-3) [3a5f7d19] START, SetMOMPolicyParametersVDSCommand(HostName = hosted_engine_1, HostId = f609e5f8-1676-4e87-98ec-9477afc27557), log id: 36c8962e 2014-04-18 17:21:59,223 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetMOMPolicyParametersVDSCommand] (DefaultQuartzScheduler_Worker-3) [3a5f7d19] FINISH, SetMOMPolicyParametersVDSCommand, log id: 36c8962e 2014-04-18 17:21:59,228 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-3) [3a5f7d19] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Failed to verify Power Management configuration for Host hosted_engine_1. 2014-04-18 17:21:59,389 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (DefaultQuartzScheduler_Worker-3) [266af7f3] Lock Acquired to object EngineLock [exclusiveLocks= key: HostedEngine value: VM_NAME , sharedLocks= ] 2014-04-18 17:21:59,453 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (DefaultQuartzScheduler_Worker-3) [266af7f3] Running command: AddVmFromScratchCommand internal: true. Entities affected : ID: 99408929-82cf-4dc7-a532-9d998063fa95 Type: VdsGroups 2014-04-18 17:21:59,707 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-3) [266af7f3] Correlation ID: 266af7f3, Job ID: 2c46a619-bc01-4b85-96bd-d3fc5e073901, Call Stack: null, Custom Event ID: -1, Message: VM HostedEngine was created by <UNKNOWN>. 2014-04-18 17:21:59,714 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (DefaultQuartzScheduler_Worker-3) [266af7f3] Lock freed to object EngineLock [exclusiveLocks= key: HostedEngine value: VM_NAME , sharedLocks= ] 2014-04-18 17:21:59,718 INFO [org.ovirt.engine.core.bll.HandleVdsCpuFlagsOrClusterChangedCommand] (DefaultQuartzScheduler_Worker-3) [5e0dc4d1] Running command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entities affected : ID: f609e5f8-1676-4e87-98ec-9477afc27557 Type: VDS 2014-04-18 17:21:59,766 INFO [org.ovirt.engine.core.bll.UpdateVdsGroupCommand] (DefaultQuartzScheduler_Worker-3) [32fd282a] Running command: UpdateVdsGroupCommand internal: true. Entities affected : ID: 99408929-82cf-4dc7-a532-9d998063fa95 Type: VdsGroups 2014-04-18 17:22:00,015 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-3) [32fd282a] Correlation ID: 32fd282a, Call Stack: null, Custom Event ID: -1, Message: Host cluster Default was updated by system 2014-04-18 17:22:00,032 INFO [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (DefaultQuartzScheduler_Worker-3) [4f38fad3] Running command: HandleVdsVersionCommand internal: true. Entities affected : ID: f609e5f8-1676-4e87-98ec-9477afc27557 Type: VDS 2014-04-18 17:22:03,100 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-6) START, FullListVdsCommand(HostName = hosted_engine_1, HostId = f609e5f8-1676-4e87-98ec-9477afc27557, vds=Host[hosted_engine_1], vmIds=[950f8a3a-82af-478e-8f99-9cd0556b9cfc]), log id: 4148c04c 2014-04-18 17:22:03,129 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-6) FINISH, FullListVdsCommand, return: [Ljava.util.HashMap;@5f864ed0, log id: 4148c04c 2014-04-18 17:22:03,131 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-6) Received a console Device without an address when processing VM 950f8a3a-82af-478e-8f99-9cd0556b9cfc devices, skipping device: {alias=console0, specParams={}, device=console, type=console, deviceId=c627f372-2893-4b79-b534-f51c86374d1b} 2014-04-18 17:22:03,131 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-6) Received a memballoon Device without an address when processing VM 950f8a3a-82af-478e-8f99-9cd0556b9cfc devices, skipping device: {alias=balloon0, specParams={model=none}, device=memballoon, type=balloon} 2014-04-18 17:22:03,132 ERROR [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-6) Empty or NULL values were passed for a VM 950f8a3a-82af-478e-8f99-9cd0556b9cfc device, Device is skipped 2014-04-18 17:53:16,713 INFO [org.ovirt.engine.core.bll.LogoutUserCommand] (ajp-/127.0.0.1:8702-5) [3829e38e] Running command: LogoutUserCommand internal: false. 2014-04-18 17:53:16,725 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-5) [3829e38e] Correlation ID: 3829e38e, Call Stack: null, Custom Event ID: -1, Message: User admin@internal logged out. 2014-04-18 17:54:28,145 INFO [org.ovirt.engine.core.bll.LoginAdminUserCommand] (ajp-/127.0.0.1:8702-4) Running command: LoginAdminUserCommand internal: false. 2014-04-18 17:54:28,149 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-4) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal logged in. 2014-04-18 17:54:28,207 INFO [org.ovirt.engine.core.bll.LoginUserCommand] (ajp-/127.0.0.1:8702-8) Running command: LoginUserCommand internal: false. 2014-04-18 17:54:28,212 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-8) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal logged in. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 6