- Users - oVirt List Archives

[Rest API / Python SDK] Setting VM Video Type
by Ollie Armstrong 11 Dec '15

11 Dec '15

Hi everyone, I'm looking for a method of settings the VM's video type to QXL from the Python SDK, which doesn't appear to be possible in any way. Whenever I set the graphics protocol to VNC it defaults the video type to CIRRUS. I'd like to use QXL with VNC, which is possible to set using the console's web UI. Has anyone achieved this before? Using the "SPICE + VNC" option with QXL would also be acceptable, but the API doesn't seem to accept that value for the graphics protocol. Cheers, Ollie

2 3

[ANN] oVirt 3.6.1 Fourth Release Candidate is now available for testing
by Sandro Bonazzola 11 Dec '15

11 Dec '15

The oVirt Project is pleased to announce the availability of the Fourth Release Candidate of oVirt 3.6.1 for testing, as of December 10th, 2015. This release is available now for Fedora 22, Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar). This release supports Hypervisor Hosts running Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar) and Fedora 22. Highly experimental support for Debian 8.2 Jessie has been added too. This release candidate includes updated packages for: - ovirt-engine - ovirt-engine-extension-aaa-ldap This release of oVirt 3.6.1 includes numerous bug fixes. See the release notes [1] for an initial list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO will be available soon[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.6.1_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 3

VM migration fails when hardware node fails
by Bill James 11 Dec '15

11 Dec '15

We are testing our new ovirt installation. We notice that if I shutdown a hardware node that the VM's do not migrate off and don't start up after the node is restarted. Its a 3 node cluster with the ovirt-engine on a 4th host. centos 7.1.1503 ovirt-engine-3.6.0.3-1.el7.centos.noarch glusterfs-3.7.5-1.el7.x86_64 High Availability box is checked, Priority = High. 2015-12-10 11:43:34,251 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-42) [5f8883ec] Correlation ID: 5d94dbf7, Job ID: 83159d5a-0ab9-4f1b-afbc-e5c2fcbb6e04, Call Stack: null, Custom Event ID: -1, Message: Failed to migrate VM billjov2.test.j2noc.com to Host ovirt3.test.j2noc.com . Trying to migrate to another Host. ... 2015-12-10 11:43:49,137 INFO [org.ovirt.engine.core.vdsbroker.VmAnalyzer] (DefaultQuartzScheduler_Worker-87) [5f8883ec] VM 'f67a4f38-bb4b-460f-81ea-10ecae60edcc'(billjov2.test.j2noc.com) moved from 'MigratingFrom' --> 'Up' 2015-12-10 11:43:49,518 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-4) [5f8883ec] Correlation ID: 5d94dbf7, Job ID: 83159d5a-0ab9-4f1b-afbc-e5c2fcbb6e04, Call Stack: null, Custom Event ID: -1, Message: Failed to migrate VM billjov2.test.j2noc.com to Host ovirt1.test.j2noc.com . Trying to migrate to another Host. Migrating live works just fine. I haven't found anywhere where it says why it failed when node is down. Any ideas on why it is failing? And why VM's don't start when node is up? Cloud Services for Business www.j2.com j2 | eFax | eVoice | FuseMail | Campaigner | KeepItSafe | Onebox This email, its contents and attachments contain information from j2 Global, Inc. and/or its affiliates which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee(s) only. If you are not an addressee, any disclosure, copy, distribution, or use of the contents of this message is prohibited. If you have received this email in error please notify the sender by reply e-mail and delete the original message and any copies. (c) 2015 j2 Global, Inc. All rights reserved. eFax, eVoice, Campaigner, FuseMail, KeepItSafe, and Onebox are registered trademarks of j2 Global, Inc. and its affiliates.

1 0

oVirt 4.0 wishlist: progress bar in the WebUI
by Kevin COUSIN 10 Dec '15

10 Dec '15

Hi list, It could be great if we can follow process like moving Disk storage, snapshots or VM import in the oVirt Interface, like in VMware or VMM. Regards, Kevin C

4 3

Strange permissions on Hosted Engine HA Agent log files
by Giuseppe Ragusa 10 Dec '15

10 Dec '15

