- Devel - oVirt List Archives

new build parameter for GWT CSS debugging
by Greg Sheremeta 29 May '14

29 May '14

Hi, We added a new build parameter called gwt.cssResourceStyle that can tell the GWT compiler to not obfuscate the names of CSS classes in its output. This is tremendously helpful when debugging CSS issues. In Firebug or similar, you'll see '<div class="GL1HI05BCHD-org-ovirt-engine-ui-common-widget-table-SimpleActionTable_WidgetUiBinderImpl_GenCss_style-headerContainer" ...' instead of just '<div class="GL1HI05BKOD" ...'. so you can see that you need to look for 'headerContainer' to modify this div. To use the new option, pass '-Dgwt.cssResourceStyle=pretty' to DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS. I use a bash alias like so: alias ovirt_build='make clean install-dev PREFIX=$HOME/ovirt-engine DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS=" -Dgwt.cssResourceStyle=pretty -Dgwt.userAgent=gecko1_8,safari"' gwt.cssResourceStyle will default to the GWT default, obf ('obfuscated'), if you don't include this extra parameter. Enjoy. Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

1 0

oVirt 3.5.0 release schedule updated
by Sandro Bonazzola 29 May '14

29 May '14

Here is the updated schedule for oVirt 3.5.0. These are tentative planning dates and may change: General availability: 2014-08-04 (Mon) oVirt 3.5 Second Test Day: 2014-07-22 (Tue) RC Build: 2014-07-16 (Wed) oVirt 3.5 First Test Day: 2014-07-01 (Tue) Branching - Beta release: 2014-06-26 (Thu) Feature freeze: 2014-06-15 (Sun) Second Alpha release: 2014-06-05 (Thu) Release management page has been updated accordingly: http://www.ovirt.org/OVirt_3.5_release-management oVirt Google Calendar has been updated accordingly: ICAL: https://www.google.com/calendar/ical/ppqtk46u9cglj7l987ruo2l0f8%40group.cal… XML: https://www.google.com/calendar/feeds/ppqtk46u9cglj7l987ruo2l0f8%40group.ca… HTML: https://www.google.com/calendar/embed?src=ppqtk46u9cglj7l987ruo2l0f8%40grou… Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

3.5 Time-frame: pushing feature freeze
by Doron Fediuck 29 May '14

