- Users - oVirt List Archives

ovirt-hosted-engine state transition messages
by Jim Kusznir 23 Jul '17

23 Jul '17

Hello: I find that I often get random-seeming messages. A lot of them mention "ReintializeFSM", but I also get engine down, engine start, etc. messages. All the time, nothing appears to be happening on the cluster, and I rarely can find anything wrong or any trigger/cause. Is this normal? What causes this (beyond obvious hardware issues / hosts rebooting)? Most of the time when I get these, my cluster is going along smoothly, and nothing (not even administrative access) is interrupted. Could ISP issues cause these messages to be generated? Thanks! --Jim

5 7

Re: [ovirt-users] workflow suggestion for the creating and destroying the VMs?
by Karli Sjöberg 21 Jul '17

21 Jul '17

3 4

ovirt on sdcard?
by Lionel Caignec 21 Jul '17

21 Jul '17

Hi, i'm planning to install some new hypervisors (ovirt) and i'm wondering if it's possible to get it installed on sdcard. I know there is write limitation on this kind of storage device. Is it a viable solution? there is somewhere some tuto about tuning ovirt on this kind of storage? Thanks -- Lionel

5 5

workflow suggestion for the creating and destroying the VMs?
by Arman Khalatyan 20 Jul '17

20 Jul '17

Hi, Can some one share an experience with dynamic creating and removing VMs based on the load? Currently I am just creating with the python SDK a clone of the apache worker, are there way to copy some config files to the VM before starting it ? Thanks, Arman.

1 0

Ovirt Engine Reports oVirt >= 4
by Victor José Acosta Domínguez 20 Jul '17

20 Jul '17

Hello everyone, quick question, is ovirt-engine-reports deprecated on oVirt >= 4? Because i don't find ovirt-engine-reports package on oVirt's 4 repo. Regards Victor Acosta

2 1

Problems with oVirt3.5 engine + CentOS6 Host
by Antonio Sallés 20 Jul '17

20 Jul '17

Hello friends, Since yesterday I've been trying to register a CentOS 6 host on an oVirt 3.5 engine, but I have not been able to finish the process successfully. I copied the ssh keys and lifted vdsmd without problems, then tried via firefox with admin portal to integrate it, but without success. Could you help me? This is the error ... Thank you very much! [root@ovirt ovirt-engine]# tail -f -n0 /var/log/ovirt-engine/engine.log 2017-07-19 17:21:25,078 WARN [org.ovirt.engine.core.compat.backendcompat.PropertyInfo] (ajp--127.0.0.1-8702-3) Unable to get value of property: vdsName for class org.ovirt.engine.core.common.businessentities.VdsStatic 2017-07-19 17:21:25,079 WARN [org.ovirt.engine.core.compat.backendcompat.PropertyInfo] (ajp--127.0.0.1-8702-3) Unable to get value of property: vdsName for class org.ovirt.engine.core.common.businessentities.VdsStatic 2017-07-19 17:21:25,079 INFO [org.ovirt.engine.core.bll.InstallVdsCommand] (ajp--127.0.0.1-8702-3) [7a173239] Running command: InstallVdsCommand internal: false. Entities affected : ID: 9b82c66f-46c8-49dc-8ab3-2b5e27c7bdd5 Type: VDSAction group EDIT_HOST_CONFIGURATION with role type ADMIN 2017-07-19 17:21:25,088 WARN [org.ovirt.engine.core.compat.backendcompat.PropertyInfo] (ajp--127.0.0.1-8702-3) Unable to get value of property: vdsName for class org.ovirt.engine.core.common.businessentities.VdsStatic 2017-07-19 17:21:25,088 WARN [org.ovirt.engine.core.compat.backendcompat.PropertyInfo] (ajp--127.0.0.1-8702-3) Unable to get value of property: vdsName for class org.ovirt.engine.core.common.businessentities.VdsStatic 2017-07-19 17:21:25,090 INFO [org.ovirt.engine.core.bll.InstallVdsInternalCommand] (ajp--127.0.0.1-8702-3) [7a173239] Lock Acquired to object EngineLock [exclusiveLocks= key: 9b82c66f-46c8-49dc-8ab3-2b5e27c7bdd5 value: VDS , sharedLocks= ] 2017-07-19 17:21:25,093 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-3) [7a173239] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Failed to verify Power Management configuration for Host kvm2.segic.cl. 2017-07-19 17:21:25,095 INFO [org.ovirt.engine.core.bll.InstallVdsInternalCommand] (org.ovirt.thread.pool-8-thread-32) [7a173239] Running command: InstallVdsInternalCommand internal: true. Entities affected : ID: 9b82c66f-46c8-49dc-8ab3-2b5e27c7bdd5 Type: VDS 2017-07-19 17:21:25,095 INFO [org.ovirt.engine.core.bll.InstallVdsInternalCommand] (org.ovirt.thread.pool-8-thread-32) [7a173239] Before Installation host 9b82c66f-46c8-49dc-8ab3-2b5e27c7bdd5, kvm2.segic.cl 2017-07-19 17:21:25,105 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-3) [7a173239] Correlation ID: 7a173239, Call Stack: null, Custom Event ID: -1, Message: Host kvm2.segic.cl configuration was updated by admin@internal. 2017-07-19 17:21:25,106 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (org.ovirt.thread.pool-8-thread-32) [7a173239] START, SetVdsStatusVDSCommand(HostName = kvm2.segic.cl, HostId = 9b82c66f-46c8-49dc-8ab3-2b5e27c7bdd5, status=Installing, nonOperationalReason=NONE, stopSpmFailureLogged=false), log id: 8c3992 2017-07-19 17:21:25,109 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (org.ovirt.thread.pool-8-thread-32) [7a173239] FINISH, SetVdsStatusVDSCommand, log id: 8c3992 2017-07-19 17:21:25,133 INFO [org.ovirt.engine.core.bll.InstallerMessages] (org.ovirt.thread.pool-8-thread-32) [7a173239] Installation 158.170.39.12: Connected to host 158.170.39.12 with SSH key fingerprint: 16:2b:79:78:60:ea:d2:24:0a:8d:7c:2f:2e:8e:20:51 2017-07-19 17:21:25,138 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-32) [7a173239] Correlation ID: 7a173239, Call Stack: null, Custom Event ID: -1, Message: Installing Host kvm2.segic.cl. Connected to host 158.170.39.12 with SSH key fingerprint: 16:2b:79:78:60:ea:d2:24:0a:8d:7c:2f:2e:8e:20:51. 2017-07-19 17:21:25,223 INFO [org.ovirt.engine.core.bll.VdsDeploy] (org.ovirt.thread.pool-8-thread-32) [7a173239] Installation of 158.170.39.12. Executing command via SSH umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; 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 2017-07-19 17:21:25,223 INFO [org.ovirt.engine.core.utils.archivers.tar.CachedTar] (org.ovirt.thread.pool-8-thread-32) Tarball '/var/cache/ovirt-engine/ovirt-host-deploy.tar' refresh 2017-07-19 17:21:25,254 INFO [org.ovirt.engine.core.uutils.ssh.SSHDialog] (org.ovirt.thread.pool-8-thread-32) SSH execute root(a)158.170.39.12 'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/setup DIALOG/dialect=str:machine DIALOG/customization=bool:True' 2017-07-19 17:21:25,351 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (VdsDeploy) Error during deploy dialog: java.lang.NullPointerException at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:835) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy.access$2000(VdsDeploy.java:83) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy$51.run(VdsDeploy.java:969) [bll.jar:] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.7.0_141] 2017-07-19 17:21:25,353 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (org.ovirt.thread.pool-8-thread-32) [7a173239] Error during host 158.170.39.12 install: java.lang.NullPointerException at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:835) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy.access$2000(VdsDeploy.java:83) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy$51.run(VdsDeploy.java:969) [bll.jar:] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.7.0_141] 2017-07-19 17:21:25,354 ERROR [org.ovirt.engine.core.bll.InstallerMessages] (org.ovirt.thread.pool-8-thread-32) [7a173239] Installation 158.170.39.12: null 2017-07-19 17:21:25,357 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-32) [7a173239] Correlation ID: 7a173239, Call Stack: null, Custom Event ID: -1, Message: Failed to install Host kvm2.segic.cl. <UNKNOWN>. 2017-07-19 17:21:25,357 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (org.ovirt.thread.pool-8-thread-32) [7a173239] Error during host 158.170.39.12 install, prefering first exception: java.lang.NullPointerException at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:835) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy.access$2000(VdsDeploy.java:83) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy$51.run(VdsDeploy.java:969) [bll.jar:] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.7.0_141] 2017-07-19 17:21:25,358 ERROR [org.ovirt.engine.core.bll.InstallVdsInternalCommand] (org.ovirt.thread.pool-8-thread-32) [7a173239] Host installation failed for host 9b82c66f-46c8-49dc-8ab3-2b5e27c7bdd5, kvm2.segic.cl.: java.lang.NullPointerException at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:835) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy.access$2000(VdsDeploy.java:83) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy$51.run(VdsDeploy.java:969) [bll.jar:] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.7.0_141] 2017-07-19 17:21:25,359 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (org.ovirt.thread.pool-8-thread-32) [7a173239] START, SetVdsStatusVDSCommand(HostName = kvm2.segic.cl, HostId = 9b82c66f-46c8-49dc-8ab3-2b5e27c7bdd5, status=InstallFailed, nonOperationalReason=NONE, stopSpmFailureLogged=false), log id: 5c71c632 2017-07-19 17:21:25,362 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (org.ovirt.thread.pool-8-thread-32) [7a173239] FINISH, SetVdsStatusVDSCommand, log id: 5c71c632 2017-07-19 17:21:25,365 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-32) [7a173239] Correlation ID: 7a173239, Call Stack: null, Custom Event ID: -1, Message: Host kvm2.segic.cl installation failed. Please refer to /var/log/ovirt-engine/engine.log and log logs under /var/log/ovirt-engine/host-deploy/ for further details.. 2017-07-19 17:21:25,365 INFO [org.ovirt.engine.core.bll.InstallVdsInternalCommand] (org.ovirt.thread.pool-8-thread-32) [7a173239] Lock freed to object EngineLock [exclusiveLocks= key: 9b82c66f-46c8-49dc-8ab3-2b5e27c7bdd5 value: VDS , sharedLocks= ] -- Antonio Salles | Fedora Ambassador

1 0

Re: [ovirt-users] Host stuck unresponsive after Network Outage
by Pavel Gashev 19 Jul '17

19 Jul '17

