July 2014 - Users - oVirt List Archives

[Community] Building an oVirt Commercial Directory
by Brian Proffitt 29 Jul '14

29 Jul '14

All: In order to promote the oVirt project, we would like to create a directory of companies that provide solutions and commercial support based on oVirt on oVirt.org. Specifically, we are looking for organizations that provide: - Commercial product/support based on oVirt - oVirt professional services/support - Vendors leveraging or embedding ovirt - Cloud providers using oVirt technologies Vendors and providers can send the following data: Name of Company Company Website URL Preferred Contact Info Location/Region Served Active oVirt Contributor(s)? [Yes/No] Please send this information to me at bkp(a)redhat.org, with oVirt Solutions Directory in the subject line if interested in participating. Thanks! 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 1

Misc architecture questions
by Maël Lavault 29 Jul '14

29 Jul '14

Hi, I'm a student currently doing my final study project based around Ovirt. I played a lot with Ovirt to have an overview of what could or could not be done, but I still have a few questions and stuff I want to clarify. My project consist of a HA architecture using Ovirt, powered by 8 reasonably powerful servers (4 x Quad core Opteron, 32Go RAM, 2x10k RPM HDD) equipped with 2 NIC each. I followed this tutorial to use Ovirt with GlusterFS : http://community.redhat.com/blog/2014/05/ovirt-3-4-glusterized/ Worked well ! I installed 2 self hosted engine on 2 different servers and a GlusterFS using 2 other servers. But since we had only 2 x 1Gb NIC per server, we decided to go with bonding and VLAN to separate each networks inspired by this blog post : http://captainkvm.com/2013/04/maximizing-your-10gb-ethernet-in-rhev/ Unfortunately, it seems like Ovirt 3.4 does not support installing self-hosted engine on bond + vlan. I tried 3.5 but there were to much bug to be usable and the project is set to be deployed in 2 months. A colleague suggested me a workaround using OpenvSwitch between Ovirt and NIC bond to "translate tagged packet into non tagged packet" and hide the bond from Ovirt. Does this have a chance to work ? Since the GlusterFS is accessed by NFS, I was able to bond the two servers. A few questions : - What is the purpose of ovirtmgmt network ? I did a lot of search by haven't found any clear explanation. Does it need to be publicly accessible or a private ip is fine too ? - Is the display network used for SPICE/VNC connection ? - How do Ovirt differentiate VM network from a storage network ? They both have the same vm role in the interface. Both networks could (should) be on private ip range right ? - How can I add the storage network after (or before, would be better) self hosted engine is installed ? (Since self hosted engine is stored on Gluster, I will loose connection to the engine) - Using self hosted engine, does all my nodes need to be installed with hosted-engine --deploy, or can I have only 2 self hosted engine nodes and 4 classic nodes ? - I'm trying to cleanly re-install the second hosted engine after some experiments, but the behavior is strange : [ INFO ] Stage: Transaction commit [ INFO ] Stage: Closing up To continue make a selection from the options below: (1) Continue setup - engine installation is complete (2) Power off and restart the VM (3) Abort setup Isn't this supposed to give me information to connect to the vm so i can install the engine ? Thanks a lot for this truly well made software !

4 6

oVirt 3.5 2nd test day report - neutron appliance
by Oved Ourfali 29 Jul '14

29 Jul '14

Hi I tested the neutron appliance in this test day. Feature page is in http://www.ovirt.org/Features/NeutronVirtualAppliance Overall environment: Engine - F19 VM Hosts - two Centos 6.5 hosts with 2 nics, using nested virtualization Tests: 1. Followed the wiki to import the appliance from the public glance repository and run a VM with that appliance • Had some comments on the wiki that were addressed instantly by Moti 2. Checked both network provisioning, and network import 3. Checked host installation with the neutron plugin, using OVS 4. Imported the Cirros image from the public glance repository, to be used in order to create VMs and check connectivity between them 5. The two VMs had connectivity on the created subnet, both when using the provisioned network, and the imported one. Tested both when running both VMs on the same host, and on two different hosts. Overall it worked pretty great. Opened three bugs on UI/Flow issues: Bug 1124294 - reinstall host dialog - neutron - UI issue (network) Bug 1124298 - cloud-init network start on boot checkbox goes down one line (virt) Bug 1124304 - import networks dialog is confusing (network) Thanks, Oved

1 0

[ANN] oVirt 3.5 Second Test Day - Today Jul 29th
by Sandro Bonazzola 29 Jul '14

29 Jul '14

Hi all, Today Jul 29th we'll have oVirt 3.5.0 second test day. On this day all relevant engineers will be online ready to support any issues you find during install / operating this new release. Just make sure you have 1 host or more to test drive the new release. If you're curious to see how it works, this is your chance. Thanks again for everyone who will join us today! Location #ovirt irc channel Please communicate here to allow others to see any issues What In this test day you have a license to kill ;) Follow the documentation to setup your environment, and test drive the new features. Please remember we expect to see some issues, and anything you come up with will save you when you'll install final release Remember to try daily tasks you'd usually do in the engine, to see there are no regressions. Write down the configuration you used (HW, console, etc) in the report etherpad[1]. Documentation Release notes: http://www.ovirt.org/OVirt_3.5_Release_Notes Features pages links: http://bit.ly/17qBn6F If you find errors in the wiki please annotate it as well in report etherpad [1] Prerequisites / recommendations Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc). Use Fedora 19 or 20. Latest RPMs repository to be enabled for testing the release are listed in the release notes page [2]. NEW issues / reports For any new issue, please update the reports etherpad [1] Feature owners, please make sure: your feature is updated and referenced on release page [2]. you have testing instruction for your feature either on test day page [3] or in your feature page. your team regression testing section is organized and up to date on test day page [3]. [1] http://etherpad.ovirt.org/p/3.5-testday-2 [2] http://www.ovirt.org/OVirt_3.5_Release_Notes [3] http://www.ovirt.org/OVirt_3.5_TestDay Thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Setting up all-in-one
by Jaco 29 Jul '14

29 Jul '14

This is a multi-part message in MIME format. --------------010107080600070007040200 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi folks, I'm new to the project, so please pardon my ignorance. I came to oVirt by way of looking for a suitable KVM/libvirt-based IaaS stack to supersede my old Ubuntu 12.04 setup, that I've been running since KVM came to Ubuntu-town. I've looked & tried a number of solutions - Eucalyptus, Enomalism, OpenStack - but most proved too cumbersome or admin-heavy for us. A while back I set up oVirt on CentOS (whatever was stable at the time), but had to shelve the project for a while, because... reasons. Fired it back up again & did all the requisite updates/upgrades to bring the host up to snuff. Unfortunately oVirt did not work as well, so I tried removing/purging it from the host & reinstalling it - both the 3.4.* stable & 3.5 beta - but both get hit up by the same issue when running the engine-setup. Details follow - Environment: Linux $REDACTED 2.6.32-431.20.5.el6.centos.plus.x86_64 #1 SMP Fri Jul 25 07:10:09 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux CentOS release 6.5 (Final) terminal-out: [ INFO ] Starting engine service [ ERROR ] Failed to execute stage 'Closing up': Command '/sbin/service' failed to execute [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20140727140628-g0z922.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20140727141521-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed log portion corresponding to the above error: 2014-07-27 13:25:01 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/system/engine.py", line 51, in _closeup state=True, File "/usr/share/otopi/plugins/otopi/services/rhel.py", line 188, in state 'start' if state else 'stop' File "/usr/share/otopi/plugins/otopi/services/rhel.py", line 96, in _executeServiceCommand raiseOnError=raiseOnError File "/usr/lib/python2.6/site-packages/otopi/plugin.py", line 871, in execute command=args[0], RuntimeError: Command '/sbin/service' failed to execute 2014-07-27 13:25:01 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Closing up': Command '/sbin/service' failed to execute & 2014-07-27 17:40:58 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:866 execute-output: ('/sbin/service', 'ovirt-engine', 'start') stderr: 2014-07-27 17:40:58 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/system/engine.py", line 57, in _closeup state=True, File "/usr/share/otopi/plugins/otopi/services/rhel.py", line 188, in state 'start' if state else 'stop' File "/usr/share/otopi/plugins/otopi/services/rhel.py", line 96, in _executeServiceCommand raiseOnError=raiseOnError File "/usr/lib/python2.6/site-packages/otopi/plugin.py", line 871, in execute command=args[0], RuntimeError: Command '/sbin/service' failed to execute 2014-07-27 17:40:58 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Closing up': Command '/sbin/service' failed to execute 2014-07-27 17:40:58 DEBUG otopi.context context.dumpEnvironment:468 ENVIRONMENT DUMP - BEGIN 2014-07-27 17:40:58 DEBUG otopi.context context.dumpEnvironment:478 ENV BASE/error=bool:'True' 2014-07-27 17:40:58 DEBUG otopi.context context.dumpEnvironment:478 ENV BASE/exceptionInfo=list:'[(<type 'exceptions.RuntimeError'>, RuntimeError("Command '/sbin/service' failed to execute",), <traceback object at 0x27fdf80>)]' 2014-07-27 17:40:58 DEBUG otopi.context context.dumpEnvironment:482 ENVIRONMENT DUMP - END 2014-07-27 17:40:58 INFO otopi.context context.runSequence:395 Stage: Clean up 2014-07-27 17:40:58 DEBUG otopi.context context.runSequence:399 STAGE cleanup 2014-07-27 17:40:58 DEBUG otopi.context context._executeMethod:138 Stage cleanup METHOD otopi.plugins.ovirt_engine_common.base.core.misc.Plugin._cleanup I've had a dig around & from what I can tell this (possibly) related to bugs that would've been patched in the stable release (& beta?) that I've installed, but the issue persists. I'm not certain where the issue could be coming in (lower-level/OS dependency maybe?), or if I've missed something. I've flushed & reloaded the full stack already, with the same outcome. Next I'll have to wipe the OS & start again, with no guarantee this issue won't reoccur. My next step would simply be to try out the oVirt live image. Does the image provide an option to install to the host? (looking at the live node installers, it seems likely) Are these images *purely* for PoC/demo/testing (i.e. highly unstable), or would it be stable enough for in-house (Docker) prototyping before deploying to a hosted/stable/production environment? Cheers - Jaco --------------010107080600070007040200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi folks,<br> <br> I'm new to the project, so please pardon my ignorance.<br> <br> I came to oVirt by way of looking for a suitable KVM/libvirt-based IaaS stack to supersede my old Ubuntu 12.04 setup, that I've been running since KVM came to Ubuntu-town.<br> <br> I've looked & tried a number of solutions - Eucalyptus, Enomalism, OpenStack - but most proved too cumbersome or admin-heavy for us.<br> <br> A while back I set up oVirt on CentOS (whatever was stable at the time), but had to shelve the project for a while, because... reasons. Fired it back up again & did all the requisite updates/upgrades to bring the host up to snuff.<br> <br> Unfortunately oVirt did not work as well, so I tried removing/purging it from the host & reinstalling it - both the 3.4.* stable & 3.5 beta - but both get hit up by the same issue when running the engine-setup.<br> <br> Details follow -<br> <br> Environment:<br> <br> Linux $REDACTED 2.6.32-431.20.5.el6.centos.plus.x86_64 #1 SMP Fri Jul 25 07:10:09<br> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux <meta http-equiv="content-type" content="text/html; charset=utf-8"> <br> <br> CentOS release 6.5 (Final) <meta http-equiv="content-type" content="text/html; charset=utf-8"> <br> <br> terminal-out:<br> [ INFO ] Starting engine service <br> [ ERROR ] Failed to execute stage 'Closing up': Command '/sbin/service' failed to execute <br> [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20140727140628-g0z922.log <br> [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20140727141521-setup.conf' <br> [ INFO ] Stage: Pre-termination <br> [ INFO ] Stage: Termination <br> [ ERROR ] Execution of setup failed<br> <br> log portion corresponding to the above error:<br> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <pre class="bz_comment_text bz_wrap_comment_text" id="comment_text_11" style="font-size: small; font-family: monospace; white-space: pre-wrap; word-wrap: break-word; width: 50em; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2014-07-27 13:25:01 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/system/engine.py", line 51, in _closeup state=True, File "/usr/share/otopi/plugins/otopi/services/rhel.py", line 188, in state 'start' if state else 'stop' File "/usr/share/otopi/plugins/otopi/services/rhel.py", line 96, in _executeServiceCommand raiseOnError=raiseOnError File "/usr/lib/python2.6/site-packages/otopi/plugin.py", line 871, in execute command=args[0], RuntimeError: Command '/sbin/service' failed to execute 2014-07-27 13:25:01 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Closing up': Command '/sbin/service' failed to execute</pre> <br> &<br> <br> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <pre class="bz_comment_text bz_wrap_comment_text" id="comment_text_12" style="font-size: small; font-family: monospace; white-space: pre-wrap; word-wrap: break-word; width: 50em; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2014-07-27 17:40:58 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:866 execute-output: ('/sbin/service', 'ovirt-engine', 'start') stderr: 2014-07-27 17:40:58 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/system/engine.py", line 57, in _closeup state=True, File "/usr/share/otopi/plugins/otopi/services/rhel.py", line 188, in state 'start' if state else 'stop' File "/usr/share/otopi/plugins/otopi/services/rhel.py", line 96, in _executeServiceCommand raiseOnError=raiseOnError File "/usr/lib/python2.6/site-packages/otopi/plugin.py", line 871, in execute command=args[0], RuntimeError: Command '/sbin/service' failed to execute 2014-07-27 17:40:58 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Closing up': Command '/sbin/service' failed to execute 2014-07-27 17:40:58 DEBUG otopi.context context.dumpEnvironment:468 ENVIRONMENT DUMP - BEGIN 2014-07-27 17:40:58 DEBUG otopi.context context.dumpEnvironment:478 ENV BASE/error=bool:'True' 2014-07-27 17:40:58 DEBUG otopi.context context.dumpEnvironment:478 ENV BASE/exceptionInfo=list:'[(<type 'exceptions.RuntimeError'>, RuntimeError("Command '/sbin/service' failed to execute",), <traceback object at 0x27fdf80>)]' 2014-07-27 17:40:58 DEBUG otopi.context context.dumpEnvironment:482 ENVIRONMENT DUMP - END 2014-07-27 17:40:58 INFO otopi.context context.runSequence:395 Stage: Clean up 2014-07-27 17:40:58 DEBUG otopi.context context.runSequence:399 STAGE cleanup 2014-07-27 17:40:58 DEBUG otopi.context context._executeMethod:138 Stage cleanup METHOD otopi.plugins.ovirt_engine_common.base.core.misc.Plugin._cleanup</pre> <br> I've had a dig around & from what I can tell this (possibly) related to bugs that would've been patched in the stable release (& beta?) that I've installed, but the issue persists.<br> <br> I'm not certain where the issue could be coming in (lower-level/OS dependency maybe?), or if I've missed something. <br> I've flushed & reloaded the full stack already, with the same outcome. Next I'll have to wipe the OS & start again, with no guarantee this issue won't reoccur.<br> <br> My next step would simply be to try out the oVirt live image.<br> Does the image provide an option to install to the host? (looking at the live node installers, it seems likely)<br> <br> Are these images *purely* for PoC/demo/testing (i.e. highly unstable), or would it be stable enough for in-house (Docker) prototyping before deploying to a hosted/stable/production environment?<br> <br> Cheers<br> <br> - Jaco<br> </body> </html> --------------010107080600070007040200--