Hi all, I'm installing oVirt (3.6) in self-hosted mode, hyperconverged with GlusterFS (3.7.6). I'm using the oVirt snapshot generated the night between the 18th and 19th of November, 2015. The (single, at the moment) host and the Engine are both CentOS 7.1 fully up-to-date. After ovirt-hosted-engine-setup successful completion, I found the following (about 3 days after setup completed) "anomalies": 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/agent.log 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/agent.log.2015-11-23 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/broker.log 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/broker.log.2015-11-23 The listing above comes from a custom security checking script that gives: "octal permissions" "number of links" "owner" "group" - "absolute pathname" Is the ominous "666" mark actually intended/necessary? ;-) Do I need to open a bugzilla notification for this? Many thanks in advance for your attention. Regards, Giuseppe

3 2

[oVirt 3.5.6] changing RAM of the hosted engine VM
by wodel youchi 10 Dec '15

10 Dec '15

Hi, I have an oVirt 3.5.6 platform using hosted-engine setup. I installed my engine's VM with 2Gb of memory at the beginning, now I want to add 2Gb I've modified /etc/ovirt-hosted-engine/vm.conf on my hypervisors the VM is booting with 4Gb of memory (free -m), but the GUI is still showing 2Gb I tried engine-setup but I get this error [ INFO ] Cleaning async tasks and compensations [ ERROR ] Failed to execute stage 'Setup validation': '36' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20151210124227-xrr3g5.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20151210124820-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed Here is the tailf log 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV OVESETUP_WSP_RPMDISRO_PACKAGES_SETUP=str:'ovirt-engine-setup-plugin-websocket-proxy' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV PACKAGER/keepAliveInterval=int:'30' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV PACKAGER/yumDisabledPlugins=list:'[]' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV PACKAGER/yumEnabledPlugins=list:'[]' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV PACKAGER/yumExpireCache=bool:'True' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV PACKAGER/yumRollback=bool:'True' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV PACKAGER/yumpackagerEnabled=bool:'True' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV SYSTEM/clockMaxGap=int:'5' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV SYSTEM/clockSet=bool:'False' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV SYSTEM/commandPath=str:'/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV SYSTEM/reboot=bool:'False' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV SYSTEM/rebootAllow=bool:'True' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:500 ENV SYSTEM/rebootDeferTime=int:'10' 2015-12-10 12:48:20 DEBUG otopi.context context.dumpEnvironment:504 ENVIRONMENT DUMP - END 2015-12-10 12:48:20 DEBUG otopi.context context._executeMethod:138 Stage pre-terminate METHOD otopi.plugins.otopi.dialog.cli.Plugin._pre_terminate 2015-12-10 12:48:20 DEBUG otopi.context context._executeMethod:144 condition False 2015-12-10 12:48:20 INFO otopi.context context.runSequence:417 Stage: Termination 2015-12-10 12:48:20 DEBUG otopi.context context.runSequence:421 STAGE terminate 2015-12-10 12:48:20 DEBUG otopi.context context._executeMethod:138 Stage terminate METHOD otopi.plugins.ovirt_engine_common.base.core.misc.Plugin._terminate 2015-12-10 12:48:20 ERROR otopi.plugins.ovirt_engine_common.base.core.misc misc._terminate:151 Execution of setup failed 2015-12-10 12:48:20 DEBUG otopi.context context._executeMethod:138 Stage terminate METHOD otopi.plugins.otopi.dialog.human.Plugin._terminate 2015-12-10 12:48:20 DEBUG otopi.context context._executeMethod:138 Stage terminate METHOD otopi.plugins.otopi.dialog.machine.Plugin._terminate 2015-12-10 12:48:20 DEBUG otopi.context context._executeMethod:144 condition False 2015-12-10 12:48:20 DEBUG otopi.context context._executeMethod:138 Stage terminate METHOD otopi.plugins.otopi.core.log.Plugin._terminate - What is the correct way to modify the engine's VM memory Thanks in advance.

2 4

LocalOnHost Multipath Blacklist Fails
by Duckworth, Douglas C 10 Dec '15

10 Dec '15