--_000_90D58F04AB4E44D98CF3C90FDCB546C1acroniscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW50aG9ueSwNCg0KT3V0cHV0IG9mIOKAnHN5c3RlbWN0bCBzdGF0dXMgLWwgdmRzbS1uZXR3b3Jr 4oCdIHdvdWxkIGhlbHAuDQoNCg0KRnJvbTogPHVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnPiBvbiBi ZWhhbGYgb2YgIkFudGhvbnkuRmlsbG1vcmUiIDxBbnRob255LkZpbGxtb3JlQHRhcmdldC5jb20+ DQpEYXRlOiBUdWVzZGF5LCAxOCBKdWx5IDIwMTcgYXQgMTg6MTMNClRvOiAidXNlcnNAb3ZpcnQu b3JnIiA8dXNlcnNAb3ZpcnQub3JnPg0KQ2M6ICJCcmFuZG9uLk1hcmtncmFmIiA8QnJhbmRvbi5N YXJrZ3JhZkB0YXJnZXQuY29tPiwgIlNhbmRlZXAuTWVuZGlyYXR0YSIgPFNhbmRlZXAuTWVuZGly YXR0YUB0YXJnZXQuY29tPg0KU3ViamVjdDogW292aXJ0LXVzZXJzXSBIb3N0IHN0dWNrIHVucmVz cG9uc2l2ZSBhZnRlciBOZXR3b3JrIE91dGFnZQ0KDQpIZXkgT3ZpcnQgVXNlcnMgYW5kIFRlYW0s DQoNCkkgaGF2ZSBhIGhvc3QgdGhhdCBJIGFtIHVuYWJsZSB0byByZWNvdmVyIHBvc3QgYSBuZXR3 b3JrIG91dGFnZS4gIFRoZSBob3N0IGlzIHN0dWNrIGluIHVucmVzcG9uc2l2ZSBtb2RlLCBldmVu IHRob3VnaCB0aGUgaG9zdCBpcyBvbiB0aGUgbmV0d29yaywgYWJsZSB0byBTU0ggYW5kIHNlZW1z IHRvIGJlIGhlYWx0aHkuICBJ4oCZdmUgdHJpZWQgc2V2ZXJhbCB0aGluZ3MgdG8gcmVjb3ZlciB0 aGUgaG9zdCBpbiBPdmlydCwgYnV0IGhhdmUgaGFkIG5vIHN1Y2Nlc3Mgc28gZmFyLiAgSeKAmWQg bGlrZSB0byByZWFjaCBvdXQgdG8gdGhlIGNvbW11bml0eSBiZWZvcmUgYmxvd2luZyBhd2F5IGFu ZCByZWJ1aWxkaW5nIHRoZSBob3N0Lg0KDQpFbnZpcm9ubWVudDogSSBoYXZlIGFuIE92ZW5naW5l IHNlcnZlciB3aXRoIGFib3V0IDI2IERhdGFjZW50ZXJzLCB3aXRoIDIgdG8gMyBob3N0cyBwZXIg RGF0YWNlbnRlci4gIE15IE92ZW5naW5lIHNlcnZlciBpcyBob3N0ZWQgY2VudHJhbGx5LCB3aXRo IG15IGhvc3RzIGJlaW5nIGJhcmUtbWV0YWwgYW5kIGRpc3RyaWJ1dGVkIHRocm91Z2hvdXQgbXkg ZW52aXJvbm1lbnQuICAgIE92ZW5naW5lIGlzIHZlcnNpb24gNC4wLjYuDQoNCldoYXQgSeKAmXZl IHRyaWVkOiBwdXQgaW50byBtYWludGVuYW5jZSBtb2RlLCByZWJvb3RlZCB0aGUgaG9zdC4gIENv bmZpcm1lZCBob3N0IHdhcyByZWJvb3RlZCBhbmQgdHJpZWQgdG8gYWN0aXZlLCBnb2VzIGJhY2sg dG8gdW5yZXNwb25zaXZlLiAgIEF0dGVtcHRlZCBhIHJlaW5zdGFsbCwgd2hpY2ggZmFpbHMuDQoN CkNoZWNraW5nIGZyb20gdGhlIGhvc3QgcGVyc3BlY3RpdmUsIEkgY2FuIHNlZSB0aGUgZm9sbG93 aW5nIHByb2JsZW1zOg0KDQpbYm94bmFtZX5dIyBzeXN0ZW1jdGwgc3RhdHVzIHZkc21kDQril48g dmRzbWQuc2VydmljZSAtIFZpcnR1YWwgRGVza3RvcCBTZXJ2ZXIgTWFuYWdlcg0KICAgTG9hZGVk OiBsb2FkZWQgKC91c3IvbGliL3N5c3RlbWQvc3lzdGVtL3Zkc21kLnNlcnZpY2U7IGVuYWJsZWQ7 IHZlbmRvciBwcmVzZXQ6IGVuYWJsZWQpDQogICBBY3RpdmU6IGluYWN0aXZlIChkZWFkKQ0KDQpK dWwgMTQgMTI6MzQ6MjggYm94bmFtZSBzeXN0ZW1kWzFdOiBEZXBlbmRlbmN5IGZhaWxlZCBmb3Ig VmlydHVhbCBEZXNrdG9wIFNlcnZlciBNYW5hZ2VyLg0KSnVsIDE0IDEyOjM0OjI4IGJveG5hbWUg c3lzdGVtZFsxXTogSm9iIHZkc21kLnNlcnZpY2Uvc3RhcnQgZmFpbGVkIHdpdGggcmVzdWx0ICdk ZXBlbmRlbmN5Jy4NCg0KR29pbmcgYSBiaXQgZGVlcGVyLCB0aGUgcmVzdWx0cyBvZiBqb3VybmFs Y3RsIOKAk3hlOg0KDQpbcm9vdEBib3huYW1lIH5dIyBqb3VybmFsY3RsIC14ZQ0KLS0gRGVmaW5l ZC1CeTogc3lzdGVtZA0KLS0gU3VwcG9ydDogaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N5c3RlbWQtZGV2ZWwNCi0tDQotLSBVbml0IGxpYnZpcnRkLnNlcnZp Y2UgaGFzIGJlZ3VuIHNodXR0aW5nIGRvd24uDQpKdWwgMTggMDk6MDc6MzEgYm94bmFtZSBzeXN0 ZW1kWzFdOiBTdG9wcGVkIFZpcnR1YWxpemF0aW9uIGRhZW1vbi4NCi0tIFN1YmplY3Q6IFVuaXQg bGlidmlydGQuc2VydmljZSBoYXMgZmluaXNoZWQgc2h1dHRpbmcgZG93bg0KLS0gRGVmaW5lZC1C eTogc3lzdGVtZA0KLS0gU3VwcG9ydDogaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWls bWFuL2xpc3RpbmZvL3N5c3RlbWQtZGV2ZWwNCi0tDQotLSBVbml0IGxpYnZpcnRkLnNlcnZpY2Ug aGFzIGZpbmlzaGVkIHNodXR0aW5nIGRvd24uDQpKdWwgMTggMDk6MDc6MzEgYm94bmFtZSBzeXN0 ZW1kWzFdOiBSZWxvYWRpbmcuDQpKdWwgMTggMDk6MDc6MzEgYm94bmFtZSBzeXN0ZW1kWzFdOiBC aW5kaW5nIHRvIElQdjYgYWRkcmVzcyBub3QgYXZhaWxhYmxlIHNpbmNlIGtlcm5lbCBkb2VzIG5v dCBzdXBwb3J0IElQdjYuDQpKdWwgMTggMDk6MDc6MzEgYm94bmFtZSBzeXN0ZW1kWzFdOiBbL3Vz ci9saWIvc3lzdGVtZC9zeXN0ZW0vcnBjYmluZC5zb2NrZXQ6Nl0gRmFpbGVkIHRvIHBhcnNlIGFk ZHJlc3MgdmFsdWUsIGlnbm9yaW5nOiBbOjoNCkp1bCAxOCAwOTowNzozMSBib3huYW1lIHN5c3Rl bWRbMV06IFN0YXJ0ZWQgQXV4aWxpYXJ5IHZkc20gc2VydmljZSBmb3IgcnVubmluZyBoZWxwZXIg ZnVuY3Rpb25zIGFzIHJvb3QuDQotLSBTdWJqZWN0OiBVbml0IHN1cGVydmRzbWQuc2VydmljZSBo YXMgZmluaXNoZWQgc3RhcnQtdXANCi0tIERlZmluZWQtQnk6IHN5c3RlbWQNCi0tIFN1cHBvcnQ6 IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9zeXN0ZW1kLWRl dmVsDQotLQ0KLS0gVW5pdCBzdXBlcnZkc21kLnNlcnZpY2UgaGFzIGZpbmlzaGVkIHN0YXJ0aW5n IHVwLg0KLS0NCi0tIFRoZSBzdGFydC11cCByZXN1bHQgaXMgZG9uZS4NCkp1bCAxOCAwOTowNzoz MSBib3huYW1lIHN5c3RlbWRbMV06IFN0YXJ0aW5nIEF1eGlsaWFyeSB2ZHNtIHNlcnZpY2UgZm9y IHJ1bm5pbmcgaGVscGVyIGZ1bmN0aW9ucyBhcyByb290Li4uDQotLSBTdWJqZWN0OiBVbml0IHN1 cGVydmRzbWQuc2VydmljZSBoYXMgYmVndW4gc3RhcnQtdXANCi0tIERlZmluZWQtQnk6IHN5c3Rl bWQNCi0tIFN1cHBvcnQ6IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9zeXN0ZW1kLWRldmVsDQotLQ0KLS0gVW5pdCBzdXBlcnZkc21kLnNlcnZpY2UgaGFzIGJl Z3VuIHN0YXJ0aW5nIHVwLg0KSnVsIDE4IDA5OjA3OjMxIGJveG5hbWUgc3lzdGVtZFsxXTogU3Rh cnRpbmcgVmlydHVhbGl6YXRpb24gZGFlbW9uLi4uDQotLSBTdWJqZWN0OiBVbml0IGxpYnZpcnRk LnNlcnZpY2UgaGFzIGJlZ3VuIHN0YXJ0LXVwDQotLSBEZWZpbmVkLUJ5OiBzeXN0ZW1kDQotLSBT dXBwb3J0OiBodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vc3lz dGVtZC1kZXZlbA0KLS0NCi0tIFVuaXQgbGlidmlydGQuc2VydmljZSBoYXMgYmVndW4gc3RhcnRp bmcgdXAuDQpKdWwgMTggMDk6MDc6MzIgYm94bmFtZSBzeXN0ZW1kWzFdOiBTdGFydGVkIFZpcnR1 YWxpemF0aW9uIGRhZW1vbi4NCi0tIFN1YmplY3Q6IFVuaXQgbGlidmlydGQuc2VydmljZSBoYXMg ZmluaXNoZWQgc3RhcnQtdXANCi0tIERlZmluZWQtQnk6IHN5c3RlbWQNCi0tIFN1cHBvcnQ6IGh0 dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9zeXN0ZW1kLWRldmVs DQotLQ0KLS0gVW5pdCBsaWJ2aXJ0ZC5zZXJ2aWNlIGhhcyBmaW5pc2hlZCBzdGFydGluZyB1cC4N Ci0tDQotLSBUaGUgc3RhcnQtdXAgcmVzdWx0IGlzIGRvbmUuDQpKdWwgMTggMDk6MDc6MzIgYm94 bmFtZSBzeXN0ZW1kWzFdOiBTdGFydGluZyBWaXJ0dWFsIERlc2t0b3AgU2VydmVyIE1hbmFnZXIg bmV0d29yayByZXN0b3JhdGlvbi4uLg0KLS0gU3ViamVjdDogVW5pdCB2ZHNtLW5ldHdvcmsuc2Vy dmljZSBoYXMgYmVndW4gc3RhcnQtdXANCi0tIERlZmluZWQtQnk6IHN5c3RlbWQNCi0tIFN1cHBv cnQ6IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9zeXN0ZW1k LWRldmVsDQotLQ0KLS0gVW5pdCB2ZHNtLW5ldHdvcmsuc2VydmljZSBoYXMgYmVndW4gc3RhcnRp bmcgdXAuDQpsaW5lcyAyNzUxLTI3OTcvMjc5NyAoRU5EKQ0KDQpEb2VzIHRoZSBjb21tdW5pdHkg aGF2ZSBzdWdnZXN0aW9ucyBvbiB3aGF0IGNhbiBiZSBkb25lIG5leHQgdG8gcmVjb3ZlciB0aGlz IGhvc3Qgd2l0aGluIE92aXJ0PyAgSSBjYW4gcHJvdmlkZSBhZGRpdGlvbmFsIGxvZyBkdW1wcyBh cyBuZWVkZWQsIHBsZWFzZSBpbmZvcm0gd2l0aCB3aGF0IHlvdSBuZWVkIHRvIGFzc2lzdCBmdXJ0 aGVyLg0KDQpUaGFuayB5b3UsDQpUb255DQoNCg== --_000_90D58F04AB4E44D98CF3C90FDCB546C1acroniscom_ Content-Type: text/html; charset="utf-8" Content-ID: <F68C33CB1CFBDD49B0C6277F306B7E68(a)acronis.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpD YWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6 dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QW50aG9ueSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+T3V0 cHV0IG9mIOKAnHN5c3RlbWN0bCBzdGF0dXMgLWwgdmRzbS1uZXR3b3Jr4oCdIHdvdWxkIGhlbHAu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZsdDt1c2Vycy1ib3Vu Y2VzQG92aXJ0Lm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90O0FudGhvbnkuRmlsbG1vcmUmcXVv dDsgJmx0O0FudGhvbnkuRmlsbG1vcmVAdGFyZ2V0LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VHVlc2RheSwgMTggSnVseSAyMDE3IGF0IDE4OjEzPGJyPg0KPGI+VG86IDwvYj4mcXVvdDt1c2Vy c0BvdmlydC5vcmcmcXVvdDsgJmx0O3VzZXJzQG92aXJ0Lm9yZyZndDs8YnI+DQo8Yj5DYzogPC9i PiZxdW90O0JyYW5kb24uTWFya2dyYWYmcXVvdDsgJmx0O0JyYW5kb24uTWFya2dyYWZAdGFyZ2V0 LmNvbSZndDssICZxdW90O1NhbmRlZXAuTWVuZGlyYXR0YSZxdW90OyAmbHQ7U2FuZGVlcC5NZW5k aXJhdHRhQHRhcmdldC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltvdmlydC11c2Vyc10g SG9zdCBzdHVjayB1bnJlc3BvbnNpdmUgYWZ0ZXIgTmV0d29yayBPdXRhZ2U8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGV5IE92aXJ0IFVzZXJzIGFu ZCBUZWFtLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYSBob3N0IHRoYXQgSSBhbSB1 bmFibGUgdG8gcmVjb3ZlciBwb3N0IGEgbmV0d29yayBvdXRhZ2UuJm5ic3A7IFRoZSBob3N0IGlz IHN0dWNrIGluIHVucmVzcG9uc2l2ZSBtb2RlLCBldmVuIHRob3VnaCB0aGUgaG9zdCBpcyBvbiB0 aGUgbmV0d29yaywgYWJsZSB0byBTU0ggYW5kIHNlZW1zIHRvIGJlIGhlYWx0aHkuJm5ic3A7IEni gJl2ZSB0cmllZCBzZXZlcmFsIHRoaW5ncyB0byByZWNvdmVyIHRoZSBob3N0IGluIE92aXJ0LA0K IGJ1dCBoYXZlIGhhZCBubyBzdWNjZXNzIHNvIGZhci4mbmJzcDsgSeKAmWQgbGlrZSB0byByZWFj aCBvdXQgdG8gdGhlIGNvbW11bml0eSBiZWZvcmUgYmxvd2luZyBhd2F5IGFuZCByZWJ1aWxkaW5n IHRoZSBob3N0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5FbnZpcm9ubWVudDwvYj46IEkg aGF2ZSBhbiBPdmVuZ2luZSBzZXJ2ZXIgd2l0aCBhYm91dCAyNiBEYXRhY2VudGVycywgd2l0aCAy IHRvIDMgaG9zdHMgcGVyIERhdGFjZW50ZXIuJm5ic3A7IE15IE92ZW5naW5lIHNlcnZlciBpcyBo b3N0ZWQgY2VudHJhbGx5LCB3aXRoIG15IGhvc3RzIGJlaW5nIGJhcmUtbWV0YWwgYW5kIGRpc3Ry aWJ1dGVkIHRocm91Z2hvdXQgbXkgZW52aXJvbm1lbnQuJm5ic3A7ICZuYnNwOyZuYnNwO092ZW5n aW5lIGlzDQogdmVyc2lvbiA0LjAuNi4mbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PldoYXQgSeKAmXZlIHRyaWVkOiA8L2I+cHV0IGludG8gbWFpbnRlbmFuY2UgbW9kZSwgcmVib290 ZWQgdGhlIGhvc3QuJm5ic3A7IENvbmZpcm1lZCBob3N0IHdhcyByZWJvb3RlZCBhbmQgdHJpZWQg dG8gYWN0aXZlLCBnb2VzIGJhY2sgdG8gdW5yZXNwb25zaXZlLiZuYnNwOyZuYnNwOyBBdHRlbXB0 ZWQgYSByZWluc3RhbGwsIHdoaWNoIGZhaWxzLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkNoZWNraW5nIGZyb20gdGhlIGhvc3QgcGVyc3BlY3RpdmUsIEkgY2FuIHNlZSB0aGUg Zm9sbG93aW5nIHByb2JsZW1zOg0KPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bYm94bmFt ZX5dIyBzeXN0ZW1jdGwgc3RhdHVzIHZkc21kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj7il48gdmRzbWQuc2VydmljZSAtIFZpcnR1YWwgRGVza3RvcCBTZXJ2ZXIgTWFuYWdl cjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IExvYWRl ZDogbG9hZGVkICgvdXNyL2xpYi9zeXN0ZW1kL3N5c3RlbS92ZHNtZC5zZXJ2aWNlOyBlbmFibGVk OyB2ZW5kb3IgcHJlc2V0OiBlbmFibGVkKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7IEFjdGl2ZTogaW5hY3RpdmUgKGRlYWQpPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkp1bCAxNCAxMjozNDoyOCBib3huYW1lIHN5c3RlbWRbMV06IERlcGVuZGVuY3kg ZmFpbGVkIGZvciBWaXJ0dWFsIERlc2t0b3AgU2VydmVyIE1hbmFnZXIuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdWwgMTQgMTI6MzQ6MjggYm94bmFtZSBzeXN0ZW1kWzFd OiBKb2IgdmRzbWQuc2VydmljZS9zdGFydCBmYWlsZWQgd2l0aCByZXN1bHQgJ2RlcGVuZGVuY3kn LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Hb2luZyBhIGJpdCBkZWVwZXIsIHRoZSByZXN1 bHRzIG9mIGpvdXJuYWxjdGwg4oCTeGU6IDwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3Jv b3RAYm94bmFtZSB+XSMgam91cm5hbGN0bCAteGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tIERlZmluZWQtQnk6IHN5c3RlbWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tIFN1cHBvcnQ6IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFp bG1hbi9saXN0aW5mby9zeXN0ZW1kLWRldmVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gVW5pdCBs aWJ2aXJ0ZC5zZXJ2aWNlIGhhcyBiZWd1biBzaHV0dGluZyBkb3duLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVsIDE4IDA5OjA3OjMxIGJveG5hbWUgc3lzdGVtZFsxXTog U3RvcHBlZCBWaXJ0dWFsaXphdGlvbiBkYWVtb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSBTdWJqZWN0OiBVbml0IGxpYnZpcnRkLnNlcnZpY2UgaGFzIGZpbmlzaGVk IHNodXR0aW5nIGRvd248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIERl ZmluZWQtQnk6IHN5c3RlbWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0t IFN1cHBvcnQ6IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9z eXN0ZW1kLWRldmVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gVW5pdCBsaWJ2aXJ0ZC5zZXJ2aWNl IGhhcyBmaW5pc2hlZCBzaHV0dGluZyBkb3duLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SnVsIDE4IDA5OjA3OjMxIGJveG5hbWUgc3lzdGVtZFsxXTogUmVsb2FkaW5nLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVsIDE4IDA5OjA3OjMxIGJveG5h bWUgc3lzdGVtZFsxXTogQmluZGluZyB0byBJUHY2IGFkZHJlc3Mgbm90IGF2YWlsYWJsZSBzaW5j ZSBrZXJuZWwgZG9lcyBub3Qgc3VwcG9ydCBJUHY2LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SnVsIDE4IDA5OjA3OjMxIGJveG5hbWUgc3lzdGVtZFsxXTogWy91c3IvbGli L3N5c3RlbWQvc3lzdGVtL3JwY2JpbmQuc29ja2V0OjZdIEZhaWxlZCB0byBwYXJzZSBhZGRyZXNz IHZhbHVlLCBpZ25vcmluZzogWzo6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5KdWwgMTggMDk6MDc6MzEgYm94bmFtZSBzeXN0ZW1kWzFdOiBTdGFydGVkIEF1eGlsaWFyeSB2 ZHNtIHNlcnZpY2UgZm9yIHJ1bm5pbmcgaGVscGVyIGZ1bmN0aW9ucyBhcyByb290LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gU3ViamVjdDogVW5pdCBzdXBlcnZkc21k LnNlcnZpY2UgaGFzIGZpbmlzaGVkIHN0YXJ0LXVwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSBEZWZpbmVkLUJ5OiBzeXN0ZW1kPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLSBTdXBwb3J0OiBodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21h aWxtYW4vbGlzdGluZm8vc3lzdGVtZC1kZXZlbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIFVuaXQg c3VwZXJ2ZHNtZC5zZXJ2aWNlIGhhcyBmaW5pc2hlZCBzdGFydGluZyB1cC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLSBUaGUgc3RhcnQtdXAgcmVzdWx0IGlzIGRvbmUuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5KdWwgMTggMDk6MDc6MzEgYm94bmFtZSBzeXN0ZW1kWzFdOiBT dGFydGluZyBBdXhpbGlhcnkgdmRzbSBzZXJ2aWNlIGZvciBydW5uaW5nIGhlbHBlciBmdW5jdGlv bnMgYXMgcm9vdC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gU3Vi amVjdDogVW5pdCBzdXBlcnZkc21kLnNlcnZpY2UgaGFzIGJlZ3VuIHN0YXJ0LXVwPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBEZWZpbmVkLUJ5OiBzeXN0ZW1kPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBTdXBwb3J0OiBodHRwOi8vbGlzdHMu ZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vc3lzdGVtZC1kZXZlbDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tIFVuaXQgc3VwZXJ2ZHNtZC5zZXJ2aWNlIGhhcyBiZWd1biBzdGFydGluZyB1 cC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1bCAxOCAwOTowNzozMSBi b3huYW1lIHN5c3RlbWRbMV06IFN0YXJ0aW5nIFZpcnR1YWxpemF0aW9uIGRhZW1vbi4uLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gU3ViamVjdDogVW5pdCBsaWJ2aXJ0 ZC5zZXJ2aWNlIGhhcyBiZWd1biBzdGFydC11cDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS0gRGVmaW5lZC1CeTogc3lzdGVtZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LS0gU3VwcG9ydDogaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWls bWFuL2xpc3RpbmZvL3N5c3RlbWQtZGV2ZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBVbml0IGxp YnZpcnRkLnNlcnZpY2UgaGFzIGJlZ3VuIHN0YXJ0aW5nIHVwLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SnVsIDE4IDA5OjA3OjMyIGJveG5hbWUgc3lzdGVtZFsxXTogU3Rh cnRlZCBWaXJ0dWFsaXphdGlvbiBkYWVtb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLSBTdWJqZWN0OiBVbml0IGxpYnZpcnRkLnNlcnZpY2UgaGFzIGZpbmlzaGVkIHN0 YXJ0LXVwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBEZWZpbmVkLUJ5 OiBzeXN0ZW1kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBTdXBwb3J0 OiBodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vc3lzdGVtZC1k ZXZlbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIFVuaXQgbGlidmlydGQuc2VydmljZSBoYXMgZmlu aXNoZWQgc3RhcnRpbmcgdXAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gVGhlIHN0YXJ0LXVwIHJl c3VsdCBpcyBkb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVsIDE4 IDA5OjA3OjMyIGJveG5hbWUgc3lzdGVtZFsxXTogU3RhcnRpbmcgVmlydHVhbCBEZXNrdG9wIFNl cnZlciBNYW5hZ2VyIG5ldHdvcmsgcmVzdG9yYXRpb24uLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0tIFN1YmplY3Q6IFVuaXQgdmRzbS1uZXR3b3JrLnNlcnZpY2UgaGFz IGJlZ3VuIHN0YXJ0LXVwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBE ZWZpbmVkLUJ5OiBzeXN0ZW1kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LSBTdXBwb3J0OiBodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8v c3lzdGVtZC1kZXZlbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIFVuaXQgdmRzbS1uZXR3b3JrLnNl cnZpY2UgaGFzIGJlZ3VuIHN0YXJ0aW5nIHVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+bGluZXMgMjc1MS0yNzk3LzI3OTcgKEVORCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RG9lcyB0aGUgY29tbXVuaXR5IGhhdmUgc3VnZ2VzdGlvbnMgb24gd2hhdCBjYW4gYmUgZG9u ZSBuZXh0IHRvIHJlY292ZXIgdGhpcyBob3N0IHdpdGhpbiBPdmlydD8mbmJzcDsgSSBjYW4gcHJv dmlkZSBhZGRpdGlvbmFsIGxvZyBkdW1wcyBhcyBuZWVkZWQsIHBsZWFzZSBpbmZvcm0gd2l0aCB3 aGF0IHlvdSBuZWVkIHRvIGFzc2lzdCBmdXJ0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFuayB5b3UsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub255PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_90D58F04AB4E44D98CF3C90FDCB546C1acroniscom_--