2 2

Test
by Maurice James 28 Jul '14

28 Jul '14

------=_Part_14041_1566191942.1406574973910 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Test ------=_Part_14041_1566191942.1406574973910 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div><span name="x">Test</span><br></div></div></body></html> ------=_Part_14041_1566191942.1406574973910--

1 0

Call for Papers Extended: KVM Forum
by Brian Proffitt 28 Jul '14

28 Jul '14

The deadline for this has been extended until July 28, 2014! ================================================================= KVM Forum 2014: Call For Participation October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany (All submissions must be received before midnight July 27, 2014) ================================================================= KVM is an industry leading open source hypervisor that provides an ideal platform for datacenter virtualization, virtual desktop infrastructure, and cloud computing. Once again, it's time to bring together the community of developers and users that define the KVM ecosystem for our annual technical conference. We will discuss the current state of affairs and plan for the future of KVM, its surrounding infrastructure, and management tools. Mark your calendar and join us in advancing KVM. http://events.linuxfoundation.org/events/kvm-forum/ Once again we are colocated with the Linux Foundation's LinuxCon Europe, CloudOpen Europe, Embedded Linux Conference (ELC) Europe, and this year, the Linux Plumbers Conference. KVM Forum attendees will be able to attend LinuxCon + CloudOpen + ELC for a discounted rate. http://events.linuxfoundation.org/events/kvm-forum/attend/register We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2014. http://events.linuxfoundation.org/cfp Suggested topics: KVM/Kernel - Scaling and optimizations - Nested virtualization - Linux kernel performance improvements - Resource management (CPU, I/O, memory) - Hardening and security - VFIO: SR-IOV, GPU, platform device assignment - Architecture ports QEMU - Management interfaces: QOM and QMP - New devices, new boards, new architectures - Scaling and optimizations - Desktop virtualization and SPICE - Virtual GPU - virtio and vhost, including non-Linux or non-virtualized uses - Hardening and security - New storage features - Live migration and fault tolerance - High availability and continuous backup - Real-time guest support - Emulation and TCG - Firmware: ACPI, UEFI, coreboot, u-Boot, etc. - Testing Management and infrastructure - Managing KVM: Libvirt, OpenStack, oVirt, etc. - Storage: glusterfs, Ceph, etc. - Software defined networking: Open vSwitch, OpenDaylight, etc. - Network Function Virtualization - Security - Provisioning - Performance tuning =============== SUBMITTING YOUR PROPOSAL =============== Abstracts due: July 27, 2014 Please submit a short abstract (~150 words) describing your presentation proposal. Slots vary in length up to 45 minutes. Also include in your proposal the proposal type -- one of: - technical talk - end-user talk Submit your proposal here: http://events.linuxfoundation.org/cfp Please only use the categories "presentation" and "panel discussion" You will receive a notification whether or not your presentation proposal was accepted by Aug 20th. Speakers will receive a complimentary pass for the event. In the instance that your submission has multiple presenters, only the primary speaker for a proposal will receive a complementary event pass. For panel discussions, all panelists will receive a complimentary event pass. TECHNICAL TALKS A good technical talk should not just report on what has happened over the last year; it should present a concrete problem and how it impacts the user and/or developer community. Whenever applicable, it should focus on the work that needs to be done or the difficulties that haven't yet been solved. Summarizing recent developments is okay but it should not be more than a small portion of the overall talk. END-USER TALKS One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user talk. As an end user, this is a unique opportunity to get your input to developers. HANDS-ON / BOF SESSIONS We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. This time can also be used for hands-on hacking sessions if you have concrete code problems to solve. These sessions will be announced during the event. If you are interested in organizing such a session, please add it to the list at http://www.linux-kvm.org/page/KVM_Forum_2014_BOF Let people you think might be interested know about it, and encourage them to add their names to the wiki page as well. Please try to add your ideas to the list before KVM Forum starts. PANEL DISCUSSIONS If you are proposing a panel discussion, please make sure that you list all of your potential panelists in your abstract. We will request full biographies if a panel is accepted. =============== HOTEL / TRAVEL =============== The KVM Forum 2014 will be held in Düsseldorf, Germany at Congress Centre Düsseldorf http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-and-travel =============== IMPORTANT DATES =============== Notification: August 20, 2014 Schedule announced: August 29, 2014 Event dates: October 14-16, 2014 Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2014 in October! -your KVM Forum 2014 Program Committee Please contact us with any questions or comments. -- 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

Adding host to upgraded 3.5 beta 2 cluster
by Nathan Stratton 28 Jul '14

28 Jul '14

Started with 3.4 setup 4 hosts, upgrade to 3.5 beta 2, things are working well except when I try to add new hosts to 3.5 cluster. Any idea how to manually fix my answers file, does not look like it got upgraded with lockspace stuff. Failed to execute stage 'Setup validation': Answer file lacks lockspace UUIDs, please use an answer file generated from the same version you are using on this additional host ><> nathan stratton | vp technology | broadsoft, inc | +1-240-404-6580 | www.broadsoft.com

1 0

el7 based node?
by Daniel Helgenberger 28 Jul '14

28 Jul '14

--=-W0C2IaA64zLSd5c7ItFG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, plans on moving forward to EL7 anytime soon (with 3.5)? Itamar wrote something like this back in April [1] but I couldt find any more info. [1] http://lists.ovirt.org/pipermail/users/2014-April/023017.html Cheers! --=20 Daniel Helgenberger=20 m box bewegtbild GmbH=20 P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19=20 D-10115 BERLIN=20 www.m-box.de www.monkeymen.tv=20 Gesch=C3=A4ftsf=C3=BChrer: Martin Retschitzegger / Michaela G=C3=B6llner Handeslregister: Amtsgericht Charlottenburg / HRB 112767=20 --=-W0C2IaA64zLSd5c7ItFG Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINtjCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4S9SMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwWtB+TXs+BJ9 3SJRaV+3uRNGJ3cUO+MTgW8+5HQXfgy19CzkDI1T1NwwICi/bo4R/mYR5FEWx91//eE0ElC/89iY 7GkL0tDasmVx4TOXnrqrsziUcxEPPqHRE8x4NhtBK7+8o0nsMIJMA1gyZ2FA5To2Ew1BBuvovvDJ +Nua3qOCNBNu+8A+eNpJlVnlu/qB7+XWaPXtUMlsIikxD+gREFVUgYE4VzBuLa2kkg0VLd09XkE2 ceRDm6YgRATuDk6ogUyX4OLxCGIJF8yi6Z37M0wemDA6Uff0EuqdwDQd5HwG/rernUjt1grLdAxq 8BwywRRg0eFHmE+ShhpyO3Fi+wIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAQ3N5zKTMSTED HGFAgd/gu91Kb8AxPHgjq+7dhf7mkCinMqqrLai2XOrz8CP63BPaAx7oGOUBI0MyASBGk5zej9L3 oHtiF2BL01m1sBnT8rQxT2CJd/+jqjUl0p2ew8T3HSyatrsooGvDwf00yCB2JHTNvtQxNO8t6x/+ 048A1Q+0i7uf0nTnyrJLjD04zhL89ytetZspltOpJVYbmwiFjq6PxsdUNthUDme/9pOLmKDnQU0p W/JEwLs2TYCBNKwdgSGAk8/z+s2SCltKIG0Uh5U6t6j7JPuwNP/znImwMrlHDJ1YpW0rkF2PGraV CgDBf9dOB+IIpnwHfIi+LD+eITCCBMowggOyoAMCAQICEQCWaWbA3qWpL+Qmn6I16DynMA0GCSqG SIb3DQEBBQUAMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYD VQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gRzIwHhcNMTMwODI3MTY1NzU4WhcN MTYwODI3MTY1NzU4WjBYMQswCQYDVQQGEwJERTEcMBoGA1UEAxMTRGFuaWVsIEhlbGdlbmJlcmdl cjErMCkGCSqGSIb3DQEJARYcZGFuaWVsLmhlbGdlbmJlcmdlckBtLWJveC5kZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAM4BQ5vPknk1OGLd1qKSUIKmQLrjccjJcYj7qtAtA+fNYKF8 9p1VY4UwiFcF9jKlmA9Q8o8tYSx16LYYFoGWokNRAeKFXZiBZiHyI0ekpEfxo8N5cTMCcxKcSYWV 8sqzmBPCoMNpmiVoC8ec8Nv5SqXH34VVtDmNLfiVlsTyomBXAJkJ2/n5XqJzPLFGWWREtPLkVVS+ u426vt/hNsQi5akNoidYeXo98JcrmeApFJ3zB2KxvMziHx8LD4q1gAl9NumtX5YLbCpdWL9AkWdX Oaro3D9zj6Q6LyGwa/UQUrZdg3BXc07hjHZn6d9vet1SzpbyqQpTzM63yXiX1meEMlMCAwEAAaOC AZEwggGNMA4GA1UdDwEB/wQEAwIFoDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUF BwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAnBgNVHREEIDAegRxk YW5pZWwuaGVsZ2VuYmVyZ2VyQG0tYm94LmRlMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20v Z3MvZ3NwZXJzb25hbHNpZ24yZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0G A1UdDgQWBBS8NFA/upd+Wipw2nj8RD/Ct+R2GTAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGws O8XuZTANBgkqhkiG9w0BAQUFAAOCAQEAXVTpu4fhOLETAW0zdbQiIwBIMZgeVNJnWV3GsMxByycU 63P+WBQTBl9qj47vHLmVdeF7MzH0QSXZSc9Tnfr6CYIImpyIZxRAGpAsWmtZf3JieRA0+j4GQJF2 zAea1NXYXoG9+ZSSZHBSxKUdrRdVdE320nuVGTT2HjEI2LEYbOvaXyi6HhpuHUiyu4LD0+RIT3fi T8jUiKKLTsApTD+Ak8SLF0IESOSA6htirv69mDDC7Klg9dT7QBPO7dpoKIUOldV3VhahndVfsDff KD7pkUUvG5XftYEQOxlWDJzuTBeqf/4hxXMtzFU9OaI6oKJjLfr6B+XBc6xwOtc/NMWmejCCBMow ggOyoAMCAQICEQCWaWbA3qWpL+Qmn6I16DynMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFs U2lnbiAyIENBIC0gRzIwHhcNMTMwODI3MTY1NzU4WhcNMTYwODI3MTY1NzU4WjBYMQswCQYDVQQG EwJERTEcMBoGA1UEAxMTRGFuaWVsIEhlbGdlbmJlcmdlcjErMCkGCSqGSIb3DQEJARYcZGFuaWVs LmhlbGdlbmJlcmdlckBtLWJveC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM4B Q5vPknk1OGLd1qKSUIKmQLrjccjJcYj7qtAtA+fNYKF89p1VY4UwiFcF9jKlmA9Q8o8tYSx16LYY FoGWokNRAeKFXZiBZiHyI0ekpEfxo8N5cTMCcxKcSYWV8sqzmBPCoMNpmiVoC8ec8Nv5SqXH34VV tDmNLfiVlsTyomBXAJkJ2/n5XqJzPLFGWWREtPLkVVS+u426vt/hNsQi5akNoidYeXo98JcrmeAp FJ3zB2KxvMziHx8LD4q1gAl9NumtX5YLbCpdWL9AkWdXOaro3D9zj6Q6LyGwa/UQUrZdg3BXc07h jHZn6d9vet1SzpbyqQpTzM63yXiX1meEMlMCAwEAAaOCAZEwggGNMA4GA1UdDwEB/wQEAwIFoDBM BgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAnBgNVHREEIDAegRxkYW5pZWwuaGVsZ2VuYmVyZ2VyQG0tYm94 LmRlMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3NwZXJzb25hbHNpZ24yZzIuY3Js MFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNv bS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0GA1UdDgQWBBS8NFA/upd+Wipw2nj8RD/C t+R2GTAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTANBgkqhkiG9w0BAQUFAAOCAQEA XVTpu4fhOLETAW0zdbQiIwBIMZgeVNJnWV3GsMxByycU63P+WBQTBl9qj47vHLmVdeF7MzH0QSXZ Sc9Tnfr6CYIImpyIZxRAGpAsWmtZf3JieRA0+j4GQJF2zAea1NXYXoG9+ZSSZHBSxKUdrRdVdE32 0nuVGTT2HjEI2LEYbOvaXyi6HhpuHUiyu4LD0+RIT3fiT8jUiKKLTsApTD+Ak8SLF0IESOSA6hti rv69mDDC7Klg9dT7QBPO7dpoKIUOldV3VhahndVfsDffKD7pkUUvG5XftYEQOxlWDJzuTBeqf/4h xXMtzFU9OaI6oKJjLfr6B+XBc6xwOtc/NMWmejGCAucwggLjAgEBMGkwVDELMAkGA1UEBhMCQkUx GTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxT aWduIDIgQ0EgLSBHMgIRAJZpZsDepakv5CafojXoPKcwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNzI4MTUxMTI1WjAjBgkqhkiG9w0B CQQxFgQUcrbKU6BhyE3oeTxzurn1lA6ZOG8weAYJKwYBBAGCNxAEMWswaTBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIEcyAhEAlmlmwN6lqS/kJp+iNeg8pzB6BgsqhkiG9w0BCRACCzFroGkwVDEL MAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNp Z24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgIRAJZpZsDepakv5CafojXoPKcwDQYJKoZIhvcNAQEB BQAEggEAgFZgFZz3sqyJ28mJLfqsT9bs6JRw1mf15YcXEKwzt2qJoIXRyZKwBIrhx28+XnoDJjYh 9571eGjZK/qPx3tMYVR/MRbS8a9sGWcfbf+mLmryEkHqP83UuGR6tOIbEEKeKvMmgVJItl+pk2eg 9xlh4FPleE61IrGWfBOaCr8nrP6Jb4MY3gslxj54fBuQczZIelNxvP0i/NSdKRaOPXIPHytCRQuv +RwjkvxYsqScpUcO9NaVECEZUFD0ccr0c/imf12tkGhwkrRLLjUhpSYM6jvwmsXcjoNsiVr2JjpJ vdVSrTNYdy5lVwETT7h6lOridQN+bwi1qIGH6GHHr1TAYQAAAAAAAA== --=-W0C2IaA64zLSd5c7ItFG--