29 May '14

Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work. Therefore I suggest to set an updated FF milestone for June 15. If you need more time or think we should not change the current date please respond. Thanks, Doron [1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt

4 10

[vdsm] VM volume chain information in getVMList API
by Adam Litke 29 May '14

29 May '14

For Live Merge, engine needs a way to get a list of volume UUIDs that comprise the volume chain for a given VM disk. Initially, we created a new verb getVolumeChain(vm, driveSpec) that would return a list of VM uuids. In the interest of preventing API bloat I would prefer to use the 'volumeChain' list in VmDiskDevice which is retrieved from the getVMList public API. Federico mentioned that this info may have been exposed by accident at one point and I agree that things like volume paths should not be used and should possibly be removed from this structure. That being said, we have a real use case for using the volume UUIDs and that should be quite safe. Do you agree with my assessment or should I continue with the getVolumeChain verb which does nothing more than: return [x['volumeID'] for x in vmDrive['volumeChain']] -- Adam Litke

3 4

[QE][ACTION NEEDED] oVirt 3.5.0 Second Alpha status
by Sandro Bonazzola 29 May '14

29 May '14

Hi, We're preparing for feature freeze scheduled for 2014-05-30. We're going to compose a Second Alpha on Firday *2014-05-30 08:00 UTC*. Maintainers: - Please be sure that master snapshot allow to create VMs before *2014-05-29 15:00 UTC* 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 1100236 integration NEW all-in-one setup should configure cluster compatibility as max common between vdsm and engine 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 1078738 [RFE] make ovirt easy configurable to allow redirection of all logs to syslog 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 1090800 [RFE] Add periodic power management health check to detect/warn about link-down detection of power management LAN 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 1058737 [RFE] Restart HA VMs ASAP infra-api 1090797 [RFE] RESTAPI: Add /tags sub-collection for Template resource infra-dwh 1091686 prevent OutOfMemoryError after starting the dwh service. infra-dwh 1091687 History DB should sync user's first and last name for user usage tables network 1078836 Add a warning when adding display network network 1079719 Display of NIC Slave/Bond fault on Event Log network 1080984 Support bridging_opts functionality within oVirt network 1080987 Support ethtool_opts functionality within oVirt network 1078862 Providing Neutron Applience storage Store OVF on any domains storage 1083312 Disk alias recycling in web-admin portal storage 1086181 [RFE] Snapshot overview in webadmin 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 1073453 Debian 7 support (incl. 1043474 oVirt guest agent for Debian) virt 1072313 Edit Running Vm virt 1083049 add progress bar for vm migration virt 1083065 EL 7 guest compatibility 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 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-28. There are still 377 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 314 bugs [4] targeted to 3.5.0. Maintainers / Assignee: - Please remember to rebuild your packages before *2014-05-29 15:00 UTC* if needed, otherwise nightly snapshot will be taken. - Please be sure that master snapshot allow to create VMs before *2014-05-29 15:00 UTC* - 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] - Please review and add test cases to oVirt 3.5 Test Day [6] Community: - You're welcome to join us testing this alpha release and getting involved in oVirt Quality Assurance[7]! [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_3.5_TestDay [7] 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

2 2

Re: [ovirt-devel] discussion: URI format for libvirt metadata
by Kobi Ianko 28 May '14

28 May '14

The URL that we will go with is "http://ovirt.org/vm/tune". The address is self explainable, it will contain vm tunable parameters and refer to a web page explaining the parameters. 10x. > > ----- Forwarded Message ----- > > > From: "Dan Kenigsberg" <danken(a)redhat.com> > > > To: "Kobi Ianko" <kobi(a)redhat.com> > > > Cc: devel(a)ovirt.org > > > Sent: Wednesday, May 28, 2014 2:16:43 AM > > > Subject: Re: [ovirt-devel] discussion: URI format for libvirt metadata > > > > > > On Tue, May 27, 2014 at 01:10:22PM -0400, Kobi Ianko wrote: > > > > Hi All, > > > > In the upcoming changes we have decided to use the Metadata section of > > > > libvirt to store temporary data. (see > > > > http://libvirt.org/html/libvirt-libvirt.html#virDomainGetMetadata) > > > > For that the libvirt api forces us to specify a valid URI. > > > > > > > > I have suggested using the following pattern: > > > > "http://ovirt.org/param/param_name" > > > > > > > > pro: it's very simple and straightforward. > > > > con: it leads to nowhere and I don't think we should create a web > > > > reference > > > > for each param. > > > > > > > > I would like to hear other suggestions from you all > > > > > > According to > > > http://libvirt.org/html/libvirt-libvirt.html#virDomainSetMetadata > > > """ > > > ... VIR_DOMAIN_METADATA_ELEMENT @metadata must be well-formed XML > > > belonging > > > to namespace defined by @uri with local name @key. > > > """ > > > so there is no doubt that we must have a properly-defined namespace on > > > the > > > URI. > > > > > > Beyond that, lacking a wiki page explaining the the key, means that a > > > reviewer knows nothing about what is this param, what are its valid > > > values, or how oVirt is using it. > > > > > > Nothing makes sure that no one else in oVirt decides to use the > > > same param for something else. > > > > > > It is important to explain that the params that you suggest are going to > > > be used for communication beween Vdsm and MoM, and that this param is a > > > vm-specific entity. http://ovirt.org/param/name seems like a parameter > > > of ovirt at large, not the CPU of a particular VM. > > > > > > Regards, > > > Dan. > > > _______________________________________________ > > > Devel mailing list > > > Devel(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > >

3 4

oVirt 3.4.2 branching
by Sandro Bonazzola 28 May '14

28 May '14

Hi, we're going to create ovirt-engine-3.4.2 branch tomorrow morning 08:00 UTC in order to allow 3.4.3 development starting on 3.4 branch while we prepare for 3.4.2 GA release. So starting tomorrow morning, if you have patches targeted to 3.4.2 you'll need to push them on 3.4.2 branch too. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

[QE][ACTION NEEDED] oVirt 3.4.2 status
by Sandro Bonazzola 28 May '14

28 May '14

Hi, We're going to start composing oVirt 3.4.2 GA on *2014-06-10 08:00 UTC* from 3.4.2 branches. The bug tracker [1] shows no blocking bugs for the release There are still 58 bugs [2] targeted to 3.4.2. Excluding node and documentation bugs we still have 27 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. Critical bugs will be re-targeted to 3.4.3 after 3.4.2 GA release. All remaining bugs will be re-targeted to 3.5.0. - Please fill release notes, the page has been created here [4] - Please build packages before *2014-06-09 15:00 UTC*. Community: - If you're testing oVirt 3.4.2 RC, 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

Discussion VM CPU pinning and NUMA CPU pinning
by Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) 28 May '14

28 May '14

--_000_B63C858E777679458338A30A991BB5240163BDA8G2W2441americas_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Now we are working on the NUMA tune feature development for oVirt 3.5. This= feature allow user to configure the vCPU pining according to host CPU/NUMA= topology to get the best performance for created VM. But this will impact = the current function of vCPU pining. Now, we are looking for a solution to = consolidate the conflict. We want to start an open discussion about VM CPU = pinning (the current design) and NUMA CPU pining (new feature we are workin= g on) in developer list: Background: Concept: 1. VM CPU pinning: the exist feature in current oVirt, which allow use= r to configure the VM vCPU pinning over ovirt, user can configure vCPU pini= ng independently without NUMA tune. 2. NUMA CPU pinning: allow user to configure the vCPU pining according= to host NUMA topology to get the best performance for created VM 3. vNode: Virtual NUMA node ( User configured ) 4. pNode: host physical NUMA node ( Get capability from host ) Notice: 1. NUMA tuning feature and CPU pinning feature are individually in lib= virt ( ovirt backend ). 2. User could configure VM CPU pining individually without NUMA tune s= etup. 3. When configuring NUMA tuning feature, user need to configure VM NUM= A tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA incl= uded ) to get optimized VM performance, otherwise VM will have low performa= nce. We have two proposal now for this issue. Please give us some comments and y= our feedback, thanks. Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used i= n NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field = of VM. Restful: Transform between the CPU pinning text and a structure which will be used i= n restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of V= M. Broker: Remove temporary solution(See the current implementation as below) and foll= ow previous cpupin configuration procedure. Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU pinning co= nfigure page, he will get a warning message. If he continues to configure N= UMA CPU pinning and save the data, the current VM CPU pinning configura= tion will be cleared. NUMA CPU pinning configured data will be saved as new structure individuall= y without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pin= ning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If= it's not configured, it will use the current VM CPU pinning. Solution 1 The CPU pining data is consistent but the code logic is very com= plex. Solution 2 have better adaptive and better data structure. This is the way = we preferred. We are appreciated that anybody could give us your comments or the better s= olution you have. The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string pro= perty. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove= pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node = index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store procedure. Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node = entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node enti= ties ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode. Best Regards, Jason Liao --_000_B63C858E777679458338A30A991BB5240163BDA8G2W2441americas_ Content-Type: text/html; charset="iso-8859-1" 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=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"ZH-CN" link=3D"#0563C1" vlink=3D"#954F72" style=3D"text-justi= fy-trim:punctuation"> <div class=3D"WordSection1"> Hi All,<o:p></o:p> <o:p> </o:p> Now we are working on the NUMA tune= feature development for oVirt 3.5. This feature allow user to configure th= e vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function= of vCPU pining. Now, we are looking for a solution to consolidate the conf= lict. We want to start an open discussion about VM CPU pinning (the current= design) and NUMA CPU pining (new feature we are working on) in developer list:<o:p></o:p> <o:p> </o:p> Background:<o:p></o:p> Concept:<o:p></o:p> <![if !supportLists]>1.<sp= an style=3D"font:7.0pt "Times New Roman"">   &nbsp= ;  <![endif]>VM CPU pinning: the exist f= eature in current oVirt, which allow user to configure the VM vCPU pinning = over ovirt, user can configure vCPU pining independently without NUMA tune.<o:p></o:p> <![if !supportLists]>2.<sp= an style=3D"font:7.0pt "Times New Roman"">   &nbsp= ;  <![endif]>NUMA CPU pinning: allow use= r to configure the vCPU pining according to host NUMA topology to get the b= est performance for created VM<o:p></o:p> <![if !supportLists]>3.<sp= an style=3D"font:7.0pt "Times New Roman"">   &nbsp= ;  <![endif]>vNode: Virtual NUMA node ( = User configured )<o:p></o:p> <![if !supportLists]>4.<sp= an style=3D"font:7.0pt "Times New Roman"">   &nbsp= ;  <![endif]>pNode: host physical NUMA n= ode ( Get capability from host )<o:p></o:p> Notice:<o:p></o:p> <![if !supportLists]>1= .   &= nbsp;  <![endif]>NUMA tuning feature and= CPU pinning feature are individually in libvirt ( ovirt backend ).<o:p></o= :p> <![if !supportLists]>2= .   &= nbsp;  <![endif]>User could configure VM= CPU pining individually without NUMA tune setup.<o:p></o:p> <![if !supportLists]>3= .   &= nbsp;  <![endif]>When configuring NUMA t= uning feature, user need to configure VM NUMA tuning ( vNode pinto pNode &a= mp; tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM = performance, otherwise VM will have low performance.<o:p></o:p> <o:p> </o:p> We have two proposal now for this i= ssue. Please give us some comments and your feedback, thanks.<o:p></o:p></s= pan> <o:p> </o:p> Solution 1:<o:p></o:p>      &nbsp= ;   GUI: <o:p></o:p> Transf= orm between the CPU pinning text and a structure which will be used in NUMA= CPU pinning configure page.<o:p></o:p>     And then save th= e CPU pinning text to the current VM CPU pinning field of VM. <o:p></o:p>      &nbsp= ;   Restful: <o:p></o:p> Transf= orm between the CPU pinning text and a structure which will be used in rest= ful NUMA CPU pinning.<o:p></o:p> And th= en save the CPU pinning text to the current VM CPU pinning field of VM.<o:p= ></o:p>      &nbsp= ;   Broker: <o:p></o:p> Remove= temporary solution(See the current implementation as below) and follow pre= vious cpupin configuration procedure.<o:p></o:p> <o:p> </o:p> Solution 2:<o:p></o:p>      &nbsp= ;   GUI: <o:p></o:p> If cur= rent VM CPU pinning is configured, when user open NUMA CPU pinning configur= e page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning  &nbsp= ;  configuration will be cleared.<o:p></o:p> NUMA C= PU pinning configured data will be saved as new structure individually with= out changing current VM CPU pinning configuration.<o:p></o:p>      &nbsp= ;   Restful: <o:p></o:p> Config= ure NUMA CPU pinning and then save the data with the new NUMA CPU pinning s= tructure. <o:p></o:p>      &nbsp= ;   Entity and Database: <o:p></o:p> Indivi= dually NUMA CPU pinning entities and data structure.<o:p></o:p>      &nbsp= ;   Broker: <o:p></o:p>    &nb= sp;     NUMA CPU pinning configuration will be first consid= ered to use. If it’s not configured, it will use the current VM CPU p= inning.<o:p></o:p> <o:p> </o:p> Solution 1 The CPU pining data is c= onsistent but the code logic is very complex.<o:p></o:p> Solution 2 have better adaptive and= better data structure. This is the way we preferred.<o:p></o:p> <o:p> </o:p> We are appreciated that anybody cou= ld give us your comments or the better solution you have.<o:p></o:p>= <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> The below is the current implementa= tion for your reference:<o:p></o:p> VM CPU pinning feature<o:p></o:p></= span>      &nbsp= ;   GUI: <o:p></o:p> User i= nput vCPU pining configure data with formatted text.<o:p></o:p>      &nbsp= ;   Restful: <o:p></o:p> User c= onfigure CpuTune and VCpuPin model with mapper to CPU pinning text.<o:p></o= :p>      &nbsp= ;   Entity and Database: <o:p></o:p> CPU pi= nning is String property.<o:p></o:p>      &nbsp= ;   Broker: <o:p></o:p> Genera= te structure of cputune ( libvirt format ) from CPU pining string property.= <o:p></o:p> NUMA tuning feature<o:p></o:p></spa= n>      &nbsp= ;   GUI: <o:p></o:p> User c= an drag & drop virtual NUMA node to host NUMA node ( pin to or remove p= in to ).<o:p></o:p>      &nbsp= ;   Restful: <o:p></o:p> Add/up= date/remove virtual NUMA node with property of pin to host NUMA node index.= <o:p></o:p>      &nbsp= ;   Design NUMACPU model under NUMA node for extend.<o:p></o:p></= span>      &nbsp= ;   Entity and Database: <o:p></o:p> Indivi= dually NUMA node entities ( vNode extend pNode ) and store procedure.<o:p><= /o:p>      &nbsp= ;   Broker: <o:p></o:p> Genera= te structure of numatune, cpu/numa ( libvirt format ) from NUMA node entiti= es.<o:p></o:p> Temporary solution prevent Notice 3= <o:p></o:p>      &nbsp= ;   Broker: <o:p></o:p> Genera= te right structure of cputune ( libivirt format ) from NUMA node entities (= vNode pinto pNode )<o:p></o:p>      &nbsp= ;   Limitation: <o:p></o:p> This s= tructure of cputune will not get the best performance of vNode.<o:p></o:p><= /span> <o:p> </o:p> Best= Regards, Jason Liao= <o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_B63C858E777679458338A30A991BB5240163BDA8G2W2441americas_--

4 13

discussion: URI format for libvirt metadata
by Kobi Ianko 28 May '14

28 May '14

Hi All, In the upcoming changes we have decided to use the Metadata section of libvirt to store temporary data. (see http://libvirt.org/html/libvirt-libvirt.html#virDomainGetMetadata) For that the libvirt api forces us to specify a valid URI. I have suggested using the following pattern: "http://ovirt.org/param/param_name" pro: it's very simple and straightforward. con: it leads to nowhere and I don't think we should create a web reference for each param. I would like to hear other suggestions from you all 10x, Kobi.

2 1