3 9

Hosted Engine/NFS Troubles
by Phillip Bailey 19 Jul '17

19 Jul '17

Hi, I'm having trouble with my hosted engine setup (v4.0) and could use some help. The problem I'm having is that whenever I try to add additional hosts to the setup via webadmin, the operation fails due to storage-related issues. webadmin shows the following error messages: "Host <host name> cannot access the Storage Domain(s) hosted_storage attached to the Data Center Default. Setting Host state to Non-Operational. Failed to connect Host ovirt-node-1 to Storage Pool Default" The VDSM log from the host shows the following error message: "Thread-18::ERROR::2017-07-17 13:01:11,483::sdc::146:: Storage.StorageDomainCache::(_findDomain) domain ca044720-e5cf-40a8-8b21-57a17026db7c not found Traceback (most recent call last): File "/usr/share/vdsm/storage/sdc.py", line 144, in _findDomain dom = findMethod(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 174, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: (u'ca044720-e5cf-40a8-8b21-57a17026db7c',)" The engine log shows the following error messages: "2017-07-17 18:32:11,409 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxyData] (org.ovirt.thread.pool-6-thread-34) [] Domain 'ca044720-e5cf-40a8-8b21-57a17026db7c:hosted_storage' was reported with error code '358' 2017-07-17 18:32:11,410 ERROR [org.ovirt.engine.core.bll.InitVdsOnUpCommand] (org.ovirt.thread.pool-6-thread-34) [] Storage Domain 'hosted_storage' of pool 'Default' is in problem in host 'ovirt-node-1' 2017-07-17 18:32:11,487 ERROR [org.ovirt.engine.core.dal. dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-34) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Host ovirt-node-1 reports about one of the Active Storage Domains as Problematic." I have ownership set to vdsm/kvm and full rwx rights enabled on both directories. I have successfully mounted both the master domain and the hosted_storage manually on one of the hosts I'm trying to add. I have attached the engine log and the VDSM log for that host. Could someone please help me figure out what's causing this? -Phillip Bailey

4 6

[kolla] Looking for Docker images for Cinder, Glance etc for oVirt
by Leni Kadali Mutungi 19 Jul '17

19 Jul '17

Hello all. I am trying to use the Cinder and Glance Docker images you provide in relation to the setup here: http://www.ovirt.org/develop/release-management/features/cinderglance-docke… I tried to run `sudo docker pull kollaglue/centos-rdo-glance-registry:latest` and got an error of not found. I thought that it could possible to use a Dockerfile to spin up an equivalent of it, so I would like some guidance on how to go about doing that. Best practices and so on. Alternatively, if it is possible, may you point me in the direction of the equivalent images mentioned in the guides if they have been superseded by something else? Thanks. CCing the oVirt users and devel lists to see if anyone has experienced something similar. -- - Warm regards Leni Kadali Mutungi

4 3

test email
by Abi Askushi 19 Jul '17

19 Jul '17

several days without receiving any email from this list. please test back. Abi

2 1

[ANN] oVirt 4.1.4 Second Release Candidate is now available
by Sandro Bonazzola 19 Jul '17

19 Jul '17

The oVirt Project is pleased to announce the availability of the Second Release Candidate of oVirt 4.1.4 for testing, as of July 19th, 2017 This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This update is the second release candidate of the fourth in a series of stabilization updates to the 4.1 series. 4.1.4 brings more than 20 enhancements and more than 80 bugfixes, including more than 50 high or urgent severity fixes, on top of oVirt 4.1 series This release is available now for: * Fedora 24 (tech preview) * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later * oVirt Node 4.1 * Fedora 24 (tech preview) See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Live is already available[4] - oVirt Node is already available[4] Additional Resources: * Read more about the oVirt 4.1.4 release highlights: http://www.ovirt.org/release/4.1.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.1.4/ [4] resources.ovirt.org/pub/ovirt-4.1-pre/iso/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

"remove" option greyed out on Permissions tab
by Ian Neilsen 19 Jul '17

19 Jul '17

Hey guys Ive just noticed that I am unable to choose the "remove" option on any "Permissions" tab in Ovirt Self-hosted 4.1. Anyone have a suggestion on how to fix this. Im logged in as admin, original admin created during installation. Thanks in Advance -- Ian Neilsen Mobile: 0424 379 762 Linkedin: http://au.linkedin.com/in/ianneilsen Twitter : ineilsen

1 1

Backup oVirt Node configuration
by Fernando Frediani 19 Jul '17

19 Jul '17

Folks. I had a need to reinstall a oVirt Node a few times these days. This imposed reconfigure it all in order to add it back to oVirt Engine. What is a better way to backup a oVirt Node configuration, for when you reinstall it or if it fail completelly you just reinstall it and restore the backed up files with network configuration, UUID, VDSM, etc ? Thanks Fernando

1 0

Host stuck unresponsive after Network Outage
by Anthony.Fillmore 18 Jul '17

18 Jul '17