1 0

Changing name of defaul data_domain to data_1_domain
by Andy Michielsen 28 Jul '14

28 Jul '14

Hello, Now I have done it. I was adding a new cluster and storage domain to my ovirt enviroment. At the end of the day I was sucsesful in doing so. Had some issues but after carefully reading the manuals got it working just fine. So now I have added a new CLUSTER002 with it's own datastorage DATA_2_DOMAIN. Then I started changing the existing default cluster name to CLUSTER001 and changing the network from VM to VM_ROMULUS and also changed the DATA_DOMAIN to DATA_1_DOMAIN. Apparently this is a bad idea as I can see all my VM's but can't start them because my ovirt enviroment tell's me the following : Cannot run VM. There is no host that satisfies current scheduling constraints. See below for details. And then nothing. So for now I 'm exporting importing the VM to my new DATA_2_DOMAIN from DATA_1_DOMAIN, which seems to work, to be able to start my VM as I need it realy quickly but how am I going to fix my optimistic changes ? Kind regards.

3 9

Re: [ovirt-users] Host installation failed. Unexpected connection termination.
by Sahina Bose 28 Jul '14

28 Jul '14

----_com.android.email_1608793116406710 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IEl0YW1hciBIZWltIDxp aGVpbUByZWRoYXQuY29tPiAKRGF0ZTogMjAxNC8wNy8yNyAgMDg6MjggIChHTVQtMDU6MDApIApU bzogUHVuaXQgRGFtYml3YWwgPGh5cHVuaXRAZ21haWwuY29tPix1c2Vyc0BvdmlydC5vcmcsRGFu IEtlbmlnc2JlcmcgPGRhbmtlbkByZWRoYXQuY29tPixhaGFkYXNAcmVkaGF0LmNvbSxTdmVuIEtp ZXNrZSA8Uy5LaWVza2VAbWl0dHdhbGQuZGU+LE1pY2hhbCBTa3JpdmFuZWsgPG1pY2hhbC5za3Jp dmFuZWtAcmVkaGF0LmNvbT4sQW50b25pIFNlZ3VyYSBQdWltZWRvbiA8YXNlZ3VyYXBAcmVkaGF0 LmNvbT4sRnJhbnRpc2VrIEtvYnppayA8ZmtvYnppa0ByZWRoYXQuY29tPixTYWhpbmEgQm9zZSA8 c2Fib3NlQHJlZGhhdC5jb20+IApTdWJqZWN0OiBSZTogSG9zdCBpbnN0YWxsYXRpb24gZmFpbGVk LiBVbmV4cGVjdGVkIGNvbm5lY3Rpb24gdGVybWluYXRpb24uIAogCk9uIDA3LzI2LzIwMTQgMDg6 MjUgUE0sIFB1bml0IERhbWJpd2FsIHdyb3RlOgo+IEhpLAo+Cj4gSSBoYXZlIHN1Y2Nlc3NmdWxs eSBpbnN0YWxsZWQgb3ZpcnQgZW5naW5lIDMuNC4zLi4uYnV0IHdoZW4gaSB0cnkgdG8gYWRkCj4g aG9zdCBpbiB0aGUgY2x1c3RlciBpdCBmYWlsZWQgd2l0aCB0aGUgZm9sbG93aW5nIGVycm9yIDot Cj4KPiBIb3N0IGNvbXB1dGUxIGluc3RhbGxhdGlvbiBmYWlsZWQuIFVuZXhwZWN0ZWQgY29ubmVj dGlvbiB0ZXJtaW5hdGlvbi4KPgo+IEVuZ2luZSBMb2cgOi0KPgo+IC0tLS0tLS0tLS0tLS0tLS0K PiAyMDE0LTA3LTI2IDE3OjE4OjM3LDE0MCBJTkZPCj4gW29yZy5vdmlydC5lbmdpbmUuY29yZS5i bGwuSW5zdGFsbGVyTWVzc2FnZXNdCj4gKG9yZy5vdmlydC50aHJlYWQucG9vbC02LXRocmVhZC0y MCkgWzQwNTgyZTUzXSBJbnN0YWxsYXRpb24KPiA0My4yNTIuMTc2LjEzIDxodHRwOi8vNDMuMjUy LjE3Ni4xMz46IENvbm5lY3RlZCB0byBob3N0IDQzLjI1Mi4xNzYuMTMKPiB3aXRoIFNTSCBrZXkg ZmluZ2VycHJpbnQ6IDFlOjM4Ojg4OmMzOjIwOjBmOmNiOjA4OjZjOmFlOmNiOjg3OjEyOmMxOjAx OjUwCgp3aGF0IGRvIHlvdSBzZWUgaW4gZW5naW5lIEV2ZW50cyB0YWIgKEdVSSk/Cgo+IDIwMTQt MDctMjYgMTc6MTg6MzcsMTY1IElORk8KPiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJy b2tlci5hdWRpdGxvZ2hhbmRsaW5nLkF1ZGl0TG9nRGlyZWN0b3JdCj4gKG9yZy5vdmlydC50aHJl YWQucG9vbC02LXRocmVhZC0yMCkgWzQwNTgyZTUzXSBDb3JyZWxhdGlvbiBJRDogNDA1ODJlNTMs Cj4gQ2FsbCBTdGFjazogbnVsbCwgQ3VzdG9tIEV2ZW50IElEOiAtMSwgTWVzc2FnZTogSW5zdGFs bGluZyBIb3N0Cj4gY29tcHV0ZTEuIENvbm5lY3RlZCB0byBob3N0IDQzLjI1Mi4xNzYuMTMgd2l0 aCBTU0gga2V5IGZpbmdlcnByaW50Ogo+IDFlOjM4Ojg4OmMzOjIwOjBmOmNiOjA4OjZjOmFlOmNi Ojg3OjEyOmMxOjAxOjUwLgo+IDIwMTQtMDctMjYgMTc6MTg6MzcsMTk0IElORk/CoCBbb3JnLm92 aXJ0LmVuZ2luZS5jb3JlLmJsbC5WZHNEZXBsb3ldCj4gKG9yZy5vdmlydC50aHJlYWQucG9vbC02 LXRocmVhZC0yMCkgWzQwNTgyZTUzXSBJbnN0YWxsYXRpb24gb2YKPiA0My4yNTIuMTc2LjEzLiBF eGVjdXRpbmcgY29tbWFuZCB2aWEgU1NIIHVtYXNrIDAwNzc7IE1ZVE1QPSIkKG1rdGVtcCAtdAo+ IG92aXJ0LVhYWFhYWFhYWFgpIjsgdHJhcCAiY2htb2QgLVIgdStyd1ggXCIke01ZVE1QfVwiID4g L2Rldi9udWxsIDI+JjE7Cj4gcm0gLWZyIFwiJHtNWVRNUH1cIiA+IC9kZXYvbnVsbCAyPiYxIiAw OyBybSAtZnIgIiR7TVlUTVB9IiAmJiBta2Rpcgo+ICIke01ZVE1QfSIgJiYgdGFyIC0td2Fybmlu Zz1uby10aW1lc3RhbXAgLUMgIiR7TVlUTVB9IiAteCAmJgo+ICIke01ZVE1QfSIvc2V0dXAgRElB TE9HL2RpYWxlY3Q9c3RyOm1hY2hpbmUKPiBESUFMT0cvY3VzdG9taXphdGlvbj1ib29sOlRydWUg PAo+IC92YXIvY2FjaGUvb3ZpcnQtZW5naW5lL292aXJ0LWhvc3QtZGVwbG95LnRhcgo+IDIwMTQt MDctMjYgMTc6MTg6MzcsMjAxIElORk8KPiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnNz aC5TU0hEaWFsb2ddCj4gKG9yZy5vdmlydC50aHJlYWQucG9vbC02LXRocmVhZC0yMCkgU1NIIGV4 ZWN1dGUgcm9vdEA0My4yNTIuMTc2LjEzCj4gPG1haWx0bzpyb290QDQzLjI1Mi4xNzYuMTM+ICd1 bWFzayAwMDc3OyBNWVRNUD0iJChta3RlbXAgLXQKPiBvdmlydC1YWFhYWFhYWFhYKSI7IHRyYXAg ImNobW9kIC1SIHUrcndYIFwiJHtNWVRNUH1cIiA+IC9kZXYvbnVsbCAyPiYxOwo+IHJtIC1mciBc IiR7TVlUTVB9XCIgPiAvZGV2L251bGwgMj4mMSIgMDsgcm0gLWZyICIke01ZVE1QfSIgJiYgbWtk aXIKPiAiJHtNWVRNUH0iICYmIHRhciAtLXdhcm5pbmc9bm8tdGltZXN0YW1wIC1DICIke01ZVE1Q fSIgLXggJiYKPiAiJHtNWVRNUH0iL3NldHVwIERJQUxPRy9kaWFsZWN0PXN0cjptYWNoaW5lIERJ QUxPRy9jdXN0b21pemF0aW9uPWJvb2w6VHJ1ZScKPiAyMDE0LTA3LTI2IDE3OjE4OjM5LDg3MSBJ TkZPCj4gW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuVmRzTWFuYWdlcl0KPiAoRGVm YXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMzMpIEluaXRpYWxpemluZyBIb3N0OiBjb21wdXRl MQo+IDIwMTQtMDctMjYgMTc6MTk6MTEsNzk4IElORk8KPiBbb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LmJsbC5nbHVzdGVyLnRhc2tzLkdsdXN0ZXJUYXNrc1NlcnZpY2VdCj4gKERlZmF1bHRRdWFydHpT Y2hlZHVsZXJfV29ya2VyLTE4KSBObyB1cCBzZXJ2ZXIgaW4gY2x1c3Rlcgo+IDIwMTQtMDctMjYg MTc6MTk6MTEsNzk5IEVSUk9SCj4gW29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuZ2x1c3Rlci5H bHVzdGVyVGFza3NTeW5jSm9iXQo+IChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xOCkg RXJyb3IgdXBkYXRpbmcgdGFza3MgZnJvbSBDTEk6Cj4gb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmNv bW1vbi5lcnJvcnMuVmRjQkxMRXhjZXB0aW9uOiBWZGNCTExFeGNlcHRpb246Cj4gTk9fVVBfU0VS VkVSX0ZPVU5EIChGYWlsZWQgd2l0aCBlcnJvciBOT19VUF9TRVJWRVJfRk9VTkQgYW5kIGNvZGUg NzAwMCkKPsKgwqDCoMKgwqDCoMKgwqDCoCBhdAo+IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwu Z2x1c3Rlci50YXNrcy5HbHVzdGVyVGFza3NTZXJ2aWNlLmdldFRhc2tMaXN0Rm9yQ2x1c3RlcihH bHVzdGVyVGFza3NTZXJ2aWNlLmphdmE6MzApCj4gW2JsbC5qYXI6XQo+wqDCoMKgwqDCoMKgwqDC oMKgIGF0Cj4gb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5nbHVzdGVyLkdsdXN0ZXJUYXNrc1N5 bmNKb2IudXBkYXRlR2x1c3RlckFzeW5jVGFza3MoR2x1c3RlclRhc2tzU3luY0pvYi5qYXZhOjg0 KQo+IFtibGwuamFyOl0KPsKgwqDCoMKgwqDCoMKgwqDCoCBhdCBzdW4ucmVmbGVjdC5HZW5lcmF0 ZWRNZXRob2RBY2Nlc3NvcjQxLmludm9rZShVbmtub3duIFNvdXJjZSkKPiBbOjEuNy4wXzY1XQo+ wqDCoMKgwqDCoMKgwqDCoMKgIGF0Cj4gc3VuLnJlZmxlY3QuRGVsZWdhdGluZ01ldGhvZEFjY2Vz c29ySW1wbC5pbnZva2UoRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5qYXZhOjQzKQo+IFty dC5qYXI6MS43LjBfNjVdCj7CoMKgwqDCoMKgwqDCoMKgwqAgYXQgamF2YS5sYW5nLnJlZmxlY3Qu TWV0aG9kLmludm9rZShNZXRob2QuamF2YTo2MDYpCj4gW3J0LmphcjoxLjcuMF82NV0KPsKgwqDC oMKgwqDCoMKgwqDCoCBhdAo+IG9yZy5vdmlydC5lbmdpbmUuY29yZS51dGlscy50aW1lci5Kb2JX cmFwcGVyLmV4ZWN1dGUoSm9iV3JhcHBlci5qYXZhOjYwKQo+IFtzY2hlZHVsZXIuamFyOl0KPsKg wqDCoMKgwqDCoMKgwqDCoCBhdCBvcmcucXVhcnR6LmNvcmUuSm9iUnVuU2hlbGwucnVuKEpvYlJ1 blNoZWxsLmphdmE6MjEzKQo+IFtxdWFydHouamFyOl0KPsKgwqDCoMKgwqDCoMKgwqDCoCBhdAo+ IG9yZy5xdWFydHouc2ltcGwuU2ltcGxlVGhyZWFkUG9vbCRXb3JrZXJUaHJlYWQucnVuKFNpbXBs ZVRocmVhZFBvb2wuamF2YTo1NTcpCj4gW3F1YXJ0ei5qYXI6XQoKU2FoaW5hIC0gYWJvdmUgbG9v a3MgbGlrZSBhbiB1bnJlbGF0ZWQgYnVnIC0gcGxlYXNlIGludmVzdGlnYXRlCgoKVGhlIGVycm9y IHJlbGF0ZWQgdG8gR2x1c3RlclRhc2tzIGlzIHVucmVsYXRlZC4uLnRoaXMgaXMgdGhlIGVycm9y IGluIHN5bmNpbmcgaW5mbyByZWxhdGVkIHRvIGdsdXN0ZXIgdGFza3MgYXMgbm8gc2VydmVyIGlu IHVwIHN0YXRlIHdhcyBhdmFpbGFibGUuIFRoaXMgam9iIHJ1bnMgaW4gYSBzZXBhcmF0ZSB0aHJl YWQuCgo= ----_com.android.email_1608793116406710 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGJyPjxicj48YnI+LS0tLS0tLS0g T3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj5Gcm9tOiBJdGFtYXIgSGVpbSAmbHQ7aWhlaW1A cmVkaGF0LmNvbSZndDsgPGJyPkRhdGU6IDIwMTQvMDcvMjcgIDA4OjI4ICAoR01ULTA1OjAwKSA8 YnI+VG86IFB1bml0IERhbWJpd2FsICZsdDtoeXB1bml0QGdtYWlsLmNvbSZndDssdXNlcnNAb3Zp cnQub3JnLERhbiBLZW5pZ3NiZXJnICZsdDtkYW5rZW5AcmVkaGF0LmNvbSZndDssYWhhZGFzQHJl ZGhhdC5jb20sU3ZlbiBLaWVza2UgJmx0O1MuS2llc2tlQG1pdHR3YWxkLmRlJmd0OyxNaWNoYWwg U2tyaXZhbmVrICZsdDttaWNoYWwuc2tyaXZhbmVrQHJlZGhhdC5jb20mZ3Q7LEFudG9uaSBTZWd1 cmEgUHVpbWVkb24gJmx0O2FzZWd1cmFwQHJlZGhhdC5jb20mZ3Q7LEZyYW50aXNlayBLb2J6aWsg Jmx0O2Zrb2J6aWtAcmVkaGF0LmNvbSZndDssU2FoaW5hIEJvc2UgJmx0O3NhYm9zZUByZWRoYXQu Y29tJmd0OyA8YnI+U3ViamVjdDogUmU6IEhvc3QgaW5zdGFsbGF0aW9uIGZhaWxlZC4gVW5leHBl Y3RlZCBjb25uZWN0aW9uIHRlcm1pbmF0aW9uLiA8YnI+IDxicj48YnI+T24gMDcvMjYvMjAxNCAw ODoyNSBQTSwgUHVuaXQgRGFtYml3YWwgd3JvdGU6PGJyPiZndDsgSGksPGJyPiZndDs8YnI+Jmd0 OyBJIGhhdmUgc3VjY2Vzc2Z1bGx5IGluc3RhbGxlZCBvdmlydCBlbmdpbmUgMy40LjMuLi5idXQg d2hlbiBpIHRyeSB0byBhZGQ8YnI+Jmd0OyBob3N0IGluIHRoZSBjbHVzdGVyIGl0IGZhaWxlZCB3 aXRoIHRoZSBmb2xsb3dpbmcgZXJyb3IgOi08YnI+Jmd0Ozxicj4mZ3Q7IEhvc3QgY29tcHV0ZTEg aW5zdGFsbGF0aW9uIGZhaWxlZC4gVW5leHBlY3RlZCBjb25uZWN0aW9uIHRlcm1pbmF0aW9uLjxi cj4mZ3Q7PGJyPiZndDsgRW5naW5lIExvZyA6LTxicj4mZ3Q7PGJyPiZndDsgLS0tLS0tLS0tLS0t LS0tLTxicj4mZ3Q7IDIwMTQtMDctMjYgMTc6MTg6MzcsMTQwIElORk88YnI+Jmd0OyBbb3JnLm92 aXJ0LmVuZ2luZS5jb3JlLmJsbC5JbnN0YWxsZXJNZXNzYWdlc108YnI+Jmd0OyAob3JnLm92aXJ0 LnRocmVhZC5wb29sLTYtdGhyZWFkLTIwKSBbNDA1ODJlNTNdIEluc3RhbGxhdGlvbjxicj4mZ3Q7 IDQzLjI1Mi4xNzYuMTMgJmx0O2h0dHA6Ly80My4yNTIuMTc2LjEzJmd0OzogQ29ubmVjdGVkIHRv IGhvc3QgNDMuMjUyLjE3Ni4xMzxicj4mZ3Q7IHdpdGggU1NIIGtleSBmaW5nZXJwcmludDogMWU6 Mzg6ODg6YzM6MjA6MGY6Y2I6MDg6NmM6YWU6Y2I6ODc6MTI6YzE6MDE6NTA8YnI+PGJyPndoYXQg ZG8geW91IHNlZSBpbiBlbmdpbmUgRXZlbnRzIHRhYiAoR1VJKT88YnI+PGJyPiZndDsgMjAxNC0w Ny0yNiAxNzoxODozNywxNjUgSU5GTzxicj4mZ3Q7IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFs LmRiYnJva2VyLmF1ZGl0bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl08YnI+Jmd0OyAob3Jn Lm92aXJ0LnRocmVhZC5wb29sLTYtdGhyZWFkLTIwKSBbNDA1ODJlNTNdIENvcnJlbGF0aW9uIElE OiA0MDU4MmU1Myw8YnI+Jmd0OyBDYWxsIFN0YWNrOiBudWxsLCBDdXN0b20gRXZlbnQgSUQ6IC0x LCBNZXNzYWdlOiBJbnN0YWxsaW5nIEhvc3Q8YnI+Jmd0OyBjb21wdXRlMS4gQ29ubmVjdGVkIHRv IGhvc3QgNDMuMjUyLjE3Ni4xMyB3aXRoIFNTSCBrZXkgZmluZ2VycHJpbnQ6PGJyPiZndDsgMWU6 Mzg6ODg6YzM6MjA6MGY6Y2I6MDg6NmM6YWU6Y2I6ODc6MTI6YzE6MDE6NTAuPGJyPiZndDsgMjAx NC0wNy0yNiAxNzoxODozNywxOTQgSU5GTyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJs bC5WZHNEZXBsb3ldPGJyPiZndDsgKG9yZy5vdmlydC50aHJlYWQucG9vbC02LXRocmVhZC0yMCkg WzQwNTgyZTUzXSBJbnN0YWxsYXRpb24gb2Y8YnI+Jmd0OyA0My4yNTIuMTc2LjEzLiBFeGVjdXRp bmcgY29tbWFuZCB2aWEgU1NIIHVtYXNrIDAwNzc7IE1ZVE1QPSIkKG1rdGVtcCAtdDxicj4mZ3Q7 IG92aXJ0LVhYWFhYWFhYWFgpIjsgdHJhcCAiY2htb2QgLVIgdStyd1ggXCIke01ZVE1QfVwiICZn dDsgL2Rldi9udWxsIDImZ3Q7JmFtcDsxOzxicj4mZ3Q7IHJtIC1mciBcIiR7TVlUTVB9XCIgJmd0 OyAvZGV2L251bGwgMiZndDsmYW1wOzEiIDA7IHJtIC1mciAiJHtNWVRNUH0iICZhbXA7JmFtcDsg bWtkaXI8YnI+Jmd0OyAiJHtNWVRNUH0iICZhbXA7JmFtcDsgdGFyIC0td2FybmluZz1uby10aW1l c3RhbXAgLUMgIiR7TVlUTVB9IiAteCAmYW1wOyZhbXA7PGJyPiZndDsgIiR7TVlUTVB9Ii9zZXR1 cCBESUFMT0cvZGlhbGVjdD1zdHI6bWFjaGluZTxicj4mZ3Q7IERJQUxPRy9jdXN0b21pemF0aW9u PWJvb2w6VHJ1ZSAmbHQ7PGJyPiZndDsgL3Zhci9jYWNoZS9vdmlydC1lbmdpbmUvb3ZpcnQtaG9z dC1kZXBsb3kudGFyPGJyPiZndDsgMjAxNC0wNy0yNiAxNzoxODozNywyMDEgSU5GTzxicj4mZ3Q7 IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudXRpbHMuc3NoLlNTSERpYWxvZ108YnI+Jmd0OyAob3Jn Lm92aXJ0LnRocmVhZC5wb29sLTYtdGhyZWFkLTIwKSBTU0ggZXhlY3V0ZSByb290QDQzLjI1Mi4x NzYuMTM8YnI+Jmd0OyAmbHQ7bWFpbHRvOnJvb3RANDMuMjUyLjE3Ni4xMyZndDsgJ3VtYXNrIDAw Nzc7IE1ZVE1QPSIkKG1rdGVtcCAtdDxicj4mZ3Q7IG92aXJ0LVhYWFhYWFhYWFgpIjsgdHJhcCAi Y2htb2QgLVIgdStyd1ggXCIke01ZVE1QfVwiICZndDsgL2Rldi9udWxsIDImZ3Q7JmFtcDsxOzxi cj4mZ3Q7IHJtIC1mciBcIiR7TVlUTVB9XCIgJmd0OyAvZGV2L251bGwgMiZndDsmYW1wOzEiIDA7 IHJtIC1mciAiJHtNWVRNUH0iICZhbXA7JmFtcDsgbWtkaXI8YnI+Jmd0OyAiJHtNWVRNUH0iICZh bXA7JmFtcDsgdGFyIC0td2FybmluZz1uby10aW1lc3RhbXAgLUMgIiR7TVlUTVB9IiAteCAmYW1w OyZhbXA7PGJyPiZndDsgIiR7TVlUTVB9Ii9zZXR1cCBESUFMT0cvZGlhbGVjdD1zdHI6bWFjaGlu ZSBESUFMT0cvY3VzdG9taXphdGlvbj1ib29sOlRydWUnPGJyPiZndDsgMjAxNC0wNy0yNiAxNzox ODozOSw4NzEgSU5GTzxicj4mZ3Q7IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlZk c01hbmFnZXJdPGJyPiZndDsgKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTMzKSBJbml0 aWFsaXppbmcgSG9zdDogY29tcHV0ZTE8YnI+Jmd0OyAyMDE0LTA3LTI2IDE3OjE5OjExLDc5OCBJ TkZPPGJyPiZndDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuZ2x1c3Rlci50YXNrcy5HbHVz dGVyVGFza3NTZXJ2aWNlXTxicj4mZ3Q7IChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0x OCkgTm8gdXAgc2VydmVyIGluIGNsdXN0ZXI8YnI+Jmd0OyAyMDE0LTA3LTI2IDE3OjE5OjExLDc5 OSBFUlJPUjxicj4mZ3Q7IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLmdsdXN0ZXIuR2x1c3Rl clRhc2tzU3luY0pvYl08YnI+Jmd0OyAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTgp IEVycm9yIHVwZGF0aW5nIHRhc2tzIGZyb20gQ0xJOjxicj4mZ3Q7IG9yZy5vdmlydC5lbmdpbmUu Y29yZS5jb21tb24uZXJyb3JzLlZkY0JMTEV4Y2VwdGlvbjogVmRjQkxMRXhjZXB0aW9uOjxicj4m Z3Q7IE5PX1VQX1NFUlZFUl9GT1VORCAoRmFpbGVkIHdpdGggZXJyb3IgTk9fVVBfU0VSVkVSX0ZP VU5EIGFuZCBjb2RlIDcwMDApPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQ8YnI+Jmd0OyBvcmcub3ZpcnQuZW5naW5lLmNvcmUu YmxsLmdsdXN0ZXIudGFza3MuR2x1c3RlclRhc2tzU2VydmljZS5nZXRUYXNrTGlzdEZvckNsdXN0 ZXIoR2x1c3RlclRhc2tzU2VydmljZS5qYXZhOjMwKTxicj4mZ3Q7IFtibGwuamFyOl08YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBh dDxicj4mZ3Q7IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuZ2x1c3Rlci5HbHVzdGVyVGFza3NT eW5jSm9iLnVwZGF0ZUdsdXN0ZXJBc3luY1Rhc2tzKEdsdXN0ZXJUYXNrc1N5bmNKb2IuamF2YTo4 NCk8YnI+Jmd0OyBbYmxsLmphcjpdPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgc3VuLnJlZmxlY3QuR2VuZXJhdGVkTWV0aG9k QWNjZXNzb3I0MS5pbnZva2UoVW5rbm93biBTb3VyY2UpPGJyPiZndDsgWzoxLjcuMF82NV08YnI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhdDxicj4mZ3Q7IHN1bi5yZWZsZWN0LkRlbGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuaW52 b2tlKERlbGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuamF2YTo0Myk8YnI+Jmd0OyBbcnQuamFy OjEuNy4wXzY1XTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGF0IGphdmEubGFuZy5yZWZsZWN0Lk1ldGhvZC5pbnZva2UoTWV0aG9k LmphdmE6NjA2KTxicj4mZ3Q7IFtydC5qYXI6MS43LjBfNjVdPGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQ8YnI+Jmd0OyBvcmcu b3ZpcnQuZW5naW5lLmNvcmUudXRpbHMudGltZXIuSm9iV3JhcHBlci5leGVjdXRlKEpvYldyYXBw ZXIuamF2YTo2MCk8YnI+Jmd0OyBbc2NoZWR1bGVyLmphcjpdPGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLnF1YXJ0ei5j b3JlLkpvYlJ1blNoZWxsLnJ1bihKb2JSdW5TaGVsbC5qYXZhOjIxMyk8YnI+Jmd0OyBbcXVhcnR6 LmphcjpdPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYXQ8YnI+Jmd0OyBvcmcucXVhcnR6LnNpbXBsLlNpbXBsZVRocmVhZFBvb2wk V29ya2VyVGhyZWFkLnJ1bihTaW1wbGVUaHJlYWRQb29sLmphdmE6NTU3KTxicj4mZ3Q7IFtxdWFy dHouamFyOl08YnI+PGJyPlNhaGluYSAtIGFib3ZlIGxvb2tzIGxpa2UgYW4gdW5yZWxhdGVkIGJ1 ZyAtIHBsZWFzZSBpbnZlc3RpZ2F0ZTxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ VGhlIGVycm9yIHJlbGF0ZWQgdG8gR2x1c3RlclRhc2tzIGlzIHVucmVsYXRlZC4uLnRoaXMgaXMg dGhlIGVycm9yIGluIHN5bmNpbmcgaW5mbyByZWxhdGVkIHRvIGdsdXN0ZXIgdGFza3MgYXMgbm8g c2VydmVyIGluIHVwIHN0YXRlIHdhcyBhdmFpbGFibGUuIFRoaXMgam9iIHJ1bnMgaW4gYSBzZXBh cmF0ZSB0aHJlYWQuPGJyPjxicj48L2Rpdj48L2JvZHk+ ----_com.android.email_1608793116406710--