--_004_BN3PR0301MB123570F47263A543CDACFF2EDAE90BN3PR0301MB1235_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello=0A= =0A= I have a Host with LocalOnHost storage only.=0A= =0A= Trying to blacklist the local disks from multipath:=0A= =0A= PV VG Fmt Attr PSize PFree=0A= /dev/sda1 HostVG lvm2 a-- 8.18t 0=0A= /dev/sdb4 HostVG lvm2 a-- 1.64t 24.00m=0A= =0A= As you can see we need to blacklist these devices:=0A= =0A= 36b8ca3a0ea18e4001a95ba4832bcb7ea=0A= 36b8ca3a0ea18e4001a95b9f82df5609b=0A= =0A= scsi-36b8ca3a0ea18e4001a95b9f82df5609b -> ../../sda=0A= scsi-36b8ca3a0ea18e4001a95b9f82df5609b-part1 -> ../../sda1=0A= scsi-36b8ca3a0ea18e4001a95ba4832bcb7ea -> ../../sdb=0A= scsi-36b8ca3a0ea18e4001a95ba4832bcb7ea-part1 -> ../../sdb1=0A= scsi-36b8ca3a0ea18e4001a95ba4832bcb7ea-part2 -> ../../sdb2=0A= scsi-36b8ca3a0ea18e4001a95ba4832bcb7ea-part3 -> ../../sdb3=0A= scsi-36b8ca3a0ea18e4001a95ba4832bcb7ea-part4 -> ../../sdb4=0A= =0A= After making blacklist changes, you can see in "syslog_errors,"=0A= multipathd does not like my blacklist syntax.=0A= =0A= Do you see errors in the multipath.conf file?=0A= =0A= Thanks=0A= Doug=0A= =0A= -- =0A= Thanks=0A= =0A= Douglas Charles Duckworth=0A= Unix Administrator=0A= Tulane University=0A= Technology Services=0A= 1555 Poydras Ave=0A= NOLA -- 70112=0A= =0A= E: duckd(a)tulane.edu=0A= O: 504-988-9341=0A= F: 504-988-8505=0A= --_004_BN3PR0301MB123570F47263A543CDACFF2EDAE90BN3PR0301MB1235_ Content-Type: text/plain; name="multipath.conf" Content-Description: multipath.conf Content-Disposition: attachment; filename="multipath.conf"; size=1444; creation-date="Thu, 10 Dec 2015 16:18:36 GMT"; modification-date="Thu, 10 Dec 2015 16:18:36 GMT" Content-Transfer-Encoding: base64 IyBSSEVWIFJFVklTSU9OIDEuMQoKZGVmYXVsdHMgewogICAgcG9sbGluZ19pbnRlcnZhbCAgICAg ICAgNQogICAgZ2V0dWlkX2NhbGxvdXQgICAgICAgICAgIi9zYmluL3Njc2lfaWQgLS13aGl0ZWxp c3RlZCAtLXJlcGxhY2Utd2hpdGVzcGFjZSAtLWRldmljZT0vZGV2LyVuIgogICAgbm9fcGF0aF9y ZXRyeSAgICAgICAgICAgZmFpbAogICAgdXNlcl9mcmllbmRseV9uYW1lcyAgICAgbm8KICAgIGZs dXNoX29uX2xhc3RfZGVsICAgICAgIHllcwogICAgZmFzdF9pb19mYWlsX3RtbyAgICAgICAgNQog ICAgZGV2X2xvc3NfdG1vICAgICAgICAgICAgMzAKICAgIG1heF9mZHMgICAgICAgICAgICAgICAg IDQwOTYKfQoKZGV2aWNlcyB7CmRldmljZSB7CiAgICB2ZW5kb3IgICAgICAgICAgICAgICAgICAi SElUQUNISSIKICAgIHByb2R1Y3QgICAgICAgICAgICAgICAgICJERi4qIgogICAgZ2V0dWlkX2Nh bGxvdXQgICAgICAgICAgIi9zYmluL3Njc2lfaWQgLS13aGl0ZWxpc3RlZCAtLXJlcGxhY2Utd2hp dGVzcGFjZSAtLWRldmljZT0vZGV2LyVuIgp9CmRldmljZSB7CiAgICB2ZW5kb3IgICAgICAgICAg ICAgICAgICAiQ09NUEVMTlQiCiAgICBwcm9kdWN0ICAgICAgICAgICAgICAgICAiQ29tcGVsbGVu dCBWb2wiCiAgICBub19wYXRoX3JldHJ5ICAgICAgICAgICBmYWlsCn0KCmJsYWNrbGlzdCB7CiAg ICAgICAgZGV2bm9kZSAiXihyYW18cmF3fGxvb3B8ZmR8bWR8ZG0tfHNyfHNjZHxzdClbMC05XSIK ICAgICAgICBkZXZub2RlICJeaGRbYS16XVtbMC05XV0iCiAgICAgICAgZGV2bm9kZSAiXmNjaXNz IWNbMC05XWRbMC05XSIKICAgICAgICBkZXZub2RlICJec2RhWzAtOV0iCiAgICAgICAgZGV2bm9k ZSAiXnNkYlswLTldIgp9CmRldmljZSB7CiAgICAjIG11bHRpcGF0aC5jb25mLmRlZmF1bHQKICAg IHZlbmRvciAgICAgICAgICAgICAgICAgICJER0MiCiAgICBwcm9kdWN0ICAgICAgICAgICAgICAg ICAiLioiCiAgICBwcm9kdWN0X2JsYWNrbGlzdCAgICAgICAiTFVOWiIKICAgIHBhdGhfZ3JvdXBp bmdfcG9saWN5ICAgICJncm91cF9ieV9wcmlvIgogICAgcGF0aF9jaGVja2VyICAgICAgICAgICAg ImVtY19jbGFyaWlvbiIKICAgIGhhcmR3YXJlX2hhbmRsZXIgICAgICAgICIxIGVtYyIKICAgIHBy aW8gICAgICAgICAgICAgICAgICAgICJlbWMiCiAgICBmYWlsYmFjayAgICAgICAgICAgICAgICBp bW1lZGlhdGUKICAgIHJyX3dlaWdodCAgICAgICAgICAgICAgICJ1bmlmb3JtIgogICAgIyB2ZHNt IHJlcXVpcmVkIGNvbmZpZ3VyYXRpb24KICAgIGdldHVpZF9jYWxsb3V0ICAgICAgICAgICIvc2Jp bi9zY3NpX2lkIC0td2hpdGVsaXN0ZWQgLS1yZXBsYWNlLXdoaXRlc3BhY2UgLS1kZXZpY2U9L2Rl di8lbiIKICAgIGZlYXR1cmVzICAgICAgICAgICAgICAgICIwIgogICAgbm9fcGF0aF9yZXRyeSAg ICAgICAgICAgZmFpbAp9Cn0KCg== --_004_BN3PR0301MB123570F47263A543CDACFF2EDAE90BN3PR0301MB1235_ Content-Type: text/plain; name="dmsetup" Content-Description: dmsetup Content-Disposition: attachment; filename="dmsetup"; size=1309; creation-date="Thu, 10 Dec 2015 16:18:36 GMT"; modification-date="Thu, 10 Dec 2015 16:18:36 GMT" Content-Transfer-Encoding: base64 W3Jvb3RAdHVsaHYycDAxIH5dIyBkbXNldHVwIGluZm8KTmFtZTogICAgICAgICAgICAgIEhvc3RW Ry1Mb2dnaW5nClN0YXRlOiAgICAgICAgICAgICBBQ1RJVkUKUmVhZCBBaGVhZDogICAgICAgIDEw MjQKVGFibGVzIHByZXNlbnQ6ICAgIExJVkUKT3BlbiBjb3VudDogICAgICAgIDEKRXZlbnQgbnVt YmVyOiAgICAgIDAKTWFqb3IsIG1pbm9yOiAgICAgIDI1MywgMwpOdW1iZXIgb2YgdGFyZ2V0czog MQpVVUlEOiBMVk0tbkRoT1k5eERFY1NxbUFzTWg2OXllMjVLYmU1cW1BV0EweW9QUXVXVlNLZlRZ azYwYTU1bGozNkw5dUtoRDRKdAoKTmFtZTogICAgICAgICAgICAgIEhvc3RWRy1Td2FwClN0YXRl OiAgICAgICAgICAgICBBQ1RJVkUKUmVhZCBBaGVhZDogICAgICAgIDEwMjQKVGFibGVzIHByZXNl bnQ6ICAgIExJVkUKT3BlbiBjb3VudDogICAgICAgIDEKRXZlbnQgbnVtYmVyOiAgICAgIDAKTWFq b3IsIG1pbm9yOiAgICAgIDI1MywgMQpOdW1iZXIgb2YgdGFyZ2V0czogMQpVVUlEOiBMVk0tbkRo T1k5eERFY1NxbUFzTWg2OXllMjVLYmU1cW1BV0E0RVlvRFI0cWljMEsxdHlmeUs5c1JoRHRJZGJv MUh2MQoKTmFtZTogICAgICAgICAgICAgIEhvc3RWRy1EYXRhClN0YXRlOiAgICAgICAgICAgICBB Q1RJVkUKUmVhZCBBaGVhZDogICAgICAgIDEwMjQKVGFibGVzIHByZXNlbnQ6ICAgIExJVkUKT3Bl biBjb3VudDogICAgICAgIDEKRXZlbnQgbnVtYmVyOiAgICAgIDAKTWFqb3IsIG1pbm9yOiAgICAg IDI1MywgNApOdW1iZXIgb2YgdGFyZ2V0czogMgpVVUlEOiBMVk0tbkRoT1k5eERFY1NxbUFzTWg2 OXllMjVLYmU1cW1BV0FpdVpIMXhKZmhrbHpQQm1lQUJTbklBcDB5MEZXS1ZiUQoKTmFtZTogICAg ICAgICAgICAgIEhvc3RWRy1Db25maWcKU3RhdGU6ICAgICAgICAgICAgIEFDVElWRQpSZWFkIEFo ZWFkOiAgICAgICAgMTAyNApUYWJsZXMgcHJlc2VudDogICAgTElWRQpPcGVuIGNvdW50OiAgICAg ICAgMQpFdmVudCBudW1iZXI6ICAgICAgMApNYWpvciwgbWlub3I6ICAgICAgMjUzLCAyCk51bWJl ciBvZiB0YXJnZXRzOiAxClVVSUQ6IExWTS1uRGhPWTl4REVjU3FtQXNNaDY5eWUyNUtiZTVxbUFX QWZrT3hJVDdXbDA2RUJ6ZDQ1eE5RTkZhQW5TUVQyc2RkCgpOYW1lOiAgICAgICAgICAgICAgbGl2 ZS1ydwpTdGF0ZTogICAgICAgICAgICAgQUNUSVZFClJlYWQgQWhlYWQ6ICAgICAgICAxMDI0ClRh YmxlcyBwcmVzZW50OiAgICBMSVZFCk9wZW4gY291bnQ6ICAgICAgICAxCkV2ZW50IG51bWJlcjog ICAgICAwCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDAKTnVtYmVyIG9mIHRhcmdldHM6IDEKCg== --_004_BN3PR0301MB123570F47263A543CDACFF2EDAE90BN3PR0301MB1235_ Content-Type: text/plain; name="syslog_errors" Content-Description: syslog_errors Content-Disposition: attachment; filename="syslog_errors"; size=3646; creation-date="Thu, 10 Dec 2015 16:18:37 GMT"; modification-date="Thu, 10 Dec 2015 16:18:37 GMT" Content-Transfer-Encoding: base64 RGVjIDEwIDE2OjA1OjM2IHR1bGh2MnAwMSByb290OiBSRVNUQVJUSU5HIE1VTFRJUEFUSApEZWMg MTAgMTY6MDU6MzkgdHVsaHYycDAxIG11bHRpcGF0aGQ6IGZvcmNlIHF1ZXVlX3dpdGhvdXRfZGFl bW9uIChvcGVyYXRvcikKRGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAwMSBtdWx0aXBhdGhkOiAtLS0t LS0tLXNodXQgZG93bi0tLS0tLS0KRGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAwMSBrZXJuZWw6IGRl dmljZS1tYXBwZXI6IHRhYmxlOiAyNTM6NTogbXVsdGlwYXRoOiBlcnJvciBnZXR0aW5nIGRldmlj ZQpEZWMgMTAgMTY6MDU6MzkgdHVsaHYycDAxIGtlcm5lbDogZGV2aWNlLW1hcHBlcjogaW9jdGw6 IGVycm9yIGFkZGluZyB0YXJnZXQgdG8gdGFibGUKRGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAwMSBt dWx0aXBhdGhkOiBtdWx0aXBhdGguY29uZiBsaW5lIDI2LCBpbnZhbGlkIGtleXdvcmQ6IGJsYWNr bGlzdApEZWMgMTAgMTY6MDU6MzkgdHVsaHYycDAxIG11bHRpcGF0aGQ6IG11bHRpcGF0aC5jb25m IGxpbmUgMjcsIGludmFsaWQga2V5d29yZDogZGV2bm9kZQpEZWMgMTAgMTY6MDU6MzkgdHVsaHYy cDAxIG11bHRpcGF0aGQ6IG11bHRpcGF0aC5jb25mIGxpbmUgMjgsIGludmFsaWQga2V5d29yZDog ZGV2bm9kZQpEZWMgMTAgMTY6MDU6MzkgdHVsaHYycDAxIG11bHRpcGF0aGQ6IG11bHRpcGF0aC5j b25mIGxpbmUgMjksIGludmFsaWQga2V5d29yZDogZGV2bm9kZQpEZWMgMTAgMTY6MDU6MzkgdHVs aHYycDAxIG11bHRpcGF0aGQ6IG11bHRpcGF0aC5jb25mIGxpbmUgMzAsIGludmFsaWQga2V5d29y ZDogZGV2bm9kZQpEZWMgMTAgMTY6MDU6MzkgdHVsaHYycDAxIG11bHRpcGF0aGQ6IG11bHRpcGF0 aC5jb25mIGxpbmUgMzEsIGludmFsaWQga2V5d29yZDogZGV2bm9kZQpEZWMgMTAgMTY6MDU6Mzkg dHVsaHYycDAxIG11bHRpcGF0aGQ6IG11bHRpcGF0aC5jb25mIGxpbmUgMzMsIGludmFsaWQga2V5 d29yZDogZGV2aWNlCkRlYyAxMCAxNjowNTozOSB0dWxodjJwMDEgbXVsdGlwYXRoZDogbXVsdGlw YXRoLmNvbmYgbGluZSAzNSwgaW52YWxpZCBrZXl3b3JkOiB2ZW5kb3IKRGVjIDEwIDE2OjA1OjM5 IHR1bGh2MnAwMSBtdWx0aXBhdGhkOiBtdWx0aXBhdGguY29uZiBsaW5lIDM2LCBpbnZhbGlkIGtl eXdvcmQ6IHByb2R1Y3QKRGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAwMSBtdWx0aXBhdGhkOiBtdWx0 aXBhdGguY29uZiBsaW5lIDM3LCBpbnZhbGlkIGtleXdvcmQ6IHByb2R1Y3RfYmxhY2tsaXN0CkRl YyAxMCAxNjowNTozOSB0dWxodjJwMDEgbXVsdGlwYXRoZDogbXVsdGlwYXRoLmNvbmYgbGluZSAz OCwgaW52YWxpZCBrZXl3b3JkOiBwYXRoX2dyb3VwaW5nX3BvbGljeQpEZWMgMTAgMTY6MDU6Mzkg dHVsaHYycDAxIG11bHRpcGF0aGQ6IG11bHRpcGF0aC5jb25mIGxpbmUgMzksIGludmFsaWQga2V5 d29yZDogcGF0aF9jaGVja2VyCkRlYyAxMCAxNjowNTozOSB0dWxodjJwMDEgbXVsdGlwYXRoZDog bXVsdGlwYXRoLmNvbmYgbGluZSA0MCwgaW52YWxpZCBrZXl3b3JkOiBoYXJkd2FyZV9oYW5kbGVy CkRlYyAxMCAxNjowNTozOSB0dWxodjJwMDEgbXVsdGlwYXRoZDogbXVsdGlwYXRoLmNvbmYgbGlu ZSA0MSwgaW52YWxpZCBrZXl3b3JkOiBwcmlvCkRlYyAxMCAxNjowNTozOSB0dWxodjJwMDEgbXVs dGlwYXRoZDogbXVsdGlwYXRoLmNvbmYgbGluZSA0MiwgaW52YWxpZCBrZXl3b3JkOiBmYWlsYmFj awpEZWMgMTAgMTY6MDU6MzkgdHVsaHYycDAxIG11bHRpcGF0aGQ6IG11bHRpcGF0aC5jb25mIGxp bmUgNDMsIGludmFsaWQga2V5d29yZDogcnJfd2VpZ2h0CkRlYyAxMCAxNjowNTozOSB0dWxodjJw MDEgbXVsdGlwYXRoZDogbXVsdGlwYXRoLmNvbmYgbGluZSA0NSwgaW52YWxpZCBrZXl3b3JkOiBn ZXR1aWRfY2FsbG91dApEZWMgMTAgMTY6MDU6MzkgdHVsaHYycDAxIG11bHRpcGF0aGQ6IG11bHRp cGF0aC5jb25mIGxpbmUgNDYsIGludmFsaWQga2V5d29yZDogZmVhdHVyZXMKRGVjIDEwIDE2OjA1 OjM5IHR1bGh2MnAwMSBtdWx0aXBhdGhkOiBtdWx0aXBhdGguY29uZiBsaW5lIDQ3LCBpbnZhbGlk IGtleXdvcmQ6IG5vX3BhdGhfcmV0cnkKRGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAwMSBtdWx0aXBh dGhkOiB1bm1hdGNoZWQgJ30nIGF0IGxpbmUgNDggb2YgY29uZmlnIGZpbGUKRGVjIDEwIDE2OjA1 OjM5IHR1bGh2MnAwMSBtdWx0aXBhdGhkOiBtdWx0aXBhdGguY29uZiBsaW5lIDQ4LCBpbnZhbGlk IGtleXdvcmQ6IH0KRGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAwMSBtdWx0aXBhdGhkOiB1bm1hdGNo ZWQgJ30nIGF0IGxpbmUgNDkgb2YgY29uZmlnIGZpbGUKRGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAw MSBtdWx0aXBhdGhkOiBtdWx0aXBhdGguY29uZiBsaW5lIDQ5LCBpbnZhbGlkIGtleXdvcmQ6IH0K RGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAwMSBtdWx0aXBhdGhkOiAzNmI4Y2EzYTBlYTE4ZTQwMDFh OTViOWY4MmRmNTYwOWI6IGlnbm9yaW5nIG1hcApEZWMgMTAgMTY6MDU6MzkgdHVsaHYycDAxIGtl cm5lbDogZGV2aWNlLW1hcHBlcjogdGFibGU6IDI1Mzo1OiBtdWx0aXBhdGg6IGVycm9yIGdldHRp bmcgZGV2aWNlCkRlYyAxMCAxNjowNTozOSB0dWxodjJwMDEga2VybmVsOiBkZXZpY2UtbWFwcGVy OiBpb2N0bDogZXJyb3IgYWRkaW5nIHRhcmdldCB0byB0YWJsZQpEZWMgMTAgMTY6MDU6MzkgdHVs aHYycDAxIG11bHRpcGF0aGQ6IDM2YjhjYTNhMGVhMThlNDAwMWE5NWJhNDgzMmJjYjdlYTogaWdu b3JpbmcgbWFwCkRlYyAxMCAxNjowNTozOSB0dWxodjJwMDEgdWRldmQtd29ya1s3NzIxXTogcmVz c2l6ZSAxMDI0IHRvbyBzaG9ydApEZWMgMTAgMTY6MDU6MzkgdHVsaHYycDAxIG11bHRpcGF0aGQ6 IHBhdGggY2hlY2tlcnMgc3RhcnQgdXAKRGVjIDEwIDE2OjA1OjM5IHR1bGh2MnAwMSB1ZGV2ZC13 b3JrWzc3MTZdOiByZXNzaXplIDEwMjQgdG9vIHNob3J0CkRlYyAxMCAxNjoxMDowMCB0dWxodjJw MDEgcnBjLnN0YXRkWzM4Nzc1XTogVmVyc2lvbiAxLjIuMyBzdGFydGluZwpEZWMgMTAgMTY6MTA6 MDAgdHVsaHYycDAxIHJwYy5zdGF0ZFszODc3NV06IEZsYWdzOiBUSS1SUEMgCkRlYyAxMCAxNjox MDowMCB0dWxodjJwMDEgcnBjLnN0YXRkWzM4Nzc1XTogZmFpbGVkIHRvIGNyZWF0ZSBSUEMgbGlz dGVuZXJzLCBleGl0aW5nCkRlYyAxMCAxNjoxMDowMiB0dWxodjJwMDEga2VybmVsOiBkZXZpY2Ut bWFwcGVyOiB0YWJsZTogMjUzOjU6IG11bHRpcGF0aDogZXJyb3IgZ2V0dGluZyBkZXZpY2UKRGVj IDEwIDE2OjEwOjAyIHR1bGh2MnAwMSBrZXJuZWw6IGRldmljZS1tYXBwZXI6IGlvY3RsOiBlcnJv ciBhZGRpbmcgdGFyZ2V0IHRvIHRhYmxlCkRlYyAxMCAxNjoxMDowMiB0dWxodjJwMDEga2VybmVs OiBkZXZpY2UtbWFwcGVyOiB0YWJsZTogMjUzOjU6IG11bHRpcGF0aDogZXJyb3IgZ2V0dGluZyBk ZXZpY2UKRGVjIDEwIDE2OjEwOjAyIHR1bGh2MnAwMSBrZXJuZWw6IGRldmljZS1tYXBwZXI6IGlv Y3RsOiBlcnJvciBhZGRpbmcgdGFyZ2V0IHRvIHRhYmxlCkRlYyAxMCAxNjoxMDowMiB0dWxodjJw MDEgdWRldmQtd29ya1s3NzIxXTogcmVzc2l6ZSAxMDI0IHRvbyBzaG9ydApEZWMgMTAgMTY6MTA6 MDIgdHVsaHYycDAxIHVkZXZkLXdvcmtbNzcxNl06IHJlc3NpemUgMTAyNCB0b28gc2hvcnQKCg== --_004_BN3PR0301MB123570F47263A543CDACFF2EDAE90BN3PR0301MB1235_--