--_000_f25a1076729a4b24a9712b1c5c7f8a9fteemlmbx11phqtargetcom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hey Ovirt Users and Team, I have a host that I am unable to recover post a network outage. The host = is stuck in unresponsive mode, even though the host is on the network, able= to SSH and seems to be healthy. I=1B$B!G=1B(Bve tried several things to r= ecover the host in Ovirt, but have had no success so far. I=1B$B!G=1B(Bd l= ike to reach out to the community before blowing away and rebuilding the ho= st. Environment: I have an Ovengine server with about 26 Datacenters, with 2 to= 3 hosts per Datacenter. My Ovengine server is hosted centrally, with my h= osts being bare-metal and distributed throughout my environment. Ovengin= e is version 4.0.6. What I=1B$B!G=1B(Bve tried: put into maintenance mode, rebooted the host. = Confirmed host was rebooted and tried to active, goes back to unresponsive.= Attempted a reinstall, which fails. Checking from the host perspective, I can see the following problems: [boxname~]# systemctl status vdsmd =1B$B!|=1B(B vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor p= reset: enabled) Active: inactive (dead) Jul 14 12:34:28 boxname systemd[1]: Dependency failed for Virtual Desktop S= erver Manager. Jul 14 12:34:28 boxname systemd[1]: Job vdsmd.service/start failed with res= ult 'dependency'. Going a bit deeper, the results of journalctl -xe: [root@boxname ~]# journalctl -xe -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit libvirtd.service has begun shutting down. Jul 18 09:07:31 boxname systemd[1]: Stopped Virtualization daemon. -- Subject: Unit libvirtd.service has finished shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit libvirtd.service has finished shutting down. Jul 18 09:07:31 boxname systemd[1]: Reloading. Jul 18 09:07:31 boxname systemd[1]: Binding to IPv6 address not available s= ince kernel does not support IPv6. Jul 18 09:07:31 boxname systemd[1]: [/usr/lib/systemd/system/rpcbind.socket= :6] Failed to parse address value, ignoring: [:: Jul 18 09:07:31 boxname systemd[1]: Started Auxiliary vdsm service for runn= ing helper functions as root. -- Subject: Unit supervdsmd.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit supervdsmd.service has finished starting up. -- -- The start-up result is done. Jul 18 09:07:31 boxname systemd[1]: Starting Auxiliary vdsm service for run= ning helper functions as root... -- Subject: Unit supervdsmd.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit supervdsmd.service has begun starting up. Jul 18 09:07:31 boxname systemd[1]: Starting Virtualization daemon... -- Subject: Unit libvirtd.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit libvirtd.service has begun starting up. Jul 18 09:07:32 boxname systemd[1]: Started Virtualization daemon. -- Subject: Unit libvirtd.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit libvirtd.service has finished starting up. -- -- The start-up result is done. Jul 18 09:07:32 boxname systemd[1]: Starting Virtual Desktop Server Manager= network restoration... -- Subject: Unit vdsm-network.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit vdsm-network.service has begun starting up. lines 2751-2797/2797 (END) Does the community have suggestions on what can be done next to recover thi= s host within Ovirt? I can provide additional log dumps as needed, please = inform with what you need to assist further. Thank you, Tony --_000_f25a1076729a4b24a9712b1c5c7f8a9fteemlmbx11phqtargetcom_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-= jp"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hey Ovirt Users and Team,<o:p></o:p> <o:p> </o:p> I have a host that I am unable to recover post a net= work outage.  The host is stuck in unresponsive mode, even though the = host is on the network, able to SSH and seems to be healthy.  I=1B$B!G= =1B(Bve tried several things to recover the host in Ovirt, but have had no success so far.  I=1B$B!G=1B(Bd like to reach out to = the community before blowing away and rebuilding the host.<o:p></o:p> <o:p> </o:p> Environment: I have an Ovengine server with a= bout 26 Datacenters, with 2 to 3 hosts per Datacenter.  My Ovengine se= rver is hosted centrally, with my hosts being bare-metal and distributed th= roughout my environment.    Ovengine is version 4.0.6.  <o:p></o:p> <o:p> </o:p> What I=1B$B!G=1B(Bve tried: put into maintena= nce mode, rebooted the host.  Confirmed host was rebooted and tried to= active, goes back to unresponsive.   Attempted a reinstall, whic= h fails.  <o:p></o:p> <o:p> </o:p> Checking from the host perspective, I can see the= following problems: <o:p></o:p> <o:p> </o:p> [boxname~]# systemctl status vdsmd<o:p></o:p> =1B$B!|=1B(B vdsmd.service - Virtual Desktop Server = Manager<o:p></o:p>    Loaded: loaded (/usr/lib/systemd/system= /vdsmd.service; enabled; vendor preset: enabled)<o:p></o:p>    Active: inactive (dead)<o:p></o:p> <o:p> </o:p> Jul 14 12:34:28 boxname systemd[1]: Dependency faile= d for Virtual Desktop Server Manager.<o:p></o:p> Jul 14 12:34:28 boxname systemd[1]: Job vdsmd.servic= e/start failed with result 'dependency'.<o:p></o:p> <o:p> </o:p> Going a bit deeper, the results of journalctl &#8= 211;xe: <o:p></o:p> <o:p> </o:p> [root@boxname ~]# journalctl -xe<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit libvirtd.service has begun shutting down.<o:= p></o:p> Jul 18 09:07:31 boxname systemd[1]: Stopped Virtuali= zation daemon.<o:p></o:p> -- Subject: Unit libvirtd.service has finished shutt= ing down<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit libvirtd.service has finished shutting down.= <o:p></o:p> Jul 18 09:07:31 boxname systemd[1]: Reloading.<o:p><= /o:p> Jul 18 09:07:31 boxname systemd[1]: Binding to IPv6 = address not available since kernel does not support IPv6.<o:p></o:p> Jul 18 09:07:31 boxname systemd[1]: [/usr/lib/system= d/system/rpcbind.socket:6] Failed to parse address value, ignoring: [::<o:p= ></o:p> Jul 18 09:07:31 boxname systemd[1]: Started Auxiliar= y vdsm service for running helper functions as root.<o:p></o:p> -- Subject: Unit supervdsmd.service has finished sta= rt-up<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit supervdsmd.service has finished starting up.= <o:p></o:p> --<o:p></o:p> -- The start-up result is done.<o:p></o:p> Jul 18 09:07:31 boxname systemd[1]: Starting Auxilia= ry vdsm service for running helper functions as root...<o:p></o:p> -- Subject: Unit supervdsmd.service has begun start-= up<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit supervdsmd.service has begun starting up.<o:= p></o:p> Jul 18 09:07:31 boxname systemd[1]: Starting Virtual= ization daemon...<o:p></o:p> -- Subject: Unit libvirtd.service has begun start-up= <o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit libvirtd.service has begun starting up.<o:p>= </o:p> Jul 18 09:07:32 boxname systemd[1]: Started Virtuali= zation daemon.<o:p></o:p> -- Subject: Unit libvirtd.service has finished start= -up<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit libvirtd.service has finished starting up.<o= :p></o:p> --<o:p></o:p> -- The start-up result is done.<o:p></o:p> Jul 18 09:07:32 boxname systemd[1]: Starting Virtual= Desktop Server Manager network restoration...<o:p></o:p> -- Subject: Unit vdsm-network.service has begun star= t-up<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit vdsm-network.service has begun starting up.<= o:p></o:p> lines 2751-2797/2797 (END)<o:p></o:p> <o:p> </o:p> Does the community have suggestions on what can be d= one next to recover this host within Ovirt?  I can provide additional = log dumps as needed, please inform with what you need to assist further.<o:= p></o:p> <o:p> </o:p> Thank you,<o:p></o:p> Tony<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_f25a1076729a4b24a9712b1c5c7f8a9fteemlmbx11phqtargetcom_--

1 0

mirror
by Fabrice Bacchella 18 Jul '17

18 Jul '17

I'm reading https://www.ovirt.org/develop/infra/repository-mirrors/ It says: You'll find in resources.ovirt.org a user named mirror I'm looking at http://resources.ovirt.org and don't see anything about that user. Where should I look ?

2 3

ISCSI storage with multiple nics on same subnet disabled on host activation
by Nelson Lameiras 17 Jul '17

17 Jul '17

------=_Part_57353689_1234561196.1496840388734 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=20 In our oVirt hosts, we are using DELL equallogic SAN with each server conne= cting to SAN via 2 physical interfaces. Since both interfaces share the sam= e network (Equalogic limitation) we must patch the linux kernel to to allow= iSCSI multipath with multiple NICs in the same subnet with sysctl :=20 ---------------------------------------------------------------------------= -----------------=20 net.ipv4.conf.p2p1.arp_ignore=3D1 net.ipv4.conf.p2p1.arp_announce=3D2 net.ipv4.conf.p2p1.rp_filter=3D2 net.ipv4.conf.p2p2.arp_ignore=3D1 net.ipv4.conf.p2p2.arp_announce=3D2 net.ipv4.conf.p2p2.rp_filter=3D2=20 ---------------------------------------------------------------------------= -----------------=20 This works great in most setups, but for a strange reason, on some of our s= etups, the sysctl configuration is updated by VDSM when activating a host a= nd the second interface stops working immeadiatly :=20 ---------------------------------------------------------------------------= -----------------=20 vdsm.log=20 2017-06-07 11:51:51,063+0200 INFO (jsonrpc/5) [storage.ISCSI] Setting stri= ct mode rp_filter for device 'p2p2'. (iscsi:602) 2017-06-07 11:51:51,064+0200 ERROR (jsonrpc/5) [storage.HSM] Could not conn= ect to storageServer (hsm:2392) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2389, in connectStorageServer conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 433, in connect iscsi.addIscsiNode(self._iface, self._target, self._cred) File "/usr/lib/python2.7/site-packages/vdsm/storage/iscsi.py", line 232, = in addIscsiNode iscsiadm.node_login(iface.name, target.address, target.iqn) File "/usr/lib/python2.7/site-packages/vdsm/storage/iscsiadm.py", line 33= 7, in node_login raise IscsiNodeError(rc, out, err)=20 ---------------------------------------------------------------------------= -----------------=20 "strict mode" is enforced for second interface, and it no longuer works...= =20 Which means - at least - that there is no redundancy in case of hardware fa= illure and this is not acceptable for our production needs.=20 What is really strange is that we have another "twin" site on another geogr= aphic region with simillar hardware configuration and same oVirt installati= on, and this problem does not happen.=20 What can be the root cause of this behaviour? How can I correct it?=20 our setup:=20 hostedEngine : Centor 7.3, ovirt 4.1.2=20 3 physical nodes centos 7.3, ovirt 4.1.2=20 SAN DELL Equalogic=20 cordialement, regards,=20 =09Nelson LAMEIRAS=20 Ing=C3=A9nieur Syst=C3=A8mes et R=C3=A9seaux / Systems and Networks enginee= r=20 Tel: +33 5 32 09 09 70=20 nelson.lameiras(a)lyra-network.com=20 www.lyra-network.com | www.payzen.eu=20 =09 =09 =09 Lyra Network, 109 rue de l'innovation, 31670 Lab=C3=A8ge, FRANCE=20 ------=_Part_57353689_1234561196.1496840388734 Content-Type: multipart/related; boundary="----=_Part_57353690_157338222.1496840388734" ------=_Part_57353690_157338222.1496840388734 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>Hello, </div><div> </div><div>In our oVirt hosts, we are using DELL equallogic SAN with eac= h server connecting to SAN via 2 physical interfaces. Since both interfaces= share the same network (Equalogic limitation) we must patch the linux kern= el to to allow iSCSI multipath with multiple NICs in the same subnet with s= ysctl : </div><div> </div><= div>-----------------------------------------------------------------------= --------------------- </div><div><pre>net.ipv4.conf= .p2p1.arp_ignore=3D1 net.ipv4.conf.p2p1.arp_announce=3D2 net.ipv4.conf.p2p1.rp_filter=3D2 net.ipv4.conf.p2p2.arp_ignore=3D1 net.ipv4.conf.p2p2.arp_announce=3D2 net.ipv4.conf.p2p2.rp_filter=3D2 </pre>--------------------------= ------------------------------------------------------------------ <= /p>This works great in most setups, but for a strange reason, on some of= our setups, the sysctl configuration is updated by VDSM when activating a = host and the second interface stops working immeadiatly :<div>---------= ---------------------------------------------------------------------------= --------</div><div>vdsm.log </div><div><pre id=3D"p= review"><code>2017-06-07 11:51:51,063+0200 INFO (jsonrpc/5) [storage.ISCSI= ] Setting strict mode rp_filter for device 'p2p2'. (iscsi:602) 2017-06-07 11:51:51,064+0200 ERROR (jsonrpc/5) [storage.HSM] Could not conn= ect to storageServer (hsm:2392) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2389, in connectStorageServer conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 433, in connect iscsi.addIscsiNode(self._iface, self._target, self._cred) File "/usr/lib/python2.7/site-packages/vdsm/storage/iscsi.py", line 232, = in addIscsiNode iscsiadm.node_login(iface.name, target.address, target.iqn) File "/usr/lib/python2.7/site-packages/vdsm/storage/iscsiadm.py", line 33= 7, in node_login raise IscsiNodeError(rc, out, err)</code></pre><pre> </pre>----------------------= ----------------------------------------------------------------------<= /div></div><div><div> </div><div>"strict mode" is e= nforced for second interface, and it no longuer works...</div><div>Which me= ans - at least - that there is no redundancy in case of hardware faillure a= nd this is not acceptable for our production needs. </div><div> </div><div>What is really strange is t= hat we have another "twin" site on another geographic region with simillar = hardware configuration and same oVirt installation, and this problem does n= ot happen.</div><div> </div><div>What can be the ro= ot cause of this behaviour? How can I correct it? <= /div><div> </div><div>our setup:</div><div>hostedEn= gine : Centor 7.3, ovirt 4.1.2 </div><div>3 physical nodes centos 7.3, o= virt 4.1.2 </div><div>SAN DELL Equalogic </div></div><div> </div><div data-mar= ker=3D"__SIG_PRE__"><div>cordialement, regards,</div><div> </div><table style=3D"margin: 0px; table-layout: fixed; border: non= e; width: 345pt; padding: 0px;" data-mce-style=3D"margin: 0px; table-layout= : fixed; border: none; width: 345pt; padding: 0px;" width=3D"460" cellspaci= ng=3D"0" cellpadding=3D"0" border=3D"0"><tbody><tr><td style=3D"margin: 0; = font-size: 11px; font-family: Arial,sans-serif; color: #2b3c7a; line-height= : 16px; width: 86.25pt; text-align: left;" data-mce-style=3D"margin: 0; fon= t-size: 11px; font-family: Arial,sans-serif; color: #2b3c7a; line-height: 1= 6px; width: 86.25pt; text-align: left;" width=3D"115" valign=3D"top"><a hre= f=3D"https://www.lyra-network.com/" style=3D"border: none; text-decoration:= none; width: 100%; display: block; clear: both;" data-mce-href=3D"https://= www.lyra-network.com/" data-mce-style=3D"border: none; text-decoration: non= e; width: 100%; display: block; clear: both;"><img src=3D"cid:6fa8666d679e1= 8cab5e566228d0ca3519aabec27@zimbra" alt=3D"" data-mce-src=3D"/home/admin@ly= ra-network.com/corporate-documents/element-signature_logo_lyra_115x94.jpg" = doc=3D"corporate-documents/element-signature_logo_lyra_115x94.jpg" height= =3D"94" width=3D"115" border=3D"0"></a> </td><td st= yle=3D"margin: 0; font-size: 11px; font-family: Arial,sans-serif; color: #2= b3c7a; line-height: 16px; width: 258.75pt;" data-mce-style=3D"margin: 0; fo= nt-size: 11px; font-family: Arial,sans-serif; color: #2b3c7a; line-height: = 16px; width: 258.75pt;" width=3D"345" valign=3D"top"><table style=3D"margin= : 0; width: 258.75pt; table-layout: fixed; border: none;" data-mce-style=3D= "margin: 0; width: 258.75pt; table-layout: fixed; border: none;" width=3D"3= 45" cellspacing=3D"0" cellpadding=3D"0" border=3D"0"><tbody><tr><td style= =3D"font-size: 16px; font-family: Arial,sans-serif; color: #2b3c7a; line-he= ight: 18px; font-weight: bold;" data-mce-style=3D"font-size: 16px; font-fam= ily: Arial,sans-serif; color: #2b3c7a; line-height: 18px; font-weight: bold= ;">Nelson LAMEIRAS</td></tr><tr><td style=3D"font-family: Arial,sans-serif;= color: #2b3c7a; font-size: 11px; line-height: 16px;" data-mce-style=3D"fon= t-family: Arial,sans-serif; color: #2b3c7a; font-size: 11px; line-height: 1= 6px;">Ing=C3=A9nieur Syst=C3=A8mes et R=C3=A9seaux / Systems a= nd Networks engineer</td></tr><tr><td style=3D"line-height: 16px; fo= nt-family: 'Arial',sans-serif; color: #2b3c7a; font-size: 11px;" data-mce-s= tyle=3D"line-height: 16px; font-family: 'Arial',sans-serif; color: #2b3c7a;= font-size: 11px;">Tel: +33 5 32 09 09 70</td></tr><tr>= <td style=3D"line-height: 16px; font-family: 'Arial',sans-serif; color: #2b= 3c7a; font-size: 11px;" data-mce-style=3D"line-height: 16px; font-family: '= Arial',sans-serif; color: #2b3c7a; font-size: 11px;"><a href=3D"mailto:nels= on.lameiras(a)lyra-network.com" style=3D"font-size: 11px; font-family: Arial,= sans-serif; line-height: 16px; text-decoration: none;" data-mce-href=3D"mai= lto:nelson.lameiras@lyra-network.com" data-mce-style=3D"font-size: 11px; fo= nt-family: Arial,sans-serif; line-height: 16px; text-decoration: none;">nel= son.lameiras(a)lyra-network.com</a> </td></tr><tr><td= style=3D"line-height: 16px; font-family: 'Arial',sans-serif; color: #2b3c7= a; font-size: 11px;" data-mce-style=3D"line-height: 16px; font-family: 'Ari= al',sans-serif; color: #2b3c7a; font-size: 11px;"><a href=3D"https://www.ly= ra-network.com/" style=3D"font-size: 11px; font-family: Arial,sans-serif; l= ine-height: 16px; border: none; text-decoration: none;" data-mce-href=3D"ht= tps://www.lyra-network.com/" data-mce-style=3D"font-size: 11px; font-family= : Arial,sans-serif; line-height: 16px; border: none; text-decoration: none;= ">www.lyra-network.com</a> <a href=3D"https://payzen.eu" style=3D"font-size= : 11px; font-family: Arial,sans-serif; line-height: 16px; border: none; tex= t-decoration: none;" data-mce-href=3D"https://payzen.eu" data-mce-style=3D"= font-size: 11px; font-family: Arial,sans-serif; line-height: 16px; border: = none; text-decoration: none;"> | www.payzen.eu</a> = </td></tr></tbody></table></td></tr></tbody></table><table style=3D"margin:= 0; table-layout: fixed; border: none; width: 345pt;" data-mce-style=3D"mar= gin: 0; table-layout: fixed; border: none; width: 345pt;" data-mce-selected= =3D"1" width=3D"460" cellspacing=3D"0" cellpadding=3D"0"><tbody><tr><td sty= le=3D"margin: 0; font-size: 11px; font-family: Arial,sans-serif; color: #2b= 3c7a; line-height: 16px; width: 24pt; text-align: left;" data-mce-style=3D"= margin: 0; font-size: 11px; font-family: Arial,sans-serif; color: #2b3c7a; = line-height: 16px; width: 24pt; text-align: left;" width=3D"32" valign=3D"t= op"><a href=3D"https://www.youtube.com/channel/UCrVl1CO_Jlu3KbiRH-tQ_vA" st= yle=3D"border: none; text-decoration: none; margin: 0; float: left; display= : inline-block; width: 32px;" data-mce-href=3D"https://www.youtube.com/chan= nel/UCrVl1CO_Jlu3KbiRH-tQ_vA" data-mce-style=3D"border: none; text-decorati= on: none; margin: 0; float: left; display: inline-block; width: 32px;"><img= src=3D"cid:2806a89cb9fbba6f879bd3fd54a93b515defd6d2@zimbra" alt=3D"" data-= mce-src=3D"/home/admin(a)lyra-network.com/corporate-documents/element-signatu= re_logo_YouTube_32x28.jpg" doc=3D"corporate-documents/element-signature_log= o_YouTube_32x28.jpg" height=3D"28" width=3D"32" border=3D"0"></a> </td><td style=3D"margin: 0; font-size: 11px; font-family: A= rial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; text-al= ign: left;" data-mce-style=3D"margin: 0; font-size: 11px; font-family: Aria= l,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; text-align= : left;" width=3D"41" valign=3D"top"><a href=3D"https://www.linkedin.com/co= mpany/lyra-network_2" style=3D"border: none; text-decoration: none; margin:= 0; float: left; display: inline-block; width: 41px;" data-mce-href=3D"http= s://www.linkedin.com/company/lyra-network_2" data-mce-style=3D"border: none= ; text-decoration: none; margin: 0; float: left; display: inline-block; wid= th: 41px;"><img src=3D"cid:878634ba055bb6ae851a7ef4540f754afa3ff86c@zimbra"= data-mce-src=3D"/home/admin(a)lyra-network.com/corporate-documents/element-s= ignature_logo_LinkedIn_41x28.jpg" doc=3D"corporate-documents/element-signat= ure_logo_LinkedIn_41x28.jpg" height=3D"28" width=3D"41" border=3D"0"></a><b= r data-mce-bogus=3D"1"></td><td style=3D"margin: 0; font-size: 11px; font-f= amily: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 31.5pt; = text-align: left;" data-mce-style=3D"margin: 0; font-size: 11px; font-famil= y: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 31.5pt; text= -align: left;" width=3D"42" valign=3D"top"><a href=3D"https://twitter.com/L= yraNetwork" style=3D"border: none; text-decoration: none; margin: 0; float:= left; display: inline-block; width: 42px;" data-mce-href=3D"https://twitte= r.com/LyraNetwork" data-mce-style=3D"border: none; text-decoration: none; m= argin: 0; float: left; display: inline-block; width: 42px;"><img src=3D"cid= :18a767bbdad6a1133fc4152b03ea78228ce25a14@zimbra" alt=3D"" data-mce-src=3D"= /home/admin@lyra-network.com/corporate-documents/element-signature_logo_Twi= tter_42x28.jpg" doc=3D"corporate-documents/element-signature_logo_Twitter_4= 2x28.jpg" height=3D"28" width=3D"42" border=3D"0"></a> </td><td style=3D"margin: 0; font-size: 11px; font-family: Arial,sans-s= erif; color: #2b3c7a; line-height: 16px; width: 258.75pt; text-align: left;= " data-mce-style=3D"margin: 0; font-size: 11px; font-family: Arial,sans-ser= if; color: #2b3c7a; line-height: 16px; width: 258.75pt; text-align: left;" = width=3D"345" valign=3D"top"><a href=3D"https://payzen.eu" style=3D"border:= none; text-decoration: none; margin: 0; float: left; display: inline-block= ; width: 61px;" data-mce-href=3D"https://payzen.eu" data-mce-style=3D"borde= r: none; text-decoration: none; margin: 0; float: left; display: inline-blo= ck; width: 61px;"><img src=3D"cid:d3fc119a0aa72bf985c19ca559c993b5b4b54ca3@= zimbra" alt=3D"" data-mce-src=3D"/home/admin(a)lyra-network.com/corporate-doc= uments/element-signature_payzen_61x28.jpg" doc=3D"corporate-documents/eleme= nt-signature_payzen_61x28.jpg" height=3D"28" width=3D"61" border=3D"0"></a>= </td></tr></tbody></table><table style=3D"margin: = 0; table-layout: fixed; border: none; width: 345pt;" data-mce-style=3D"marg= in: 0; table-layout: fixed; border: none; width: 345pt;" width=3D"460" cell= spacing=3D"0" cellpadding=3D"0"><tbody><tr><td><hr style=3D"background: #29= 3b79 none repeat scroll 0% 0%; width: 100%; height: 4px; color: #293b79; ma= rgin: 0px;" data-mce-style=3D"background: #293b79 none repeat scroll 0% 0%;= width: 100%; height: 4px; color: #293b79; margin: 0px;"></td></tr></tbody>= </table><table style=3D"margin: 0; table-layout: fixed; border: none; width= : 345pt;" data-mce-style=3D"margin: 0; table-layout: fixed; border: none; w= idth: 345pt;" data-mce-selected=3D"1" width=3D"460" cellspacing=3D"0" cellp= adding=3D"0"><tbody><tr><td style=3D"margin: 0; font-size: 11px; font-famil= y: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; tex= t-align: left;" data-mce-style=3D"margin: 0; font-size: 11px; font-family: = Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; text-a= lign: left;"><div>Lyra Network, 109 rue de l'innovation, 31670 Lab=C3=A8ge,= FRANCE</div></td></tr></tbody></table><div> </div></div></div></body></= html> ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_logo_lyra_115x94.jpg Content-Disposition: attachment; filename=element-signature_logo_lyra_115x94.jpg Content-Transfer-Encoding: base64 Content-ID: <6fa8666d679e18cab5e566228d0ca3519aabec27@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOkU1QUU4Nzk1OEExMzExRTZBNTFCRjVENEYyNDYxNTQ1IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkU1QUU4Nzk0OEExMzExRTZBNTFCRjVENEYyNDYxNTQ1IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIAF4AcwMBEQACEQEDEQH/xACdAAEBAAIDAQEAAAAAAAAAAAAACAUH AgMGBAEBAQADAQEAAAAAAAAAAAAAAAACBAUBAxAAAAUDAgAHDQcCBwAAAAAAAAECAwQRBQYSByFR E7RWFzcxQSKS0nOT03RVlQgYYXEyQiMUFYEzsVJicmODOBEAAgECAwcEAgIDAAAAAAAAAAECEQNR EwQhgbESMlIzMUGhFHEVwQUiQzT/2gAMAwEAAhEDEQA/AKpAE9b/AGQZdF3FtNpsd4l29M2DHSll iS6w0bzsp5slqJCiLvERnTuENTRQg7bckntK15vmojj1WfMP0rc+Jy/JD7Fjt+EMueJ6bbnBN4bR lkWdkt+XPtDaHSfjKnSHyUpTZkg+TcLSdFGRjyv3rUo0iqP8EoQkntZ7fcOy5VdrXGYxuccGW2+S 3nCecYq3oUWnU2RmfhGXAPPSXLcJNzVVT8kNVbnKKUHRmppW1/zBOSXVtZS4lpSjNtP8nLKhfcSR alqdPXp+ERhauKKTe38nX1WfMP0qc+Jy/JHPsWO34RPLniOqz5h+lTnxOX5IfYsdvwhlzxHVZ8w/ Spz4nL8kPsWO34Qy54jqs+YfpU58Tl+SH2LHb8IZc8R1WfMP0qc+Jy/JD7Fjt+EMueJ2bCX3MH9y LxZr7eJdxKBCkoW0/JdfaJ5mUy2a0EszL/MRHTuGGshDLTiqVf8AAst81GUGMssgAAAAE5b89s+L +zwefPDV0fhlv4FW71oo0ZRaAAAAAAAAAAAAACdtj+3DLfNXDn7I1dX4Y7uBWtdbKJGUWQAAAACc t+e2fF/Z4PPnhq6Pwy38Crd60UaMotAAAAAAAAAAAAABO2x/bhlvmrhz9kaur8Md3ArWutlEjKLI AAAABOW/PbPi/s8Hnzw1dH4Zb+BVu9aKNGUWjAKzrGk5cnEjkq/nVo5RMbk3NOnkzd/uU0fgKvdH rky5eb2I86rQz48iQAAAAAAAAABO2x/bhlvmrhz9kaur8Md3ArWutlEjKLIAAAABOW/PbPi/s8Hn zw1dH4Zb+BVu9aKNGUWjSD//AKkj+xnzJQ0V/wA2/wDkr/7D3e7GX5DiOMfzlniMTEMPIRORIJfg tOeCladCk/nNJH94raa1GcuVnpck4qqOrJdz4dr2yazKOhDjkxhlUGMszop98i/TOlD/AE/CNX+0 x23p27nIJXKRqeeyjdnLMd27sGSzLdEO4Xd4uWifqkhDDiFut0qrUSzQlNa9wz7g9bemjK44puiI yuNRTOzGs53hud+gvzsYjwMVnqNfLuqUTrEck69bitZmStPc1NJIz4hy5ZtKLpKskIzk36bDHRt2 9yMsuMw9v8ejybNBc5M5s5Rp5Uy4aEZuMJSai4dPCZFStBN6a3BLne1nMyT6Uffgu8GQ5DnysXuN mbtZx461TG1ms3kyGiLWRHXToMz8Hg7nfMQvaWMYcydTsLjcqG2BSPYnbY/twy3zVw5+yNXV+GO7 gVrXWyiRlFkAAAAAnLfntnxf2eDz54auj8Mt/Aq3etFGjKLROmdZbAxL5g/5yey6/GjREJW2wSTc M3YpoKms0F3VcY1bNpzscqKs5UnU9pad4cG3Fefw1UWXFO7x3mULkpaJJnoM6JNC10WREak/aXGK 8tLO1/ns2HorilsNTYzar/kOQWTa+5tmmBjk+W9cKGqimkrJS68RcCkoV/yC7clGMXcXrJI8Yptq OBsj5oEpTiNmSRESSuKSJJFwUJlzgoKv9f1P8Hrf9Db1wh/vbVJh6tH7lhbOvi5RBpr/AEqKMXR1 PZrYaC2x3Jgbawp+IZjBkwpkWS480603rSslkRU7qTOuiqFlUlEfepw6WosO61ODK9ufLsZ27f36 RkG/8q9OwXbe3PgKciMPp0uHHS22hpxRf60o1f4VC9DlsUrWjEHWdSghllknbY/twy3zVw5+yNXV +GO7gVrXWyiRlFkAAAAAnLfntnxf2eDz54auj8Mt/Aq3etFGjKLRxU00o6qQlR8ZkRhUGMyO7W7H 7FOvUpCSZgMrfMqERqNJeCgj41qokvtMTtxcpJL3OSdFU1n8vFimPwbrnF18O55DIXybhlw8ihZm s08RLdqVOJJC5rZqqgvSJ42V7v3MpM3dTBnyWbtBQmHFnXFpLzdXOWjW9tWo2irwPpd0pWhVPBPU R0qILTVWx+y+STuYmQj7sxHH1Kctb7NuahnMflKW2akk3J/bvGlojqtpv8ZuJP8ACR8Ag9M8dtTu YdErdfEJTCZKrY/L5JSySbrbCdKmicdWRLeWlJK/bs8skq+ElSacJ8HVppr3OZiP2RuxFK4W5xi3 LK2T5D8NmY8baHHnWySSeTSa6to1K8JTumn3gtM6PbtQzDYYqnqTtsf24Zb5q4c/ZGrq/DHdwK1r rZRIyiyAAAAATlvz2z4v7PB588NXR+GW/gVbvWijRlFoADGZHjVmyO2Ltd4YOTAcUlbjJLcbJRoO qam2pCuA+GlROFxwdV6nJRT2M+q226DbLfHt8BkmIcRtLMdlNaJQgqEVTqZ/eYjKTbqwlQ5Hb4Bp Uk4zRpUpa1FoTQ1uEaVqPg7qiUZGffDmYodSbNZ0toaTBjk02hbTaCaQSUtu/wBxCSpQkr/MXfHe d4iiP12z2h5k2XYMdxlSkuKbW0hSTW2kkIUZGVKpSkiI+8RApPEURydtltdQpDsRlxCtepKm0mR8 qdXKkZfn/NxjnMxQ+kcOk7bH9uGW+auHP2Rq6vwx3cCta62USMosgAAAAE5b89s+L+zwefPDV0fh lv4FW71oo0ZRaAAAAAAAAAAAAACdtj+3DLfNXDn7I1dX4Y7uBWtdbKJGUWQAAAACb9/3mWN4cbff WTTLUWEt1xX4UpTNeNSj+wiGtolW1LfwKt7qRuTrY226RwfSkKH1rnaz3zI4jrZ226RwfSkH1rna xmRxHWztt0jg+lIPrXO1jMjiOtnbbpHB9KQfWudrGZHEdbO23SOD6Ug+tc7WMyOJ+o3W24WtKE5F CUpR0SknCqZmH1rnazjuxW2pnbTfbPeGnHbXMamNtK0OLaVqJKjKtDELlqUNklQ7C5GfS6mOu+f4 XZpy4F0vMWHMbJKlsOrJKyJRVTUvtIdjZnJVSOuaXqfF1sbbdI4PpSEvrXO1nMyOJp7YiQxJ3oyi RHcS9Hejz3GXUcKVoVOZNKi+wyOovaxUsx3cDwtdbKNGUWgAAAADX+4GzGPZveWbtcpsuO+xGTFS iObRINCFrcIz1oWdaun3xas6qVtUSR5ztKTqeZ+lrCvely8Zj1Q9f2M8EQyEPpawr3pcvGY9UH7G eCGQh9LWFe9Ll4zHqg/YzwQyEPpawr3pcvGY9UH7GeCGQh9LWFe9Ll4zHqg/YzwQyEc2flfwxl5t 1NzuJqbUSiI1MUqX/UOr+xmn6I5LTRaaxNg4XhNuxOHIiwX3n0SXCdWb5pMyMk6eDSlPEPDU6mV5 pteg0+nVpNI8zm+xeNZfkDt7nzprEl5Dbam2FNEgibTpKmttR97jErWslCNEkTlaUnUwP0tYV70u XjMeqHp+xngiOQj023+zGPYReXrtbZsuQ+/GVFUiQbRoJC1ocMy0IQdatF3x5XtVK4qNInC0oups AVT0AAAAAAAAAAAAAAAAAAAAAAAAAAAAD//Z ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_logo_YouTube_32x28.jpg Content-Disposition: attachment; filename=element-signature_logo_YouTube_32x28.jpg Content-Transfer-Encoding: base64 Content-ID: <2806a89cb9fbba6f879bd3fd54a93b515defd6d2@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjQ1REY5Njk1OEExNzExRTY5OUVDOTI1QTU3QzAwNzI0IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjQ1REY5Njk0OEExNzExRTY5OUVDOTI1QTU3QzAwNzI0IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAIAMBEQACEQEDEQH/xAB5AAADAQEAAAAAAAAAAAAAAAAABwgF BgEAAgMBAAAAAAAAAAAAAAAAAAQCAwUBEAABBAECBAUFAAAAAAAAAAABAgMEBQARBiESEwcxUdIU CEEik1UYEQACAQMCBQUAAAAAAAAAAAAAAQIRAwQhMVFhEiITQaHBYhX/2gAMAwEAAhEDEQA/AKpw AnD5Hbg3JA35XxKqxmxUPVrJEaI862FuqkPp4IbI5lHQDNXBhFwbaW4tebqcMIvfYjURtz6eesv1 YzWz9fYh38zR7eX2+mu5lHV3VhaNOe8aTJgTHnweVXEBba1cQRkb8IeNtJbHYN9WpW+YY2T53inQ 4HfzZk6a4lmHGaiOSHl8EoT7mSOZR+gBIzUxU3Yklz+Be4+9DRl30N3dMOxjbyro9EzHW3MqupHc L7qlaoX1SsFvlHl44moPpa6XXiW113FPuu3qrT5I7dfrJLUxllMRl15hQWjqBbiuXmTqCQlQx23F rHdSqTrNFFZlDAou7vZa43xuSNaw7CPFZZhIiKbeSsqKkOuuE/aCNNHcexspW40a9Sm5bcmcH/J1 5+0rvxOenGf0o8GQ8DN7ZXxzv9vbpqrhy0huMQJCHlstocBKU+ITqANcru50ZRao9SUbLTqPvMwv DAAwAMAP/9k= ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_logo_LinkedIn_41x28.jpg Content-Disposition: attachment; filename=element-signature_logo_LinkedIn_41x28.jpg Content-Transfer-Encoding: base64 Content-ID: <878634ba055bb6ae851a7ef4540f754afa3ff86c@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjY2MEYzRTFGOEExNzExRTY5QzI5OUNGQkY1MzM2MUQ1IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjY2MEYzRTFFOEExNzExRTY5QzI5OUNGQkY1MzM2MUQ1IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAKQMBEQACEQEDEQH/xAB2AAEBAQEAAAAAAAAAAAAAAAAABggH AQEAAwEAAAAAAAAAAAAAAAAAAwQFAhAAAQMEAgICAgMBAAAAAAAAAQIDBAARBQYhEjEHMghBE1Fh IhcRAAICAQIDCQAAAAAAAAAAAAABAgMREgQxkTIhQVGhscETMxX/2gAMAwEAAhEDEQA/ANU0Bl33 zsuzQfZcmHj8tMiMKaihDLMl1psKcQkXslSUjk8mtjZ1xdeWkVbW9RDZ/ZN8wOXkYnI7LKMuL1Lq o+RddaIWkLHVwLAPCuf4NWYVwksqPkcNtd5V+ldr2ef7MwkaZmJsqK6p/uy9JdcbUBGcULpUog8i 9Q7uuKreEjquT1GsKxC2KAUBk37B2/6y72t1tB7X8dbIvf8Aq3mtvZfVzKlvUWWw7Dr+Dfy8rCt4 d153Z8ew0FNx3kohuxmUyFtAfFPyBUOBz+arwhKWE89L9SRtLmTuns4xj7LLaxYaGNE6SYojlJZ6 rhLUf19f89eyj4qa1t7ft449ziPWairGLQoBQHFvZ/onObht0jNxclFjMPNtNpZdS4Vj9aAk36gj mtDb7yMIaWiGdTbySSfqnsKbdctAFh1Fm3Bwfx8fFT/ox8GcfAyk9dfX7OapuGNzj+SiPRoJcKmG kuBRDjS2x1uAPK71DfvYzg444nUKmnk7lWcTigFAKAUAoBQCgP/Z ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_logo_Twitter_42x28.jpg Content-Disposition: attachment; filename=element-signature_logo_Twitter_42x28.jpg Content-Transfer-Encoding: base64 Content-ID: <18a767bbdad6a1133fc4152b03ea78228ce25a14@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjdDMkI3MjMyOEExNzExRTY5MDUyRTk1NEIyREUwNjVCIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjdDMkI3MjMxOEExNzExRTY5MDUyRTk1NEIyREUwNjVCIiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAKgMBEQACEQEDEQH/xAB3AAEBAQEBAAAAAAAAAAAAAAAABwUI BgEBAAMBAQAAAAAAAAAAAAAAAAMEBQIBEAABAwIEBwEBAQAAAAAAAAABAgMEAAUREhMGITFBFBUH CIEiFhEAAgIBAgQHAAAAAAAAAAAAAAERAgMxBCHBEgVBUWGBQhMV/9oADAMBAAIRAxEAPwDC9g7u 3dH33uJiNeri2wxcJQQ01JfCUNodVwCUqwSlI/AK3sGKropS0Kd7OWZMXcPsyZDdnQ7he5UFhQQ/ LZelOMoURiEqWlRAOFdumNOGqyeTYtPzFfL1df8ASm5XCTP0ey0e5eceyZu4zZc5VhjlGOFZ/cKJ dMKNeRNhbclzrOJxQCgOSW7o5a/oKXMRFXNT5iYw/EaAUtbL61tOBKTwXglWOXrW30zgj0RUmLlb 9p3rZ/r/ANd3GxWJtm3XC8B1EO2RsEqDkng88pAP8JSnEk8ugqlt6Xy5Fa3FImyNVUI8z8nJCU7o SOSRAA/O5qbuXx9+Rxg8ToGsssCgFAc/7q+b9xXrc11u7V3iNN3CW/JbQUuhaUuuFYBIHMA9K08e +rWqUPgivbC25MofK25Qoq81DKjwKlJeUT+kE13+jXyZ59DKX6a9WXPYfmO+msTPJdtp6AWMuhq4 5swHPVFVN1uFkiFoS46dJSqqEgoBQCgFAKAUAoBQH//Z ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_payzen_61x28.jpg Content-Disposition: attachment; filename=element-signature_payzen_61x28.jpg Content-Transfer-Encoding: base64 Content-ID: <d3fc119a0aa72bf985c19ca559c993b5b4b54ca3@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOkU1NjczQjM2OEEzNDExRTZCOEJBQ0Y4Mzg3RTEzODkyIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkU1NjczQjM1OEEzNDExRTZCOEJBQ0Y4Mzg3RTEzODkyIiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAPQMBEQACEQEDEQH/xABvAAABBAMAAAAAAAAAAAAAAAAAAQUG BwIDBAEBAAAAAAAAAAAAAAAAAAAAABAAAQQABAQEAgsBAAAAAAAAAQIDBAUAERIGITETFEEiFQfS I1FhcYGhMlIkRMQWhhEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AvqZ7q7OhzZMSS9IQ Yjy2JT/avqZbW2rSvU6lBSACOeeAljLzTzSHmVhxpxIW24k5pUlQzBBHgRgM8BBJ9fKuvcGwr3La wgxIlfGeaagyVsJ1uOOBRUBmOSRgI0bnZgfQwdx7qDrroYZSVzBrcJ0hKM2xq+7AWBU7PTXTEShc 2svRx6MuWp5o5gjigj68BombFRKmPyTfXTPXWpzoszloaRqOelCQPKkeAwEP6lp6f6V6vYaP9Z6b 3fcr7ntuhno6vPnxwGyohb2ntbpr6Y17NdKt7Bp5+YHlPJLitKyltI0KGk+XPANVgzV1Eyyqbe3s IMmnhsMbVaYcebDraY+XVbQ15XXFOghQVnkMBkbjcVPTUs6M5IkPbnpWa1hKlrWG7QZBp0hROnUh xRUfHTgJDWuwtsbptVTpC1xaqhgJfkuFTji9DjoKiTmpSlq/HAcO2d11d/cuXUySJG4C0+NvbfCH CmK2hClHUop0GQ6E+dWfAeUYBi2lY2E+zgW7twhVlHDk+7AkzFO9u2lRdjORFIEZrTmAkA+GYwDl TwLJhjZFouxsF3NzN6r7Lj7imExHUOSHWi0TpyCdORIzzwHT/J/7n+vgLVAA5YBChBUlRSCpOelR HEZ88sA2WG3YVhb1lnJW4VVJcXFjAgM9VxOjqKTlmVJTnp48M8Ax2+3N3J3TJu6KVAbRKisxnWpr brh+SpasxoKf14BBD91hxE2kB+nt5Px4AEL3VGoiZSAr4qyjyOP2+fAL2nuvw/e0vDl8iT8eAbv8 Lur0vPvYXrPrfrfU6bvb59Lp6NOev83HngLBwBgDAGAMAYAwBgP/2Q== ------=_Part_57353690_157338222.1496840388734-- ------=_Part_57353689_1234561196.1496840388734--

3 5

Active Directory authentication setup
by Todd Punderson 17 Jul '17

17 Jul '17

--_000_ff591869654646c7bc8df4c4af6d898fdoongaorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've been pulling my hair out over this one. Here's the outp= ut of ovirt-engine-extension-aaa-ldap-setup. Everything works fine if I use= "plain" but I don't really want to do that. I searched the error that's sh= own below and tried several different "fixes" but none of them helped. Thes= e are Server 2016 DCs. Not too sure where to go next. [ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup Configuration files: ['/etc/ovirt-engine-extension-aaa-ldap-setup= .conf.d/10-packaging.conf'] Log file: /tmp/ovirt-engine-extension-aaa-ldap-setup-201707151709= 53-wfo1pk.log Version: otopi-1.6.2 (otopi-1.6.2-1.el7.centos) [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment customization Welcome to LDAP extension configuration program Available LDAP implementations: 1 - 389ds 2 - 389ds RFC-2307 Schema 3 - Active Directory 4 - IBM Security Directory Server 5 - IBM Security Directory Server RFC-2307 Schema 6 - IPA 7 - Novell eDirectory RFC-2307 Schema 8 - OpenLDAP RFC-2307 Schema 9 - OpenLDAP Standard Schema 10 - Oracle Unified Directory RFC-2307 Schema 11 - RFC-2307 Schema (Generic) 12 - RHDS 13 - RHDS RFC-2307 Schema 14 - iPlanet Please select: 3 Please enter Active Directory Forest name: home.doonga.org [ INFO ] Resolving Global Catalog SRV record for home.doonga.org [ INFO ] Resolving LDAP SRV record for home.doonga.org NOTE: It is highly recommended to use secure protocol to access the LDA= P server. Protocol startTLS is the standard recommended method to do so. Only in cases in which the startTLS is not supported, fallback to= non standard ldaps protocol. Use plain for test environments only. Please select protocol to use (startTLS, ldaps, plain) [startTLS]= : ldaps Please select method to obtain PEM encoded CA certificate (File, = URL, Inline, System, Insecure): System [ INFO ] Resolving SRV record 'home.doonga.org' [ INFO ] Connecting to LDAP using 'ldaps://DC1.home.doonga.org:636' [WARNING] Cannot connect using 'ldaps://DC1.home.doonga.org:636': {'info': = 'TLS error -8157:Certificate extension not found.', 'desc': "Can't contact = LDAP server"} [ INFO ] Connecting to LDAP using 'ldaps://DC2.home.doonga.org:636' [WARNING] Cannot connect using 'ldaps://DC2.home.doonga.org:636': {'info': = 'TLS error -8157:Certificate extension not found.', 'desc': "Can't contact = LDAP server"} [ INFO ] Connecting to LDAP using 'ldaps://DC3.home.doonga.org:636' [WARNING] Cannot connect using 'ldaps://DC3.home.doonga.org:636': {'info': = 'TLS error -8157:Certificate extension not found.', 'desc': "Can't contact = LDAP server"} [ ERROR ] Cannot connect using any of available options Also: 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_extension_aaa_ldap.ldap= .common common._connectLDAP:391 Connecting to LDAP using 'ldap://DC2.home.d= oonga.org:389' 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_extension_aaa_ldap.ldap= .common common._connectLDAP:442 Executing startTLS 2017-07-15 18:18:06 DEBUG otopi.plugins.ovirt_engine_extension_aaa_ldap.lda= p.common common._connectLDAP:459 Exception Traceback (most recent call last): File "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovi= rt-engine-extension-aaa-ldap/ldap/common.py", line 443, in _connectLDAP c.start_tls_s() File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 564, i= n start_tls_s return self._ldap_call(self._l.start_tls_s) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in= _ldap_call result =3D func(*args,**kwargs) CONNECT_ERROR: {'info': 'TLS error -8157:Certificate extension not found.',= 'desc': 'Connect error'} 2017-07-15 18:18:06 WARNING otopi.plugins.ovirt_engine_extension_aaa_ldap.l= dap.common common._connectLDAP:463 Cannot connect using 'ldap://DC2.home.do= onga.org:389': {'info': 'TLS error -8157:Certificate extension not found.',= 'desc': 'Connect error'} 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_extension_aaa_ldap.ldap= .common common._connectLDAP:391 Connecting to LDAP using 'ldap://DC3.home.d= oonga.org:389' 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_extension_aaa_ldap.ldap= .common common._connectLDAP:442 Executing startTLS 2017-07-15 18:18:06 DEBUG otopi.plugins.ovirt_engine_extension_aaa_ldap.lda= p.common common._connectLDAP:459 Exception Traceback (most recent call last): File "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovi= rt-engine-extension-aaa-ldap/ldap/common.py", line 443, in _connectLDAP c.start_tls_s() File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 564, i= n start_tls_s return self._ldap_call(self._l.start_tls_s) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in= _ldap_call result =3D func(*args,**kwargs) CONNECT_ERROR: {'info': 'TLS error -8157:Certificate extension not found.',= 'desc': 'Connect error'} Any help would be appreciated! Thanks --_000_ff591869654646c7bc8df4c4af6d898fdoongaorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi,<o:p></o:p>         &nbs= p;      I’ve been pulling my hair out over t= his one. Here’s the output of ovirt-engine-extension-aaa-ldap-setup. = Everything works fine if I use “plain” but I don’t really= want to do that. I searched the error that’s shown below and tried several different “fixes” but none of them helped. These= are Server 2016 DCs. Not too sure where to go next.<o:p></o:p> <o:p> </o:p> [ INFO  ] Stage: Initializing<o:p></o:p> [ INFO  ] Stage: Environment setup<o:p></o:p></= p>         &nbs= p; Configuration files: ['/etc/ovirt-engine-extension-aaa-ldap-setup.conf.d= /10-packaging.conf']<o:p></o:p>         &nbs= p; Log file: /tmp/ovirt-engine-extension-aaa-ldap-setup-20170715170953-wfo1= pk.log<o:p></o:p>         &nbs= p; Version: otopi-1.6.2 (otopi-1.6.2-1.el7.centos)<o:p></o:p> [ INFO  ] Stage: Environment packages setup<o:p= ></o:p> [ INFO  ] Stage: Programs detection<o:p></o:p><= /p> [ INFO  ] Stage: Environment customization<o:p>= </o:p>         &nbs= p; Welcome to LDAP extension configuration program<o:p></o:p>         &nbs= p; Available LDAP implementations:<o:p></o:p>         &nbs= p;  1 - 389ds<o:p></o:p>         &nbs= p;  2 - 389ds RFC-2307 Schema<o:p></o:p>         &nbs= p;  3 - Active Directory<o:p></o:p>         &nbs= p;  4 - IBM Security Directory Server<o:p></o:p>         &nbs= p;  5 - IBM Security Directory Server RFC-2307 Schema<o:p></o:p>         &nbs= p;  6 - IPA<o:p></o:p>         &nbs= p;  7 - Novell eDirectory RFC-2307 Schema<o:p></o:p>         &nbs= p;  8 - OpenLDAP RFC-2307 Schema<o:p></o:p>          &nb= sp; 9 - OpenLDAP Standard Schema<o:p></o:p>         &nbs= p; 10 - Oracle Unified Directory RFC-2307 Schema<o:p></o:p>         &nbs= p; 11 - RFC-2307 Schema (Generic)<o:p></o:p>         &nbs= p; 12 - RHDS<o:p></o:p>         &nbs= p; 13 - RHDS RFC-2307 Schema<o:p></o:p>         &nbs= p; 14 - iPlanet<o:p></o:p>         &nbs= p; Please select: 3<o:p></o:p>         &nbs= p; Please enter Active Directory Forest name: home.doonga.org<o:p></o:p></p= > [ INFO  ] Resolving Global Catalog SRV record f= or home.doonga.org<o:p></o:p> [ INFO  ] Resolving LDAP SRV record for home.do= onga.org<o:p></o:p>         &nbs= p; NOTE:<o:p></o:p>         &nbs= p; It is highly recommended to use secure protocol to access the LDAP serve= r.<o:p></o:p>         &nbs= p; Protocol startTLS is the standard recommended method to do so.<o:p></o:p= >         &nbs= p; Only in cases in which the startTLS is not supported, fallback to non st= andard ldaps protocol.<o:p></o:p>         &nbs= p; Use plain for test environments only.<o:p></o:p>         &nbs= p; Please select protocol to use (startTLS, ldaps, plain) [startTLS]: ldaps= <o:p></o:p>         &nbs= p; Please select method to obtain PEM encoded CA certificate (File, URL, In= line, System, Insecure): System<o:p></o:p> [ INFO  ] Resolving SRV record 'home.doonga.org= '<o:p></o:p> [ INFO  ] Connecting to LDAP using 'ldaps://DC1= .home.doonga.org:636'<o:p></o:p> [WARNING] Cannot connect using 'ldaps://DC1.home.doo= nga.org:636': {'info': 'TLS error -8157:Certificate extension not found.', = 'desc': "Can't contact LDAP server"}<o:p></o:p> [ INFO  ] Connecting to LDAP using 'ldaps://DC2= .home.doonga.org:636'<o:p></o:p> [WARNING] Cannot connect using 'ldaps://DC2.home.doo= nga.org:636': {'info': 'TLS error -8157:Certificate extension not found.', = 'desc': "Can't contact LDAP server"}<o:p></o:p> [ INFO  ] Connecting to LDAP using 'ldaps://DC3= .home.doonga.org:636'<o:p></o:p> [WARNING] Cannot connect using 'ldaps://DC3.home.doo= nga.org:636': {'info': 'TLS error -8157:Certificate extension not found.', = 'desc': "Can't contact LDAP server"}<o:p></o:p> [ ERROR ] Cannot connect using any of available opti= ons<o:p></o:p> <o:p> </o:p> Also:<o:p></o:p> 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_= extension_aaa_ldap.ldap.common common._connectLDAP:391 Connecting to LDAP u= sing 'ldap://DC2.home.doonga.org:389'<o:p></o:p> 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_= extension_aaa_ldap.ldap.common common._connectLDAP:442 Executing startTLS<o= :p></o:p> 2017-07-15 18:18:06 DEBUG otopi.plugins.ovirt_engine= _extension_aaa_ldap.ldap.common common._connectLDAP:459 Exception<o:p></o:p= > Traceback (most recent call last):<o:p></o:p>   File "/usr/share/ovirt-engine-extension-= aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.p= y", line 443, in _connectLDAP<o:p></o:p>     c.start_tls_s()<o:p></o:p>   File "/usr/lib64/python2.7/site-packages= /ldap/ldapobject.py", line 564, in start_tls_s<o:p></o:p>     return self._ldap_call(self._l.st= art_tls_s)<o:p></o:p>   File "/usr/lib64/python2.7/site-packages= /ldap/ldapobject.py", line 99, in _ldap_call<o:p></o:p>     result =3D func(*args,**kwargs)<o= :p></o:p> CONNECT_ERROR: {'info': 'TLS error -8157:Certificate= extension not found.', 'desc': 'Connect error'}<o:p></o:p> 2017-07-15 18:18:06 WARNING otopi.plugins.ovirt_engi= ne_extension_aaa_ldap.ldap.common common._connectLDAP:463 Cannot connect us= ing 'ldap://DC2.home.doonga.org:389': {'info': 'TLS error -8157:Certificate= extension not found.', 'desc': 'Connect error'}<o:p></o:p> 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_= extension_aaa_ldap.ldap.common common._connectLDAP:391 Connecting to LDAP u= sing 'ldap://DC3.home.doonga.org:389'<o:p></o:p> 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_= extension_aaa_ldap.ldap.common common._connectLDAP:442 Executing startTLS<o= :p></o:p> 2017-07-15 18:18:06 DEBUG otopi.plugins.ovirt_engine= _extension_aaa_ldap.ldap.common common._connectLDAP:459 Exception<o:p></o:p= > Traceback (most recent call last):<o:p></o:p>   File "/usr/share/ovirt-engine-extension-= aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.p= y", line 443, in _connectLDAP<o:p></o:p>     c.start_tls_s()<o:p></o:p>   File "/usr/lib64/python2.7/site-packages= /ldap/ldapobject.py", line 564, in start_tls_s<o:p></o:p>     return self._ldap_call(self._l.st= art_tls_s)<o:p></o:p>   File "/usr/lib64/python2.7/site-packages= /ldap/ldapobject.py", line 99, in _ldap_call<o:p></o:p>     result =3D func(*args,**kwargs)<o= :p></o:p> CONNECT_ERROR: {'info': 'TLS error -8157:Certificate= extension not found.', 'desc': 'Connect error'}<o:p></o:p> <o:p> </o:p> Any help would be appreciated!<o:p></o:p> Thanks<o:p></o:p> </div> </body> </html> --_000_ff591869654646c7bc8df4c4af6d898fdoongaorg_--

2 3

Engine HA-Issues
by Sven Achtelik 17 Jul '17

17 Jul '17

--_000_BFAB40933B3367488CE6299BAF8592D1014E52E495ACSOCRATESasl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, after running solid for several month my ovirt-engine started rebooting on = several hosts. I've looked into the hostend-engine -vm-status and it sees t= hat the engine is up on one host but not reachable. At the same time I can = access the gui and everything is working fine. After some time the engine i= s shutting down and all hosts are trying to start the engine until one is t= he winner, at least it looks like this. Any clues where to look at and find= the issue with the liveliness check ? ---------------------------------------------------------------------------= ----------------------------- --=3D=3D Host 1 status =3D=3D-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt-node01 Host ID : 1 Engine status : {"reason": "vm not running on this hos= t", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 3eb33843 local_conf_timestamp : 17128 Host timestamp : 17113 Extra metadata (valid at timestamp): metadata_parse_version=3D1 metadata_feature_version=3D1 timestamp=3D17113 (Fri Jul 14 11:50:23 2017) host-id=3D1 score=3D3400 vm_conf_refresh_time=3D17128 (Fri Jul 14 11:50:38 2017) conf_on_shared_storage=3DTrue maintenance=3DFalse state=3DEngineDown stopped=3DFalse --=3D=3D Host 2 status =3D=3D-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt-node02.mgmt.lan Host ID : 2 Engine status : {"reason": "failed liveliness check", = "health": "bad", "vm": "up", "detail": "up"} Score : 3400 stopped : False Local maintenance : False crc32 : 2a8c86cc local_conf_timestamp : 523182 Host timestamp : 523167 Extra metadata (valid at timestamp): metadata_parse_version=3D1 metadata_feature_version=3D1 timestamp=3D523167 (Fri Jul 14 11:50:25 2017) host-id=3D2 score=3D3400 vm_conf_refresh_time=3D523182 (Fri Jul 14 11:50:40 2017) conf_on_shared_storage=3DTrue maintenance=3DFalse state=3DEngineStarting stopped=3DFalse --=3D=3D Host 3 status =3D=3D-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt-node03.mgmt.lan Host ID : 3 Engine status : {"reason": "vm not running on this hos= t", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : f8490d79 local_conf_timestamp : 527698 Host timestamp : 527683 Extra metadata (valid at timestamp): metadata_parse_version=3D1 metadata_feature_version=3D1 timestamp=3D527683 (Fri Jul 14 11:50:33 2017) host-id=3D3 score=3D3400 vm_conf_refresh_time=3D527698 (Fri Jul 14 11:50:47 2017) conf_on_shared_storage=3DTrue maintenance=3DFalse state=3DEngineDown stopped=3DFalse ---------------------------------------------------------------------------= ------------------- Thank you, Sven --_000_BFAB40933B3367488CE6299BAF8592D1014E52E495ACSOCRATESasl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 15 (filtered medium)"><style></style></head><body lang=3DDE link=3D"#0563C1" v= link=3D"#954F72"><div class=3DWordSection1>Hi All, <o:= p></o:p><o:p> </o:p>= after running solid for several month my ovirt-engine st= arted rebooting on several hosts. I’ve looked into the hostend-engine= –vm-status and it sees that the engine is up on one host but not rea= chable. At the same time I can access the gui and everything is working fin= e. After some time the engine is shutting down and all hosts are trying to = start the engine until one is the winner, at least it looks like this. Any = clues where to look at and find the issue with the liveliness check ? <o:p>= </o:p><o:p> </o:p><= /span>-------------------------= ---------------------------------------------------------------------------= ----<o:p></o:p><o:p>&nbs= p;</o:p>--=3D=3D Host 1 = status =3D=3D--<o:p></o:p><o:p> </o:p>conf_= on_shared_storage          &nb= sp;  : True<o:p></o:p>Status up-to-date        &= nbsp;         : True<o:p></o:p></sp= an>Hostname   &n= bsp;           &nbsp= ;           : ovirt-node0= 1<o:p></o:p>Host ID&nbsp= ;            &n= bsp;           &nbsp= ;  : 1<o:p></o:p>En= gine status          &nbs= p;           : {"rea= son": "vm not running on this host", "health": &qu= ot;bad", "vm": "down", "detail": "u= nknown"}<o:p></o:p>= Score           &nbs= p;            &= nbsp;     : 3400<o:p></o:p>stopped       &nb= sp;            =         : False<o:p></o:p>Local maintenance   &nb= sp;            =   : False<o:p></o:p>crc32           &nb= sp;            =       : 3eb33843<o:p></o:p>local_conf_timestamp    &nb= sp;          : 17128<o:p></o:p= >Host timestamp &nb= sp;            &nbsp= ;      : 17113<o:p></o:p>Extra metadata (valid at timestamp):<o:p></= o:p>   &n= bsp;    metadata_parse_version=3D1<o:p></o:p>      &nb= sp; metadata_feature_version=3D1<o:p></o:p>=         timestamp=3D1= 7113 (Fri Jul 14 11:50:23 2017)<o:p></o:p><= span lang=3DEN-US>        host-id=3D1<o:= p></o:p>  &nbs= p;     score=3D3400<o:p></o:p>        vm_con= f_refresh_time=3D17128 (Fri Jul 14 11:50:38 2017)<o:p></o:p>      &nb= sp; conf_on_shared_storage=3DTrue<o:p></o:p>        maintenance= =3DFalse<o:p></o:p>&nbsp= ;       state=3DEngineDown<o:p></o:p><= /p>     &n= bsp;  stopped=3DFalse<o:p></o:p><o:p> </o:p><o:p> </o:p>-= -=3D=3D Host 2 status =3D=3D--<o:p></o:p><s= pan lang=3DEN-US><o:p> </o:p>conf_on_shared_storage       &= nbsp;     : True<o:p></o:p>Status up-to-date     &nbsp= ;            : True<= o:p></o:p>Hostname =             &nb= sp;            = : ovirt-node02.mgmt.lan<o:p></o:p>Host ID         &nb= sp;            =       : 2<o:p></o:p>Engine status      &nbsp= ;            &n= bsp;  : {"reason": "failed liveliness check", &quo= t;health": "bad", "vm": "up", "deta= il": "up"}<o:p></o:p>Score         &nbs= p;            &= nbsp;       : 3400<o:p></o:p>stopped     &nb= sp;            =           : False<o:p></o:p></= span>Local maintenance &nb= sp;            =     : False<o:p></o:p>crc32         &nb= sp;            =         : 2a8c86cc<o:p></o:p>= local_conf_timestamp  &nb= sp;            : 523= 182<o:p></o:p>Host times= tamp           &nbsp= ;         : 523167<o:p></o:p></span= >Extra metadata (valid at times= tamp):<o:p></o:p> &= nbsp;      metadata_parse_version=3D1<o:p></o:p></= span>    &n= bsp;   metadata_feature_version=3D1<o:p></o:p>        = timestamp=3D523167 (Fri Jul 14 11:50:25 2017)<o:p></o:p>        = host-id=3D2<o:p></o:p>&n= bsp;       score=3D3400<o:p></o:p>=      &nbsp= ;  vm_conf_refresh_time=3D523182 (Fri Jul 14 11:50:40 2017)<o:p></o:p>=     =     conf_on_shared_storage=3DTrue<o:p></o:p>      &nbs= p; maintenance=3DFalse<o:p></o:p>        state=3DEngineStarting<= o:p></o:p>  &n= bsp;     stopped=3DFalse<o:p></o:p><o:p> </o:p><o:p> </o:p><= span lang=3DEN-US>--=3D=3D Host 3 status =3D=3D--<o:p></o:p><o:p> </o:p>conf_on_shared_storage    =          : True<o:p></o:p></= p>Status up-to-date  &nbs= p;            &= nbsp;  : True<o:p></o:p>Hostname          &n= bsp;           &nbsp= ;    : ovirt-node03.mgmt.lan<o:p></o:p>Host ID      =             &nb= sp;         : 3<o:p></o:p></= p>Engine status   &n= bsp;           &nbsp= ;      : {"reason": "vm not running= on this host", "health": "bad", "vm": &= quot;down", "detail": "unknown"}<o:p></o:p>= Score    &n= bsp;            &nbs= p;            := 3400<o:p></o:p>stopped&= nbsp;           &nbs= p;            &= nbsp;  : False<o:p></o:p>Local maintenance        &nbs= p;         : False<o:p></o:p></span= >crc32    &= nbsp;           &nbs= p;             = : f8490d79<o:p></o:p>loc= al_conf_timestamp         &nbs= p;     : 527698<o:p></o:p>Host timestamp      &nb= sp;            =   : 527683<o:p></o:p>Extra metadata (valid at timestamp):<o:p></o:p>        metadat= a_parse_version=3D1<o:p></o:p>        metadata_feature_version= =3D1<o:p></o:p> &nb= sp;      timestamp=3D527683 (Fri Jul 14 11:50:33 2= 017)<o:p></o:p> &nb= sp;      host-id=3D3<o:p></o:p>        = score=3D3400<o:p></o:p>&= nbsp;       vm_conf_refresh_time=3D527698 (Fr= i Jul 14 11:50:47 2017)<o:p></o:p>        conf_on_shared_storage= =3DTrue<o:p></o:p> =        maintenance=3DFalse<o:p></o:p><= /p>     &n= bsp;  state=3DEngineDown<o:p></o:p><sp= an lang=3DEN-US>        stopped=3DFalse<= o:p></o:p><o:p> </o= :p>---------------------= -------------------------------------------------------------------------<o= :p></o:p>Thank you, <o:p= ></o:p>Sven <o:p></o:p><= /span></div></body></html>= --_000_BFAB40933B3367488CE6299BAF8592D1014E52E495ACSOCRATESasl_--

2 2

Installation oVirt node and engine on the same machine
by wc hung 17 Jul '17

17 Jul '17

Hi all, Could we install oVirt node and engine on the same machine? If we can do that, is there any guide to show the step?

4 6

[Ovirt 4.0] Cluster : Scheduling policy
by TranceWorldLogic . 16 Jul '17

16 Jul '17

Hi, Can some one help me how to select PinToHost policy in ovirt 4.0 ? I am lost in GUI. http://www.ovirt.org/develop/release-management/features/sla/scheduler-poli… Thanks, ~Rohit

2 2

Re: [ovirt-users] oVIRT 4.1.3 / iSCSI / VM Multiple Disks / Snapshot deletion issue.
by Benny Zlotnik 16 Jul '17

16 Jul '17

[Adding ovirt-users] On Sun, Jul 16, 2017 at 12:58 PM, Benny Zlotnik <bzlotnik(a)redhat.com> wrote: > We can see a lot of related errors in the engine log but we are unable > to correlate to the vdsm log. Do you have more hosts? If yes, please > attach their logs as well. > And just to be sure you were attempting to perform cold merge? > > On Fri, Jul 14, 2017 at 7:32 PM, Devin Acosta <devin(a)pabstatencio.com> wrote: >> >> You can get my logs from: >> >> https://files.linuxstack.cloud/s/NjoyMF11I38rJpH >> >> They were a little to big to attach to this e-mail. Would like to know if >> this is the similar bug that Richard indicated is a possibility. >> >> -- >> >> Devin Acosta >> Red Hat Certified Architect, LinuxStack >> 602-354-1220 || devin(a)linuxguru.co >> >> On July 14, 2017 at 9:18:08 AM, Devin Acosta (devin(a)pabstatencio.com) wrote: >> >> I have attached the logs. >> >> >> >> -- >> >> Devin Acosta >> Red Hat Certified Architect, LinuxStack >> 602-354-1220 || devin(a)linuxguru.co >> >> On July 13, 2017 at 9:22:03 AM, richard anthony falzini >> (richardfalzini(a)gmail.com) wrote: >> >> Hi, >> i have the same problem with gluster. >> this is a bug that i opened >> https://bugzilla.redhat.com/show_bug.cgi?id=1461029 . >> In the bug i used single disk vm but i start to notice the problem with >> multiple disk vm. >> >> >> 2017-07-13 0:07 GMT+02:00 Devin Acosta <devin(a)pabstatencio.com>: >>> >>> We are running a fresh install of oVIRT 4.1.3, using ISCSI, the VM in >>> question has multiple Disks (4 to be exact). It snapshotted OK while on >>> iSCSI however when I went to delete the single snapshot that existed it went >>> into Locked state and never came back. The deletion has been going for well >>> over an hour, and I am not convinced since the snapshot is less than 12 >>> hours old that it’s really doing anything. >>> >>> I have seen that doing some Googling indicates there might be some known >>> issues with iSCSI/Block Storage/Multiple Disk Snapshot issues. >>> >>> In the logs on the engine it shows: >>> >>> 2017-07-12 21:59:42,473Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 21:59:52,480Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 21:59:52,483Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:02,490Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:02,493Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:12,498Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:12,501Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:22,508Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:22,511Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> >>> This is what I seen on the SPM when I grep’d the Snapshot ID. >>> >>> 2017-07-12 14:22:18,773-0700 INFO (jsonrpc/6) [vdsm.api] START >>> createVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', size=u'107374182400', >>> volFormat=4, preallocate=2, diskType=2, >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', desc=u'', >>> srcImgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> srcVolUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', initialSize=None) >>> from=::ffff:10.4.64.7,60016, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:46) >>> 2017-07-12 14:22:19,095-0700 WARN (tasks/6) [root] File: >>> /rhev/data-center/00000001-0001-0001-0001-000000000311/0c02a758-4295-4199-97de-b041744b3b15/images/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 >>> already removed (utils:120) >>> 2017-07-12 14:22:19,096-0700 INFO (tasks/6) [storage.Volume] Request to >>> create snapshot >>> 6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 of >>> volume >>> 6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae >>> (blockVolume:545) >>> 2017-07-12 14:22:19,676-0700 INFO (tasks/6) [storage.LVM] Change LV tags >>> (vg=0c02a758-4295-4199-97de-b041744b3b15, >>> lv=5921ba71-0f00-46cd-b0be-3c2ac1396845, delTags=['OVIRT_VOL_INITIALIZING'], >>> addTags=['MD_10', u'PU_0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', >>> u'IU_6a887015-67cd-4f7b-b709-eef97142258d']) (lvm:1344) >>> 2017-07-12 14:22:36,010-0700 INFO (jsonrpc/5) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:46) >>> 2017-07-12 14:22:36,077-0700 INFO (jsonrpc/5) [storage.VolumeManifest] >>> Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 5921ba71-0f00-46cd-b0be-3c2ac1396845 (volume:238) >>> 2017-07-12 14:22:36,185-0700 INFO (jsonrpc/5) [storage.VolumeManifest] >>> 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 >>> info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', >>> 'voltype': 'LEAF', 'description': '', 'parent': >>> '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, >>> 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', >>> 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': >>> '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', >>> 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', >>> 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) >>> 2017-07-12 14:22:36,186-0700 INFO (jsonrpc/5) [vdsm.api] FINISH >>> getVolumeInfo return={'info': {'status': 'OK', 'domain': >>> '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': >>> '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', >>> 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': >>> '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', >>> 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': >>> '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': >>> '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} >>> from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:52) >>> 2017-07-12 14:24:24,854-0700 INFO (jsonrpc/1) [vdsm.api] START >>> deleteVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volumes=[u'5921ba71-0f00-46cd-b0be-3c2ac1396845'], postZero=u'false', >>> force=u'false', discard=False) from=::ffff:10.4.64.7,60016, >>> flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) >>> 2017-07-12 14:24:25,010-0700 INFO (tasks/7) [storage.Volume] Request to >>> delete LV 5921ba71-0f00-46cd-b0be-3c2ac1396845 of image >>> 6a887015-67cd-4f7b-b709-eef97142258d in VG >>> 0c02a758-4295-4199-97de-b041744b3b15 (blockVolume:579) >>> 2017-07-12 14:24:25,130-0700 INFO (tasks/7) [storage.VolumeManifest] >>> sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 5921ba71-0f00-46cd-b0be-3c2ac1396845 legality = ILLEGAL (volume:398) >>> 2017-07-12 14:24:38,881-0700 INFO (jsonrpc/2) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:46) >>> 2017-07-12 14:24:49,911-0700 INFO (jsonrpc/1) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:46) >>> 2017-07-12 14:24:49,912-0700 INFO (jsonrpc/1) [storage.VolumeManifest] >>> Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (volume:238) >>> 2017-07-12 14:24:50,036-0700 INFO (jsonrpc/1) [storage.VolumeManifest] >>> 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae >>> info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', >>> 'voltype': 'LEAF', 'description': '', 'parent': >>> '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, >>> 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', >>> 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': >>> '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', >>> 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', >>> 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) >>> 2017-07-12 14:24:50,037-0700 INFO (jsonrpc/1) [vdsm.api] FINISH >>> getVolumeInfo return={'info': {'status': 'OK', 'domain': >>> '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': >>> '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', >>> 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': >>> '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', >>> 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': >>> '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': >>> '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:52) >>> >>> HELP, Right now I am starting to think Block Storage and oVIRT = BAD! >>> >>> >>> >>> >>> -- >>> >>> Devin Acosta >>> Red Hat Certified Architect, LinuxStack >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>

1 0

oVIRT 4.1.3 / iSCSI / VM Multiple Disks / Snapshot deletion issue.
by Devin Acosta 14 Jul '17

14 Jul '17

We are running a fresh install of oVIRT 4.1.3, using ISCSI, the VM in question has multiple Disks (4 to be exact). It snapshotted OK while on iSCSI however when I went to delete the single snapshot that existed it went into Locked state and never came back. The deletion has been going for well over an hour, and I am not convinced since the snapshot is less than 12 hours old that it’s really doing anything. I have seen that doing some Googling indicates there might be some known issues with iSCSI/Block Storage/Multiple Disk Snapshot issues. In the logs on the engine it shows: 2017-07-12 21:59:42,473Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 21:59:52,480Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 21:59:52,483Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:02,490Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:02,493Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:12,498Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:12,501Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:22,508Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:22,511Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete This is what I seen on the SPM when I grep’d the Snapshot ID. 2017-07-12 14:22:18,773-0700 INFO (jsonrpc/6) [vdsm.api] START createVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', size=u'107374182400', volFormat=4, preallocate=2, diskType=2, volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', desc=u'', srcImgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', srcVolUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', initialSize=None) from=::ffff:10.4.64.7,60016, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:46) 2017-07-12 14:22:19,095-0700 WARN (tasks/6) [root] File: /rhev/data-center/00000001-0001-0001-0001-000000000311/0c02a758-4295-4199-97de-b041744b3b15/images/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 already removed (utils:120) 2017-07-12 14:22:19,096-0700 INFO (tasks/6) [storage.Volume] Request to create snapshot 6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 of volume 6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (blockVolume:545) 2017-07-12 14:22:19,676-0700 INFO (tasks/6) [storage.LVM] Change LV tags (vg=0c02a758-4295-4199-97de-b041744b3b15, lv=5921ba71-0f00-46cd-b0be-3c2ac1396845, delTags=['OVIRT_VOL_INITIALIZING'], addTags=['MD_10', u'PU_0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', u'IU_6a887015-67cd-4f7b-b709-eef97142258d']) (lvm:1344) 2017-07-12 14:22:36,010-0700 INFO (jsonrpc/5) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:46) 2017-07-12 14:22:36,077-0700 INFO (jsonrpc/5) [storage.VolumeManifest] Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 5921ba71-0f00-46cd-b0be-3c2ac1396845 (volume:238) 2017-07-12 14:22:36,185-0700 INFO (jsonrpc/5) [storage.VolumeManifest] 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) 2017-07-12 14:22:36,186-0700 INFO (jsonrpc/5) [vdsm.api] FINISH getVolumeInfo return={'info': {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:52) 2017-07-12 14:24:24,854-0700 INFO (jsonrpc/1) [vdsm.api] START deleteVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volumes=[u'5921ba71-0f00-46cd-b0be-3c2ac1396845'], postZero=u'false', force=u'false', discard=False) from=::ffff:10.4.64.7,60016, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:25,010-0700 INFO (tasks/7) [storage.Volume] Request to delete LV 5921ba71-0f00-46cd-b0be-3c2ac1396845 of image 6a887015-67cd-4f7b-b709-eef97142258d in VG 0c02a758-4295-4199-97de-b041744b3b15 (blockVolume:579) 2017-07-12 14:24:25,130-0700 INFO (tasks/7) [storage.VolumeManifest] sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 5921ba71-0f00-46cd-b0be-3c2ac1396845 legality = ILLEGAL (volume:398) 2017-07-12 14:24:38,881-0700 INFO (jsonrpc/2) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:49,911-0700 INFO (jsonrpc/1) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', options=None) from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:49,912-0700 INFO (jsonrpc/1) [storage.VolumeManifest] Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (volume:238) 2017-07-12 14:24:50,036-0700 INFO (jsonrpc/1) [storage.VolumeManifest] 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) 2017-07-12 14:24:50,037-0700 INFO (jsonrpc/1) [vdsm.api] FINISH getVolumeInfo return={'info': {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:52) HELP, Right now I am starting to think Block Storage and oVIRT = BAD! -- Devin Acosta Red Hat Certified Architect, LinuxStack

4 5

oVirt Metrics
by Arsène Gschwind 14 Jul '17

14 Jul '17

This is a multi-part message in MIME format. --------------9A99E910BE6E6C7F1C6C0B2C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I'm trying to setup oVirt metrics as described at https://www.ovirt.org/develop/release-management/features/engine/metrics-st… using SSO. My oVirt installation is based on Version: 4.1.3.5-1.el7.centos. I'm missing the SSO tool called ovirt-register-sso-client as written in the doc to register new SSO client. I couldn't figure out which package contains that tool, is it included in the latest distribution ? Thanks for any help. rgds, Arsène -- *Arsène Gschwind* Fa. Sapify AG im Auftrag der Universität Basel IT Services Klingelbergstr. 70 | CH-4056 Basel | Switzerland Tel. +41 79 449 25 63 | http://its.unibas.ch <http://its.unibas.ch/> ITS-ServiceDesk: support-its(a)unibas.ch | +41 61 267 14 11 --------------9A99E910BE6E6C7F1C6C0B2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi all, I'm trying to setup oVirt metrics as described at <a class="moz-txt-link-freetext" href="https://www.ovirt.org/develop/release-management/features/engine/metrics-st…">https://www.ovirt.org/develop/release-management/features/engine/metrics-st…</a> using SSO. My oVirt installation is based on Version: 4.1.3.5-1.el7.centos. I'm missing the SSO tool called ovirt-register-sso-client as written in the doc to register new SSO client. I couldn't figure out which package contains that tool, is it included in the latest distribution ? Thanks for any help. rgds, Arsène <div class="moz-signature">-- Arsène Gschwind Fa. Sapify AG im Auftrag der Universität Basel IT Services Klingelbergstr. 70 | CH-4056 Basel | Switzerland Tel. +41 79 449 25 63 | <a href="http://its.unibas.ch/"> http://its.unibas.ch </a> ITS-ServiceDesk: <a class="moz-txt-link-abbreviated" href="mailto:support-its@unibas.ch">support-its(a)unibas.ch</a> | +41 61 267 14 11 </div> </body> </html> --------------9A99E910BE6E6C7F1C6C0B2C--

3 2

Fwd: Windows USB Redirection
by Abi Askushi 14 Jul '17

14 Jul '17

Hi All, I have Ovirt 4.1 with 3 nodes on top glusterfs. I Have 2 VMs: Windows 2016 64bit and Windows 10 64bit When I attach a USB flash disk to a VM (from host devices) the VM cannot see the USB drive and report driver issue at device manager (see attached). This happens with both VMs when tested. When testing with Windows 7 or Windows XP USB is attached and accessed normally. Have you encountered such issue? I have installed latest guest tools on both VMs. Many thanx

2 3

Removing iSCSI domain: host side part
by Gianluca Cecchi 14 Jul '17

14 Jul '17

Hello, I have cleanly removed an iSCSI domain from oVirt. There is another one (connecting to another storage array) that is the master domain. But I see that oVirt hosts still maintain the iscsi session to the LUN. So I want to clean from os point of view before removing the LUN itself from storage. At the moment I still see the multipath lun on both hosts [root@ov301 network-scripts]# multipath -l . . . 364817197b5dfd0e5538d959702249b1c dm-2 EQLOGIC ,100E-00 size=4.0T features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=0 status=active |- 9:0:0:0 sde 8:64 active undef running `- 10:0:0:0 sdf 8:80 active undef running and [root@ov301 network-scripts]# iscsiadm -m session tcp: [1] 10.10.100.9:3260,1 iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910 (non-flash) tcp: [2] 10.10.100.9:3260,1 iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910 (non-flash) . . . Do I have to clean the multipath paths and multipath device and then iSCSI logout, or is it sufficient to iSCSI logout and the multipath device and its path will be cleanly removed from OS point of view? I would like not to have multipath device in stale condition. Thanks Gianluca

2 2