3 3

[ANN] oVirt 3.5 Second Test Day - Tomorrow Jul 29th
by Sandro Bonazzola 28 Jul '14

28 Jul '14

Hi all, Tomorrow Jul 29th we'll have oVirt 3.5.0 second test day. On this day all relevant engineers will be online ready to support any issues you find during install / operating this new release. Just make sure you have 1 host or more to test drive the new release. If you're curious to see how it works, this is your chance. Thanks again for everyone who will join us tomorrow! Location #ovirt irc channel Please communicate here to allow others to see any issues What In this test day you have a license to kill ;) Follow the documentation to setup your environment, and test drive the new features. Please remember we expect to see some issues, and anything you come up with will save you when you'll install final release Remember to try daily tasks you'd usually do in the engine, to see there are no regressions. Write down the configuration you used (HW, console, etc) in the report etherpad[1]. Documentation Release notes: http://www.ovirt.org/OVirt_3.5_Release_Notes Features pages links: http://bit.ly/17qBn6F If you find errors in the wiki please annotate it as well in report etherpad [1] Prerequisites / recommendations Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc). Use Fedora 19 or 20. Latest RPMs repository to be enabled for testing the release are listed in the release notes page [2]. NEW issues / reports For any new issue, please update the reports etherpad [1] Feature owners, please make sure: your feature is updated and referenced on release page [2]. you have testing instruction for your feature either on test day page [3] or in your feature page. your team regression testing section is organized and up to date on test day page [3]. [1] http://etherpad.ovirt.org/p/3.5-testday-2 [2] http://www.ovirt.org/OVirt_3.5_Release_Notes [3] http://www.ovirt.org/OVirt_3.5_TestDay Thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Changing name of default data_domain to data_1_domain
by Andy Michielsen 28 Jul '14