1 1

hot plug memory in el7
by Nathanaël Blanchet 10 Dec '15

10 Dec '15

Hi all, I may miss something but according to http://www.ovirt.org/Features/Hot_Plug_Memory, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7. I found this : http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html, and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported libvirtd? Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)? Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web. Maybe the feature has been postponed to a 3.6.z release? Thank you for your help

5 21

Migration failed
by Massimo Mad 10 Dec '15

10 Dec '15

Hi Michal, This is my configuration end the error: 1 start to migrate the vm from cluster in centos 6.x to cluster un centos bare-metal 7.x Migration started (VM: Spacewalk, Source: ovirtxx3, Destination: ovirtxx5, User: admin@internal). 2 first error: Migration failed due to Error: Fatal error during migration. Trying to migrate to another Host (VM: Spacewalkp, Source: ovirtxx03, Destination: ovirtxx05). 3 Second error: Migration failed, No available host found (VM: Spacewalk, Source: ovirtxx3). Regards Massimo

2 1

engine-setup failed because of postgres 9.4
by Fabrice Bacchella 10 Dec '15

10 Dec '15

--Apple-Mail=_ED6F23F2-EAD4-4794-9104-AE8484B6590A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm on a RHEL 7, trying to install a ovirt 3.6.0.3. The database used is on a remote server, using a postgres 9.4. The backup of the previous database fails with : 2015-12-10 12:04:13 DEBUG = otopi.**FILTERED**_engine_setup.engine_common.database = database.backup:661 db backup res {'result': [{'stderr': 'pg_dump: = server version: 9.4.5; pg_dump version: 9.2.14\npg_dump: aborting = because of server version mismatch\n', 'rc': 1}], 'stdout': ''} But the good pg_dump is in the path: ~# type pg_dump pg_dump is /usr/pgsql-9.4/bin/pg_dump Although in the log file: 2015-12-10 12:40:19 DEBUG otopi.context context.dumpEnvironment:510 ENV = COMMAND/pg_dump=3Dstr:'/bin/pg_dump' Why ? How can I enforce the use of the latest pg_dump without rewrinting = the '/bin/pg_dump' which is owned by the official postgres package ? --Apple-Mail=_ED6F23F2-EAD4-4794-9104-AE8484B6590A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">I'm on a RHEL 7, trying to install a ovirt 3.6.0.3.<div = class=3D""><br class=3D""></div><div class=3D"">The database used is on = a remote server, using a postgres 9.4.</div><div class=3D""><br = class=3D""></div><div class=3D"">The backup of the previous database = fails with :</div><div class=3D""><div style=3D"margin: 0px; font-size: = 11px; font-family: Menlo;" class=3D"">2015-12-10 12:04:13 DEBUG = otopi.**FILTERED**_engine_setup.engine_common.database = database.backup:661 db backup res {'result': [{'stderr': 'pg_dump: = server version: 9.4.5; pg_dump version: 9.2.14\npg_dump: aborting = because of server version mismatch\n', 'rc': 1}], 'stdout': = ''}</div></div><div class=3D""><br class=3D""></div><div class=3D"">But = the good pg_dump is in the path:</div><div class=3D""><br = class=3D""></div><div class=3D""><div style=3D"margin: 0px; font-size: = 11px; font-family: Menlo;" class=3D"">~# type pg_dump</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">pg_dump is /usr/pgsql-9.4/bin/pg_dump</div></div><div = class=3D""><br class=3D""></div><div class=3D"">Although in the log = file:</div><div class=3D""><br class=3D""></div><div class=3D""><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">2015-12-10 12:40:19 DEBUG otopi.context = context.dumpEnvironment:510 ENV COMMAND/<span = style=3D"font-variant-ligatures: no-common-ligatures; color: #ffffff; = background-color: #000000" class=3D"">pg_dump</span>=3Dstr:'/bin/<span = style=3D"font-variant-ligatures: no-common-ligatures; color: #ffffff; = background-color: #000000" class=3D"">pg_dump</span>'</div></div><div = class=3D""><br class=3D""></div><div class=3D"">Why ? How can I enforce = the use of the latest pg_dump without rewrinting the <span = style=3D"font-family: Menlo; font-size: 11px;" = class=3D"">'/bin/</span><span style=3D"font-family: Menlo; font-size: = 11px; color: rgb(255, 255, 255); background-color: rgb(0, 0, 0);" = class=3D"">pg_dump</span><span style=3D"font-family: Menlo; font-size: = 11px;" class=3D"">'</span> which is owned by the official postgres = package ?</div><div class=3D""><br class=3D""></div></body></html>= --Apple-Mail=_ED6F23F2-EAD4-4794-9104-AE8484B6590A--

2 2