28 Jul '14

Hello Oved, Gilad , I was retracing my steps of what I changed and I remember now that I also deleted the host and and then added it again from the host tab. Here I changed the Address entry from it's ip-address to its FQDN. Maybe this is where it went wrong ? But how do I fix this ? Kind regards.

1 0

[ANN] oVirt 3.5 Second Test Day - Tomorrow Jul 29th
by Sandro Bonazzola 28 Jul '14

28 Jul '14

Hi all, Tomorrow Jul 29th we'll have oVirt 3.5.0 second test day. On this day all relevant engineers will be online ready to support any issues you find during install / operating this new release. Just make sure you have 1 host or more to test drive the new release. If you're curious to see how it works, this is your chance. Thanks again for everyone who will join us tomorrow! Location #ovirt irc channel Please communicate here to allow others to see any issues What In this test day you have a license to kill ;) Follow the documentation to setup your environment, and test drive the new features. Please remember we expect to see some issues, and anything you come up with will save you when you'll install final release Remember to try daily tasks you'd usually do in the engine, to see there are no regressions. Write down the configuration you used (HW, console, etc) in the report etherpad[1]. Documentation Release notes: http://www.ovirt.org/OVirt_3.5_Release_Notes Features pages links: http://bit.ly/17qBn6F If you find errors in the wiki please annotate it as well in report etherpad [1] Prerequisites / recommendations Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc). Use Fedora 19 or 20. Latest RPMs repository to be enabled for testing the release are listed in the release notes page [2]. NEW issues / reports For any new issue, please update the reports etherpad [1] Feature owners, please make sure: your feature is updated and referenced on release page [2]. you have testing instruction for your feature either on test day page [3] or in your feature page. your team regression testing section is organized and up to date on test day page [3]. [1] http://etherpad.ovirt.org/p/3.5-testday-2 [2] http://www.ovirt.org/OVirt_3.5_Release_Notes [3] http://www.ovirt.org/OVirt_3.5_TestDay Thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[ANN] oVirt 3.5 Second Test Day - Tomorrow Jul 29th
by Sandro Bonazzola 28 Jul '14

28 Jul '14

Hi all, Tomorrow Jul 29th we'll have oVirt 3.5.0 second test day. On this day all relevant engineers will be online ready to support any issues you find during install / operating this new release. Just make sure you have 1 host or more to test drive the new release. If you're curious to see how it works, this is your chance. Thanks again for everyone who will join us tomorrow! Location #ovirt irc channel Please communicate here to allow others to see any issues What In this test day you have a license to kill ;) Follow the documentation to setup your environment, and test drive the new features. Please remember we expect to see some issues, and anything you come up with will save you when you'll install final release Remember to try daily tasks you'd usually do in the engine, to see there are no regressions. Write down the configuration you used (HW, console, etc) in the report etherpad[1]. Documentation Release notes: http://www.ovirt.org/OVirt_3.4.0_release_notes Features pages links: http://bit.ly/17qBn6F If you find errors in the wiki please annotate it as well in report etherpad [1] Prerequisites / recommendations Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc). Use Fedora 19 or 20. Latest RPMs repository to be enabled for testing the release are listed in the release notes page [2]. NEW issues / reports For any new issue, please update the reports etherpad [1] Feature owners, please make sure: your feature is updated and referenced on release page [2]. you have testing instruction for your feature either on test day page [3] or in your feature page. your team regression testing section is organized and up to date on test day page [3]. [1] http://etherpad.ovirt.org/p/3.5-testday-2 [2] http://www.ovirt.org/OVirt_3.5_Release_Notes [3] http://www.ovirt.org/OVirt_3.5_TestDay Thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Host installation failed. Unexpected connection termination.
by Punit Dambiwal 28 Jul '14

28 Jul '14

Hi, I have successfully installed ovirt engine 3.4.3...but when i try to add host in the cluster it failed with the following error :- Host compute1 installation failed. Unexpected connection termination. Engine Log :- ---------------- 2014-07-26 17:18:37,140 INFO [org.ovirt.engine.core.bll.InstallerMessages] (org.ovirt.thread.pool-6-thread-20) [40582e53] Installation 43.252.176.13: Connected to host 43.252.176.13 with SSH key fingerprint: 1e:38:88:c3:20:0f:cb:08:6c:ae:cb:87:12:c1:01:50 2014-07-26 17:18:37,165 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-20) [40582e53] Correlation ID: 40582e53, Call Stack: null, Custom Event ID: -1, Message: Installing Host compute1. Connected to host 43.252.176.13 with SSH key fingerprint: 1e:38:88:c3:20:0f:cb:08:6c:ae:cb:87:12:c1:01:50. 2014-07-26 17:18:37,194 INFO [org.ovirt.engine.core.bll.VdsDeploy] (org.ovirt.thread.pool-6-thread-20) [40582e53] Installation of 43.252.176.13. Executing command via SSH umask 0077; MYTMP="$(mktemp -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir "${MYTMP}" && tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/setup DIALOG/dialect=str:machine DIALOG/customization=bool:True < /var/cache/ovirt-engine/ovirt-host-deploy.tar 2014-07-26 17:18:37,201 INFO [org.ovirt.engine.core.utils.ssh.SSHDialog] (org.ovirt.thread.pool-6-thread-20) SSH execute root(a)43.252.176.13 'umask 0077; MYTMP="$(mktemp -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir "${MYTMP}" && tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/setup DIALOG/dialect=str:machine DIALOG/customization=bool:True' 2014-07-26 17:18:39,871 INFO [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-33) Initializing Host: compute1 2014-07-26 17:19:11,798 INFO [org.ovirt.engine.core.bll.gluster.tasks.GlusterTasksService] (DefaultQuartzScheduler_Worker-18) No up server in cluster 2014-07-26 17:19:11,799 ERROR [org.ovirt.engine.core.bll.gluster.GlusterTasksSyncJob] (DefaultQuartzScheduler_Worker-18) Error updating tasks from CLI: org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException: NO_UP_SERVER_FOUND (Failed with error NO_UP_SERVER_FOUND and code 7000) at org.ovirt.engine.core.bll.gluster.tasks.GlusterTasksService.getTaskListForCluster(GlusterTasksService.java:30) [bll.jar:] at org.ovirt.engine.core.bll.gluster.GlusterTasksSyncJob.updateGlusterAsyncTasks(GlusterTasksSyncJob.java:84) [bll.jar:] at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) [:1.7.0_65] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:60) [scheduler.jar:] at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:] at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz.jar:] ------------------ Thanks, Punit

3 2

RHEV - Hypervisor directory structure.
by santosh 27 Jul '14

27 Jul '14

This is a multi-part MIME message. --=_reb-r6F64C883-t53D29588 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi, I am trying to understand the directory structure on the RHEV hypervisor. Below is the part of the directory tree on hypervisor. |root@XYZ dom_md] tree /rhev/data-center/51a24440-6a1f-48f0-8306-92455fe7aaa1/mastersd/ /rhev/data-center/51a24440-6a1f-48f0-8306-92455fe7aaa1/mastersd/ ??? dom_md ? ??? ids -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/ids ? ??? inbox -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/inbox ? ??? leases -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/leases ? ??? master -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/master ? ??? metadata -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/metadata ? ??? outbox -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/outbox ??? images ? ??? 7f0be608-0251-4125-a3a1-b4e74bbcaa34 ? ? ??? 53596e07-0317-43b3-838a-13cde56ce1c8 -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/53596e07-0317-43b3-838a-13cde56ce1c8 ? ??? aa6b4787-271f-4651-98c8-97054ff4418d ? ? ??? 22961431-c139-4311-bc78-c4f5a58cfda7 -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/22961431-c139-4311-bc78-c4f5a58cfda7 ? ? ??? f5f5f1ff-af71-4d11-a15a-dbc863e5d6f7 -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/f5f5f1ff-af71-4d11-a15a-dbc863e5d6f7 ? ??? e4f70c9e-c5b3-4cbe-a755-684d6a86026f ? ??? 8c2f5f05-c109-45e7-af98-c54437ad5d9e -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/8c2f5f05-c109-45e7-af98-c54437ad5d9e ??? master ??? lost+found ??? tasks ??? vms ??? 1ba7645c-79db-403a-95f6-b3078e441b86 ? ??? 1ba7645c-79db-403a-95f6-b3078e441b86.ovf ??? 6df2c080-a0d5-4202-8f09-ed719184f667 ??? 6df2c080-a0d5-4202-8f09-ed719184f667.ovf| I am trying to understand the *ids, inbox, leases, master, metadata and outbox* device files above. I would appreciate any pointer to get this information. Thanks. ***************************Legal Disclaimer*************************** "This communication may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message by mistake, please advise the sender by reply email and delete the message. Thank you." ********************************************************************** --=_reb-r6F64C883-t53D29588 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> I am trying to understand the directory structure on the RHEV hypervisor. <br> Below is the part of the directory tree on hypervisor.<br> <br> <br> <blockquote> <pre><font color="#000099"><big><code>root@XYZ dom_md] tree /rhev/data-center/51a24440-6a1f-48f0-8306-92455fe7aaa1/mastersd/ /rhev/data-center/51a24440-6a1f-48f0-8306-92455fe7aaa1/mastersd/ ├── dom_md │   ├── ids -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/ids │   ├── inbox -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/inbox │   ├── leases -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/leases │   ├── master -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/master │   ├── metadata -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/metadata │   └── outbox -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/outbox ├── images │   ├── 7f0be608-0251-4125-a3a1-b4e74bbcaa34 │   │   └── 53596e07-0317-43b3-838a-13cde56ce1c8 -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/53596e07-0317-43b3-838a-13cde56ce1c8 │   ├── aa6b4787-271f-4651-98c8-97054ff4418d │   │   ├── 22961431-c139-4311-bc78-c4f5a58cfda7 -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/22961431-c139-4311-bc78-c4f5a58cfda7 │   │   └── f5f5f1ff-af71-4d11-a15a-dbc863e5d6f7 -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/f5f5f1ff-af71-4d11-a15a-dbc863e5d6f7 │   └── e4f70c9e-c5b3-4cbe-a755-684d6a86026f │   └── 8c2f5f05-c109-45e7-af98-c54437ad5d9e -> /dev/f86ee04c-d84d-4032-a3f8-c77ed1ad29ea/8c2f5f05-c109-45e7-af98-c54437ad5d9e └── master ├── lost+found ├── tasks └── vms ├── 1ba7645c-79db-403a-95f6-b3078e441b86 │   └── 1ba7645c-79db-403a-95f6-b3078e441b86.ovf └── 6df2c080-a0d5-4202-8f09-ed719184f667 └── 6df2c080-a0d5-4202-8f09-ed719184f667.ovf</code></big></font></pre> </blockquote> <br> <p>I am trying to understand the <strong>ids, inbox, leases, master, metadata and outbox</strong> device files above. </p> <p>I would appreciate any pointer to get this information. </p> <p>Thanks.</p> </body> </html> <pre> ***************************Legal Disclaimer*************************** "This communication may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message by mistake, please advise the sender by reply email and delete the message. Thank you." **********************************************************************</pre> --=_reb-r6F64C883-t53D29588--

2 1

Glusterfs HA with Ovirt
by Punit Dambiwal 27 Jul '14

27 Jul '14

Hi, I have some HA related concern about glusterfs with Ovirt...let say i have 4 storage node with gluster bricks as below :- 1. 10.10.10.1 to 10.10.10.4 with 2 bricks each and i have distributed replicated architecture... 2. Now attached this gluster storge to ovrit-engine with the following mount point 10.10.10.2/vol1 3. In my cluster i have 3 hypervisior hosts (10.10.10.5 to 10.10.10.7) SPM is on 10.10.10.5... 4. What happen if 10.10.10.2 will goes down.....can hypervisior host can still access the storage ?? 5. What happen if SPM goes down ??? Note :- What happen for point 4 &5 ,If storage and Compute both working on the same server. Thanks, Punit

6 10

Documentation of cloud-init
by Amedeo Salvati 25 Jul '14

25 Jul '14

--_=__=_XaM3_.1406285961.2A.813187.42.17781.52.42.007.867559545 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hy guys,=0A=0Aafter some headache I was able to use cloud-init via python= -sdk (thanks to Juan), and I hope no one will fight anymore with them :D,= so if you want I think it's better to document with a simple example it'= s use on web page available at:=0A=0Ahttp://www.ovirt.org/Features/Cloud-= Init_Integration=0A=0Abelow simple change that you can integrate on web p= age:=0A=0A- fix api design example of usage for files xml, on the web pag= e you can find:=0A=0A...=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <files>=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <file>=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <name>/tmp/testFile1.txt</n= ame>=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <cont= ent>temp content</content>=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <type>PLAINTEXT</type>=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 </file>=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </files>=0A= ...=0A=0Abut on params.File there aren't any "type" parameter only "type_= " so you can change xml with:=0A=0A...=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <files>=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <file>=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <name>/tmp/test= File1.txt</name>=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 <content>temp content</content>=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 <type_>PLAINTEXT</type_>=0A=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </file>=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 </files>=0A...=0A=0A- insert an example of using cloud-init via pytho= n-sdk (I hope java-sdk haven't big differences).=0A=0Afor this you can in= sert on web page an example of setting via cloud-init: hostname, reset ro= ot password and write a simple text file, and finally simple python code = is:=0A=0A...=0Ascontent =3D "write_files:\n-=C2=A0=C2=A0 content: |\n=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #simple file\n=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 PIPPO=3D\"ciao\"\n=C2=A0=C2=A0=C2=A0 path: /etc/pippo.= txt"=0Aaction =3D params.Action(=0A=C2=A0 vm=3Dparams.VM(=0A=C2=A0=C2=A0=C2= =A0 initialization=3Dparams.Initialization(=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 cloud_init=3Dparams.CloudInit(=0A=C2=A0=C2=A0 =C2=A0host=3Dparams.Hos= t(address=3D"rheltest029"),=0A=C2=A0=C2=A0 =C2=A0users=3Dparams.Users(=0A= =C2=A0=C2=A0 =C2=A0=C2=A0 user=3D[params.User(user_name=3D"root", passwor= d=3D"pippolo")]=0A=C2=A0=C2=A0 =C2=A0=C2=A0 ),=0A=C2=A0=C2=A0 =C2=A0files= =3Dparams.Files(=0A=C2=A0=C2=A0 =C2=A0=C2=A0 file=3D[params.File(name=3D"= /etc/pippo.txt", content=3Dscontent, type_=3D"PLAINTEXT")]=0A=C2=A0=C2=A0= =C2=A0=C2=A0 )=0A=C2=A0=C2=A0 =C2=A0)=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 )= =0A=C2=A0 )=0A)=0Avm.start( action )=0A...=0A=0AHTH=0AAmedeo Salvati --_=__=_XaM3_.1406285961.2A.813187.42.17781.52.42.007.867559545 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A<div class=3D"xam_msg_class">=0A<div style=3D"font: normal 13px Arial;= color:rgb(31, 28, 27);">Hy guys,<br><br>after some headache I was able t= o use cloud-init via python-sdk (thanks to Juan), and I hope no one will = fight anymore with them :D, so if you want I think it's better to documen= t with a simple example it's use on web page available at:<br><br>http://= www.ovirt.org/Features/Cloud-Init_Integration<br><br>below simple change = that you can integrate on web page:<br><br>- fix api design example of us= age for files xml, on the web page you can find:<br><br>...<br> &nbs= p;     <files><br>    &nbsp= ;    <file><br>      &= nbsp;    <name>/tmp/testFile1.txt</name><br>&n= bsp;          <content&gt= ;temp content</content><br>      &nbs= p;    <type>PLAINTEXT</type><br>  &n= bsp;      </file><br>   &nb= sp;   </files><br>...<br><br>but on params.File there are= n't any "type" parameter only "type_" so you can change xml with:<br><br>= ...<br>       <files><br>  =        <file><br>   &n= bsp;       <name>/tmp/testFile1.txt&l= t;/name><br>         &nbs= p; <content>temp content</content><br>   &nbsp= ;       <type_>PLAINTEXT</type_&gt= ;<br>         </file><br>&n= bsp;      </files><br>...<br><br>- insert = an example of using cloud-init via python-sdk (I hope java-sdk haven't bi= g differences).<br><br>for this you can insert on web page an example of = setting via cloud-init: hostname, reset root password and write a simple = text file, and finally simple python code is:<br><br>...<br>scontent =3D = "write_files:\n-   content: |\n     &n= bsp;  #simple file\n        PIPPO= =3D\"ciao\"\n    path: /etc/pippo.txt"<br>action =3D param= s.Action(<br>  vm=3Dparams.VM(<br>    initialization=3D= params.Initialization(<br>      cloud_init=3Dpar= ams.CloudInit(<br>    host=3Dparams.Host(address=3D"rhelte= st029"),<br>    users=3Dparams.Users(<br>   &nbs= p;  user=3D[params.User(user_name=3D"root", password=3D"pippolo")]<b= r>      ),<br>    files=3Dparams.Files= (<br>      file=3D[params.File(name=3D"/etc/pippo.txt= ", content=3Dscontent, type_=3D"PLAINTEXT")]<br>     = )<br>    )<br>      )<br>  = )<br>)<br>vm.start( action )<br>...<br><br>HTH<br>Amedeo Salvati</div>=0A= </div>=0A --_=__=_XaM3_.1406285961.2A.813187.42.17781.52.42.007.867559545--

2 1

[ANN] oVirt 3.5.0 Second Beta is now available for testing
by Sandro Bonazzola 25 Jul '14

25 Jul '14

The oVirt team is pleased to announce that the 3.5.0 Second Beta is now available for testing as of Jul 21th 2014. The beta is available now for Fedora 19, Fedora 20 and Red Hat Enterprise Linux 6.5 (or similar). Feel free to join us testing it on Tue Jul 29th second test day! This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.5-pre has been updated for delivering this release without the need of enabling any other repository. Please refer to release notes [1] for Installation / Upgrade instructions. New oVirt Live, oVirt Guest Tools and oVirt Node ISO will be available soon as well[2]. Please note that mirrors may need a couple of days before being synchronized. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.5.repo commenting the mirror line and removing the comment on baseurl line. [1] http://www.ovirt.org/OVirt_3.5_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

Weird yum depencency problem upgtading host 3.4.3
by Daniel Helgenberger 25 Jul '14

25 Jul '14

--=-xBZU0tRm0TJDUQp8tADG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I am in the process updating my 2 node HE cluster to oVirt 3.4.3. The engine and node one is already updaded without any problems (great work on fixing the ha-agend subsystem locked issue!). Now, yum updating node two - immediately after node one - : Error: Package: ovirt-hosted-engine-ha-1.2.1-0.2.master.20140723134021.el6.noarch (ovirt-3.4-stable) Requires: vdsm-python >=3D 4.16.0 Removing: vdsm-python-4.14.9-0.el6.x86_64 (@ovirt-3.4-stable) vdsm-python =3D 4.14.9-0.el6 Updated By: vdsm-python-4.14.11.2-0.el6.x86_64 (ovirt-3.4-stable) vdsm-python =3D 4.14.11.2-0.el6 Available: vdsm-python-4.12.1-2.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.12.1-2.el6 Available: vdsm-python-4.12.1-4.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.12.1-4.el6 Available: vdsm-python-4.13.0-9.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.0-9.el6 Available: vdsm-python-4.13.0-11.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.0-11.el6 Available: vdsm-python-4.13.2-1.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.2-1.el6 Available: vdsm-python-4.13.3-2.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.3-2.el6 Available: vdsm-python-4.13.3-3.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.3-3.el6 Available: vdsm-python-4.13.3-4.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.3-4.el6 Available: vdsm-python-4.13.4-0.el6.i686 (ovirt-3.3-stable) vdsm-python =3D 4.13.4-0.el6 Available: vdsm-python-4.14.6-0.el6.i686 (ovirt-3.4-stable) vdsm-python =3D 4.14.6-0.el6 Available: vdsm-python-4.14.8.1-0.el6.i686 (ovirt-3.4-stable) vdsm-python =3D 4.14.8.1-0.el6 Available: vdsm-python-4.14.11-0.el6.i686 (ovirt-3.4-stable) vdsm-python =3D 4.14.11-0.el6 Error: Package: ovirt-hosted-engine-ha-1.2.1-0.2.master.20140723134021.el6.noarch (ovirt-3.4-stable) Requires: vdsm-cli >=3D 4.16.0 Removing: vdsm-cli-4.14.9-0.el6.noarch (@ovirt-3.4-stable) vdsm-cli =3D 4.14.9-0.el6 Updated By: vdsm-cli-4.14.11.2-0.el6.noarch (ovirt-3.4-stable) vdsm-cli =3D 4.14.11.2-0.el6 Available: vdsm-cli-4.12.0-1.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.12.0-1.el6 Available: vdsm-cli-4.12.1-2.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.12.1-2.el6 Available: vdsm-cli-4.12.1-4.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.12.1-4.el6 Available: vdsm-cli-4.13.0-9.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.0-9.el6 Available: vdsm-cli-4.13.0-11.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.0-11.el6 Available: vdsm-cli-4.13.2-1.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.2-1.el6 Available: vdsm-cli-4.13.3-2.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.3-2.el6 Available: vdsm-cli-4.13.3-3.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.3-3.el6 Available: vdsm-cli-4.13.3-4.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.3-4.el6 Available: vdsm-cli-4.13.4-0.el6.noarch (ovirt-3.3-stable) vdsm-cli =3D 4.13.4-0.el6 Available: vdsm-cli-4.14.6-0.el6.noarch (ovirt-3.4-stable) vdsm-cli =3D 4.14.6-0.el6 Available: vdsm-cli-4.14.8.1-0.el6.noarch (ovirt-3.4-stable) vdsm-cli =3D 4.14.8.1-0.el6 Available: vdsm-cli-4.14.11-0.el6.noarch (ovirt-3.4-stable) vdsm-cli =3D 4.14.11-0.el6 Error: Package: ovirt-hosted-engine-ha-1.2.1-0.2.master.20140723134021.el6.noarch (ovirt-3.4-stable) Requires: vdsm >=3D 4.16.0 Removing: vdsm-4.14.9-0.el6.x86_64 (@ovirt-3.4-stable) vdsm =3D 4.14.9-0.el6 Updated By: vdsm-4.14.11.2-0.el6.x86_64 (ovirt-3.4-stable) vdsm =3D 4.14.11.2-0.el6 Available: vdsm-4.12.1-2.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.12.1-2.el6 Available: vdsm-4.12.1-4.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.12.1-4.el6 Available: vdsm-4.13.0-9.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.0-9.el6 Available: vdsm-4.13.0-11.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.0-11.el6 Available: vdsm-4.13.2-1.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.2-1.el6 Available: vdsm-4.13.3-2.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.3-2.el6 Available: vdsm-4.13.3-3.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.3-3.el6 Available: vdsm-4.13.3-4.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.3-4.el6 Available: vdsm-4.13.4-0.el6.i686 (ovirt-3.3-stable) vdsm =3D 4.13.4-0.el6 Available: vdsm-4.14.6-0.el6.i686 (ovirt-3.4-stable) vdsm =3D 4.14.6-0.el6 Available: vdsm-4.14.8.1-0.el6.i686 (ovirt-3.4-stable) vdsm =3D 4.14.8.1-0.el6 Available: vdsm-4.14.11-0.el6.i686 (ovirt-3.4-stable) vdsm =3D 4.14.11-0.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest You have new mail in /var/spool/mail/root The other host upgraded to vdsm 4.14.11 .... Thanks, Daniel --=20 Daniel Helgenberger=20 m box bewegtbild GmbH=20 P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19=20 D-10115 BERLIN=20 www.m-box.de www.monkeymen.tv=20 Gesch=C3=A4ftsf=C3=BChrer: Martin Retschitzegger / Michaela G=C3=B6llner Handeslregister: Amtsgericht Charlottenburg / HRB 112767=20 --=-xBZU0tRm0TJDUQp8tADG Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN9zCCBFcw ggM/oAMCAQICCwQAAAAAAS9O4TFGMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwWtB+TXs+BJ9 3SJRaV+3uRNGJ3cUO+MTgW8+5HQXfgy19CzkDI1T1NwwICi/bo4R/mYR5FEWx91//eE0ElC/89iY 7GkL0tDasmVx4TOXnrqrsziUcxEPPqHRE8x4NhtBK7+8o0nsMIJMA1gyZ2FA5To2Ew1BBuvovvDJ +Nua3qOCNBNu+8A+eNpJlVnlu/qB7+XWaPXtUMlsIikxD+gREFVUgYE4VzBuLa2kkg0VLd09XkE2 ceRDm6YgRATuDk6ogUyX4OLxCGIJF8yi6Z37M0wemDA6Uff0EuqdwDQd5HwG/rernUjt1grLdAxq 8BwywRRg0eFHmE+ShhpyO3Fi+wIDAQABo4IBJTCCASEwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB /wQIMAYBAf8CAQAwHQYDVR0OBBYEFD8V0m18L+cxnkMKBqiUbCw7xe5lMEcGA1UdIARAMD4wPAYE VR0gADA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5 LzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QuY3JsMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vcm9v dHIxMB8GA1UdIwQYMBaAFGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQDI WOF8oQHpI41wO21cUvjE819juuGa05F5yK/ESqW+9th9vfhG92eaBSLViTIJV7gfCFbt11WexfK/ 44NeiJMfi5wX6sK7Xnt8QIK5lH7ZX1Wg/zK1cXjrgRaYUOX/MA+PmuRm4gWV0zFwYOK2uv4OFgaM mVr+8en7K1aQY2ecI9YhEaDWOcSGj6SN8DvzPdE4G4tBk4/aIsUged9sGDqRYweKla3LTNjXPps1 Y+zsVbgHLtjdOIB0YZ1hrlAQcY2L/b+V+Yyoi7CMdOtmm1Rm6Jh5ILbwQTjlUCkgu5yVdfs9LDKc M0SPeCldkjfaGVSd+nURMOUy3hfxsMVux9+FMIIEyjCCA7KgAwIBAgIRAJZpZsDepakv5CafojXo PKcwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjAeFw0xMzA4Mjcx NjU3NThaFw0xNjA4MjcxNjU3NThaMFgxCzAJBgNVBAYTAkRFMRwwGgYDVQQDExNEYW5pZWwgSGVs Z2VuYmVyZ2VyMSswKQYJKoZIhvcNAQkBFhxkYW5pZWwuaGVsZ2VuYmVyZ2VyQG0tYm94LmRlMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzgFDm8+SeTU4Yt3WopJQgqZAuuNxyMlxiPuq 0C0D581goXz2nVVjhTCIVwX2MqWYD1Dyjy1hLHXothgWgZaiQ1EB4oVdmIFmIfIjR6SkR/Gjw3lx MwJzEpxJhZXyyrOYE8Kgw2maJWgLx5zw2/lKpcffhVW0OY0t+JWWxPKiYFcAmQnb+fleonM8sUZZ ZES08uRVVL67jbq+3+E2xCLlqQ2iJ1h5ej3wlyuZ4CkUnfMHYrG8zOIfHwsPirWACX026a1flgts Kl1Yv0CRZ1c5qujcP3OPpDovIbBr9RBStl2DcFdzTuGMdmfp32963VLOlvKpClPMzrfJeJfWZ4Qy UwIDAQABo4IBkTCCAY0wDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQw MgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMCcGA1Ud EQQgMB6BHGRhbmllbC5oZWxnZW5iZXJnZXJAbS1ib3guZGUwCQYDVR0TBAIwADAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC5nbG9iYWxz aWduLmNvbS9ncy9nc3BlcnNvbmFsc2lnbjJnMi5jcmwwVQYIKwYBBQUHAQEESTBHMEUGCCsGAQUF BzAChjlodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJn Mi5jcnQwHQYDVR0OBBYEFLw0UD+6l35aKnDaePxEP8K35HYZMB8GA1UdIwQYMBaAFD8V0m18L+cx nkMKBqiUbCw7xe5lMA0GCSqGSIb3DQEBBQUAA4IBAQBdVOm7h+E4sRMBbTN1tCIjAEgxmB5U0mdZ XcawzEHLJxTrc/5YFBMGX2qPju8cuZV14XszMfRBJdlJz1Od+voJggianIhnFEAakCxaa1l/cmJ5 EDT6PgZAkXbMB5rU1dhegb35lJJkcFLEpR2tF1V0TfbSe5UZNPYeMQjYsRhs69pfKLoeGm4dSLK7 gsPT5EhPd+JPyNSIootOwClMP4CTxIsXQgRI5IDqG2Ku/r2YMMLsqWD11PtAE87t2mgohQ6V1XdW FqGd1V+wN98oPumRRS8bld+1gRA7GVYMnO5MF6p//iHFcy3MVT05ojqgomMt+voH5cFzrHA61z80 xaZ6MIIEyjCCA7KgAwIBAgIRAJZpZsDepakv5CafojXoPKcwDQYJKoZIhvcNAQEFBQAwVDELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBHMjAeFw0xMzA4MjcxNjU3NThaFw0xNjA4MjcxNjU3NThaMFgx CzAJBgNVBAYTAkRFMRwwGgYDVQQDExNEYW5pZWwgSGVsZ2VuYmVyZ2VyMSswKQYJKoZIhvcNAQkB FhxkYW5pZWwuaGVsZ2VuYmVyZ2VyQG0tYm94LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAzgFDm8+SeTU4Yt3WopJQgqZAuuNxyMlxiPuq0C0D581goXz2nVVjhTCIVwX2MqWYD1Dy jy1hLHXothgWgZaiQ1EB4oVdmIFmIfIjR6SkR/Gjw3lxMwJzEpxJhZXyyrOYE8Kgw2maJWgLx5zw 2/lKpcffhVW0OY0t+JWWxPKiYFcAmQnb+fleonM8sUZZZES08uRVVL67jbq+3+E2xCLlqQ2iJ1h5 ej3wlyuZ4CkUnfMHYrG8zOIfHwsPirWACX026a1flgtsKl1Yv0CRZ1c5qujcP3OPpDovIbBr9RBS tl2DcFdzTuGMdmfp32963VLOlvKpClPMzrfJeJfWZ4QyUwIDAQABo4IBkTCCAY0wDgYDVR0PAQH/ BAQDAgWgMEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3 Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMCcGA1UdEQQgMB6BHGRhbmllbC5oZWxnZW5iZXJn ZXJAbS1ib3guZGUwCQYDVR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYD VR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9nc3BlcnNvbmFsc2ln bjJnMi5jcmwwVQYIKwYBBQUHAQEESTBHMEUGCCsGAQUFBzAChjlodHRwOi8vc2VjdXJlLmdsb2Jh bHNpZ24uY29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJnMi5jcnQwHQYDVR0OBBYEFLw0UD+6l35a KnDaePxEP8K35HYZMB8GA1UdIwQYMBaAFD8V0m18L+cxnkMKBqiUbCw7xe5lMA0GCSqGSIb3DQEB BQUAA4IBAQBdVOm7h+E4sRMBbTN1tCIjAEgxmB5U0mdZXcawzEHLJxTrc/5YFBMGX2qPju8cuZV1 4XszMfRBJdlJz1Od+voJggianIhnFEAakCxaa1l/cmJ5EDT6PgZAkXbMB5rU1dhegb35lJJkcFLE pR2tF1V0TfbSe5UZNPYeMQjYsRhs69pfKLoeGm4dSLK7gsPT5EhPd+JPyNSIootOwClMP4CTxIsX QgRI5IDqG2Ku/r2YMMLsqWD11PtAE87t2mgohQ6V1XdWFqGd1V+wN98oPumRRS8bld+1gRA7GVYM nO5MF6p//iHFcy3MVT05ojqgomMt+voH5cFzrHA61z80xaZ6MYIC5zCCAuMCAQEwaTBUMQswCQYD VQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQ ZXJzb25hbFNpZ24gMiBDQSAtIEcyAhEAlmlmwN6lqS/kJp+iNeg8pzAJBgUrDgMCGgUAoIIBUzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA3MjQxNjIzMDlaMCMG CSqGSIb3DQEJBDEWBBT6i7l0yHWCZaStlhmMrBhZ97a/jjB4BgkrBgEEAYI3EAQxazBpMFQxCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWdu IFBlcnNvbmFsU2lnbiAyIENBIC0gRzICEQCWaWbA3qWpL+Qmn6I16DynMHoGCyqGSIb3DQEJEAIL MWugaTBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMh R2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIEcyAhEAlmlmwN6lqS/kJp+iNeg8pzANBgkq hkiG9w0BAQEFAASCAQBKkY1xImSPMK4whqROcGG8+WvrwqFNZsvkY8/eUNug5RuRupVvxNvP4hBU 5GWS1zxbSLIqCh57rhW82WNwIUENEWkC7kZ9dCL7VENtc6oLob92qM+KtZ7fJgKU92apVDNipQgD aoFVxg7ph45CGIMbf1ZEB6BXLMzBscrEl37K1VktW818Pd3xLxme99Zwu/Lnt6V5F4RQYg12ju2Y E7lWYizficVWzKKKKt4yYdd3ij5JeIE+VV6iuwgp3n3g2196rLBbMt8Vnz4o+IR1sEg4xXBUum33 2IiVnZpoJaxLm8QQMvPHnie7qeTmWD5umqrIFyEMkbbqZHhVGLy20EQGAAAAAAAA --=-xBZU0tRm0TJDUQp8tADG--

5 7

Migration of CentOS 6.5 VMs causes kernel panic after upgrading to oVirt 3.4.3
by s k 25 Jul '14

25 Jul '14

--_1dcf94f6-d452-406c-89e4-63c2a6074ed7_ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Hello=2C I upgraded oVirt yesterday from 3.4.2 to 3.4.3 and performed a yum upgrade = on all ovirt nodes as well without rebooting any of them. After completing the upgrade=2C I tried to perform manual migration of VMs = to a different host. The result was that all Windows 2003/2008 and CentOS = 5 VMs were migrated successfully without any issues but all CentOS 6.5 VMs = crashed although migration was completed successfully. By looking the console of the CentOS 6.5 VMs I noticed that a few seconds a= fter migration was complete=2C all the processes were killed=2C many out of= memory errors were thrown as well as messages like "virtio_balloon virtio3= : Out of puff! Cant' get 256 pages" and the VM ended up in kernel panic so = I had to perform a manual poweroff and start the VM again. Any ideas of what might be the cause? I have opened an urgent Bug for this = (https://bugzilla.redhat.com/show_bug.cgi?id=3D1123274) Thank you=2C Sokratis = --_1dcf94f6-d452-406c-89e4-63c2a6074ed7_ Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'>Hello=2C<div><br></div><div><br>= </div><div>I upgraded oVirt yesterday from 3.4.2 to 3.4.3 and performed a y= um upgrade on all ovirt nodes as well without rebooting any of them.</div><= div><br></div><div><br></div><div>After completing the upgrade=2C I tried t= o perform manual migration of VMs to a different host. The result was that = all Windows 2003/2008 &nbsp=3Band CentOS 5 VMs were migrated successfully w= ithout any issues but all CentOS 6.5 VMs crashed although migration was com= pleted successfully.</div><div><br></div><div><br></div><div>By looking the= console of the CentOS 6.5 VMs I noticed that a few seconds after migration= was complete=2C all the processes were killed=2C many out of memory errors= were thrown as well as messages like "virtio_balloon virtio3: Out of puff!= Cant' get 256 pages" and the VM ended up in kernel panic so I had to perfo= rm a manual poweroff and start the VM again.</div><div><br></div><div><br><= /div><div>Any ideas of what might be the cause? I have opened an urgent Bug= for this (<a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1123274= " target=3D"_blank" style=3D"font-size: 12pt=3B">https://bugzilla.redhat.co= m/show_bug.cgi?id=3D1123274</a>)</div><div><br></div><div><br></div><div>Th= ank you=2C</div><div><br></div><div><br></div><div>Sokratis</div><div><br><= /div><div><br></div><div><br></div><div><br></div><div><br></div> = </div></body> </html>= --_1dcf94f6-d452-406c-89e4-63c2a6074ed7_--

1 0

Call for Papers Reminder: KVM Forum
by Brian Proffitt 25 Jul '14

25 Jul '14

This is a reminder to everyone that the CFP for KVM Forum is coming up very soon. All submissions must be received[1] before midnight (PDT) on July 27, 2014. This event will be an excellent opportunity to show off the new work being done around oVirt, and will also be hosting of a new oVirt Workshop. Get your submittals in as soon as you can! [1] http://events.linuxfoundation.org/events/kvm-forum/program/cfp BKP -- 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

Disk migration eats all CPU, vms running in SPM become unresponsive
by Federico Alberto Sayd 24 Jul '14

24 Jul '14

Hello: I am experiencing some troubles with ovirt nodes: When a node is selected as SPM and I move a disk between storage domains, it seems that migration process eats all CPU and some VMs (running on the SPM) hang, others lose network connectivity. The events tab at Ovirt Engine reports the CPU exceeding the defined threshold and then reports that VMs in such host (SPM) are not responding. How can I debug this? Why do the VMs become unresponsive or lost network connectivity when the host CPU goes too high? I have attached a screenshot of the ovirt-engine events, and the relevant engine.log My setup: oVirt Engine Version: 3.4.0-1.el6 (Centos 6.5) Nodes: Centos 6.5 vdsm-4.14.6-0.el6 libvirt-0.10.2-29.el6_5.9 KVM: 0.12.1.2 - 2.415.el6_5.10 (jenkins build) Regards Federico

2 1

planning ovirt for production
by Demeter Tibor 24 Jul '14

24 Jul '14

------=_Part_27854792_967363234.1405525563715 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, We have a production environment with KVM+centos6 and we want to switch to ovirt. At this moment we have 12 VM on three independent server. This VMs uses the local disks of servers, we don't have a central storage. currently we have for ovirt - Two Dell R710 with 128 gigs of ram. - A third dell server for ovirt-engine. - four 1 gb/sec NICs/ server. - Smart GB switch we would like make an ovirt environment with - clusterized, redundant filesystem, data loss protection - If a host goes to down the VMs could made a restart on the remain host - LACP/bonding (mode 6) for fast I/O beetwen gluster hosts, we don't have 10Gbe nics - 8 TB of disk capacity for VMs we don't want: - using hw raid on servers, because we need free disk tray for more capacity My questions. - Which glusterfs method is the best for us for performance? - Can I make a real "performance" disk i/o by 4-4 NICs ? Or I need 10 Gbe nic for this? - How much disk need for good redundancy/performance? 4/server or 2/server ? - What will the weak point our project? Thanks in advance. Tibor ------=_Part_27854792_967363234.1405525563715 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: times new roman, new york, times, se= rif; font-size: 12pt; color: #000000"><div>Hi,</div><div><br></div><div>We = have a production environment with KVM+centos6 and we want to switch to ovi= rt.</div><div>At this moment we have 12 VM on three independent server.&nbs= p;</div><div>This VMs uses the local disks of servers, we don't have a cent= ral storage.</div><div><br></div><div>currently we have for ovirt</div><div= ><br></div><div>- Two Dell R710 with 128 gigs of ram.</div><div><span style= =3D"font-size: 12pt;">- A third dell server for ovirt-engine.</span></div><= div><span style=3D"font-size: 12pt;">- four 1 gb/sec NICs/ server.</span></= div><div><span style=3D"font-size: 12pt;">- Smart GB switch</span></div><di= v><br></div><div>we would like make an ovirt environment with</div><div><br= ></div><div>- clusterized, redundant filesystem, data loss protection</div>= <div>- If a host goes to down the VMs could made a restart on the remain ho= st</div><div>- LACP/bonding (mode 6) for fast I/O beetwen gluster hosts, we= don't have 10Gbe nics</div><div>- 8 TB of disk capacity for VMs</div><div>= <br></div><div>we don't want:</div><div><br></div><div>- using hw raid on s= ervers, because we need free disk tray for more capacity</div><div><br></di= v><div>My questions.</div><div><br></div><div>- Which glusterfs method is t= he best for us for performance?</div><div>- Can I make a real "performance"= disk i/o  by 4-4 NICs  ? Or I need 10 Gbe nic for this?</div><di= v>- How much disk need for good redundancy/performance? 4/server or 2/serve= r ? </div><div>- What will the weak point our project?</div><div><br><= /div><div>Thanks in advance.</div><div><br></div><div>Tibor</div><div><br><= /div><div><br></div><div><br></div><div><br></div><div><br></div></div></bo= dy></html> ------=_Part_27854792_967363234.1405525563715--

3 3