- Users - oVirt List Archives

Few Questions on New Install
by Talk Jesus 12 Feb '18

12 Feb '18

Greetings, Just installed Ovirt: Software Version:4.2.0.2-1.el7.centos How Do I: - add a subnet of IPv4 to assign to VMs - download (or import) basic Linux templates like Centos 7, Ubuntu 16 even if using minimal iso - import from SolusVM based KVM nodes Does oVirt support bulk IPv4 assignment to VMs? If I wish to assign say a full /26 subnet of IPv4 to VM #1, is this a one click option? Thank you. I read the docs, but everything is a bit confusing for me.

2 1

Network Topologies
by aeR7Re 11 Feb '18

11 Feb '18

This is a multi-part message in MIME format. --b1_bf9e7016867c417f2a03f0009ce95b53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGVsbG8sCkknbSBsb29raW5nIGZvciBzb21lIGFkdmljZSBvbiBvciBldmVuIGp1c3Qgc29tZSBl eGFtcGxlcyBvZiBob3cgb3RoZXIgb1ZpcnQgdXNlcnMgaGF2ZSBjb25maWd1cmVkIG5ldHdvcmtp bmcgaW5zaWRlIHRoZWlyIGNsdXN0ZXJzLgoKQ3VycmVudGx5IHdlJ3JlIHJ1bm5pbmcgYSBjbHVz dGVyIHdpdGggaG9zdHMgc3ByZWFkIGFjcm9zcyBtdWx0aXBsZSByYWNrcyBpbiBvdXIgREMsIHdp dGggbGF5ZXIgMiBzcGFubmVkIGJldHdlZW4gdGhlbSBmb3IgVk0gbmV0d29ya3MuIFdoaWxlIHRo aXMgaXMgZnVuY3Rpb25hbCwgaXQncyAxMDAlIG5vdCBpZGVhbCBhcyB0aGVyZSdzIG11bHRpcGxl IHNpbmdsZSBwb2ludHMgb2YgZmFpbHVyZSBhbmQgYXQgc29tZSBwb2ludCBzb21lb25lIGlzIGdv aW5nIHRvIGFjY2lkZW50YWxseSBsb29wIGl0IDopCgpXaGF0IHdlJ3JlIGFmdGVyIGlzIGEgbWV0 aG9kIG9mIHByb3ZpZGluZyBhIFZNIG5ldHdvcmsgYWNyb3NzIG11bHRpcGxlIHJhY2tzIHdoZXJl IHRoZXJlIGFyZSBubyBzaW5nbGUgcG9pbnRzIG9mIGZhaWx1cmUuIFdlJ3ZlIGdvdCBsYXllciAz IHN3aXRjaGVzIGluIHJhY2tzIGNhcGFibGUgb2YgcnVubmluZyBhbiBJR1AvRUdQLgoKQ3VycmVu dCBpZGVhczoKLSBSdW4gYSByb3V0aW5nIGRhZW1vbiBvbiBlYWNoIFZNIGFuZCBoYXZlIGl0IGFk dmVydGlzZSBhIC8zMiB0byB0aGUgZGlzdHJpYnV0aW9uIHN3aXRjaAotIE9WTiBmb3IgbGF5ZXIg MiBiZXR3ZWVuIGhvc3RzICsgcG90ZW50aWFsbHkgVlJSUCBvciBzaW1pbGFyIG9uIHRoZSBkaXN0 cmlidXRpb24gc3dpdGNoCgpTbyBhcyBwZXIgbXkgb3JpZ2luYWwgcGFyYWdyYXBoLCBhbnkgYWR2 aWNlIG9uIHRoZSBtb3N0IGFwcHJvcHJpYXRlIG5ldHdvcmsgdG9wb2xvZ3kgZm9yIGFuIG9WaXJ0 IGNsdXN0ZXI/IG9yIGhvdyBoYXZlIHlvdSBzZXQgdXAgeW91ciBuZXR3b3Jrcz8KClRoYW5rIHlv dQoKU2VudCB3aXRoIFtQcm90b25NYWlsXShodHRwczovL3Byb3Rvbm1haWwuY29tKSBTZWN1cmUg RW1haWwu --b1_bf9e7016867c417f2a03f0009ce95b53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5IZWxsbyw8YnI+PC9kaXY+PGRpdj5JJ20gbG9va2luZyBmb3Igc29tZSBhZHZpY2Ugb24g b3IgZXZlbiBqdXN0IHNvbWUgZXhhbXBsZXMgb2YgaG93IG90aGVyIG9WaXJ0IHVzZXJzIGhhdmUg Y29uZmlndXJlZCBuZXR3b3JraW5nIGluc2lkZSB0aGVpciBjbHVzdGVycy4gPGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+Q3VycmVudGx5IHdlJ3JlIHJ1bm5pbmcgYSBjbHVzdGVyIHdpdGgg aG9zdHMgc3ByZWFkIGFjcm9zcyBtdWx0aXBsZSByYWNrcyBpbiBvdXIgREMsIHdpdGggbGF5ZXIg MiBzcGFubmVkIGJldHdlZW4gdGhlbSBmb3IgVk0gbmV0d29ya3MuIFdoaWxlIHRoaXMgaXMgZnVu Y3Rpb25hbCwgaXQncyAxMDAlIG5vdCBpZGVhbCBhcyB0aGVyZSdzIG11bHRpcGxlIHNpbmdsZSBw b2ludHMgb2YgZmFpbHVyZSBhbmQgYXQgc29tZSBwb2ludCBzb21lb25lIGlzIGdvaW5nIHRvIGFj Y2lkZW50YWxseSBsb29wIGl0IDopIDxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PldoYXQg d2UncmUgYWZ0ZXIgaXMgYSBtZXRob2Qgb2YgcHJvdmlkaW5nIGEgVk0gbmV0d29yayBhY3Jvc3Mg bXVsdGlwbGUgcmFja3Mgd2hlcmUgdGhlcmUgYXJlIG5vIHNpbmdsZSBwb2ludHMgb2YgZmFpbHVy ZS4gV2UndmUgZ290IGxheWVyIDMgc3dpdGNoZXMgaW4gcmFja3MgY2FwYWJsZSBvZiBydW5uaW5n IGFuIElHUC9FR1AuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Q3VycmVudCBpZGVhczo8 YnI+PC9kaXY+PGRpdj4tIFJ1biBhIHJvdXRpbmcgZGFlbW9uIG9uIGVhY2ggVk0gYW5kIGhhdmUg aXQgYWR2ZXJ0aXNlIGEgLzMyIHRvIHRoZSBkaXN0cmlidXRpb24gc3dpdGNoPGJyPjwvZGl2Pjxk aXY+LSBPVk4gZm9yIGxheWVyIDIgYmV0d2VlbiBob3N0cyArIHBvdGVudGlhbGx5IFZSUlAgb3Ig c2ltaWxhciBvbiB0aGUgZGlzdHJpYnV0aW9uIHN3aXRjaDxicj48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PlNvIGFzIHBlciBteSBvcmlnaW5hbCBwYXJhZ3JhcGgsIGFueSBhZHZpY2Ugb24gdGhl IG1vc3QgYXBwcm9wcmlhdGUgbmV0d29yayB0b3BvbG9neSBmb3IgYW4gb1ZpcnQgY2x1c3Rlcj8g b3IgaG93IGhhdmUgeW91IHNldCB1cCB5b3VyIG5ldHdvcmtzPzxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PlRoYW5rIHlvdTxicj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25h dHVyZV9ibG9jayI+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stdXNlciBw cm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9InBy b3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXByb3RvbiI+U2VudCB3aXRoIDxhIGhyZWY9Imh0dHBz Oi8vcHJvdG9ubWFpbC5jb20iPlByb3Rvbk1haWw8L2E+IFNlY3VyZSBFbWFpbC48YnI+PC9kaXY+ PC9kaXY+PGRpdj48YnI+PC9kaXY+ --b1_bf9e7016867c417f2a03f0009ce95b53--

1 0

Re: [ovirt-users] Live migration of VM(0 downtime) while Hypervisor goes down in ovirt
by Luca 'remix_tj' Lorenzetto 11 Feb '18

11 Feb '18

What you're looking at is called fault tolerance in other hypervisors. As far as i know, ovirt doesn't implement such solution. But if your system doesn't support failure recovery done by high availability options, you should take in account to revise your application architecture if you want to keep running on ovirt. Luca Il 10 feb 2018 8:31 AM, "Ranjith P" <ranjithspr13(a)yahoo.com> ha scritto: Hi, >>Who's shutting down the hypervisor? (Or perhaps it is shutdown externally, due to overheating or otherwise?) We need a continuous availability of VM's in our production setup. If the hypervisor goes down due to any hardware failure or work load then VM's above hypervisor will reboot and started on available hypervisors. This is normally happening but it disrupting VM's. Can you suggest a solution in this case? Can we achieve this challenge using glusterfs? Thanks & Regards Ranjith Sent from Yahoo Mail on Android <https://overview.mail.yahoo.com/mobile/?.src=Android> On Sat, Feb 10, 2018 at 2:07 AM, Yaniv Kaul <ykaul(a)redhat.com> wrote: On Fri, Feb 9, 2018 at 9:25 PM, ranjithspr13(a)yahoo.com < ranjithspr13(a)yahoo.com> wrote: Hi, Anyone can suggest how to setup VM Live migration (without restart vm) while Hypervisor goes down in ovirt? I think there are two parts to achieving this: 1. Have a script that migrates VMs off a specific host. This should be easy to write using the Python/Ruby/Java SDK, Ansible or using REST directly. 2. Having this script run as a service when a host shuts down, in the right order - well before libvirt and VDSM shut down, and would be fast enough not to be terminated by systemd. This is a bit more challenging. Who's shutting down the hypervisor? (Or perhaps it is shutdown externally, due to overheating or otherwise?) Y. Using glusterfs is it possible? Then how? Thanks & Regards Ranjith Sent from Yahoo Mail on Android <https://overview.mail.yahoo.com/mobile/?.src=Android> ______________________________ _________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/ mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users> _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

VM backups - Bacchus
by Niyazi Elvan 11 Feb '18

11 Feb '18

Dear Friends, It has been a while I could not have time to work on Bacchus. This weekend I created an ansible playbook to replace the installation procedure. You simply download installer.yml and settings.yml files from git repo and run the installer as "ansible-playbook installer.yml" Please check it at https://github.com/openbacchus/bacchus . I recommend you to run the installer on a fresh VM, which has no MySQL DB or previous installation. Hope this helps to more people and please let me know about your ideas. ps. Regarding oVirt 4.2, I had a chance to look at it and tried the new domain type "Backup Domain". This is really cool feature and I am planning to implement the support in Bacchus. Hopefully, CBT will show up soon and we will have a better world :) King Regards, -- Niyazi Elvan

1 0

Maximum time node can be offline.
by Thomas Letherby 11 Feb '18

11 Feb '18

Hello all, Is there a maximum length of time an Ovirt Node 4.2 based host can be offline in a cluster before it would have issues when powered back on? The reason I ask is in my lab I currently have a three node cluster that works really well, however a lot of the time I only actually need the resources of one host, so to save power I'd like to keep the other two offline until needed. I can always script them to boot once a week or so if I need to. Thanks, Thomas

6 8

Live migration of VM(0 downtime) while Hypervisor goes down in ovirt
by ranjithspr13＠yahoo.com 10 Feb '18

10 Feb '18

------=_Part_1968242_1358094662.1518204324810 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi,Anyone can suggest how to setup VM Live migration (without restart vm) while Hypervisor goes down in ovirt?Using glusterfs is it possible? Then how? Thanks & RegardsRanjith Sent from Yahoo Mail on Android ------=_Part_1968242_1358094662.1518204324810 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi,<div id="yMail_cursorElementTracker_1518203906835">Anyone can suggest how to setup VM Live migration (without restart vm) while Hypervisor goes down in ovirt?</div><div id="yMail_cursorElementTracker_1518204210420">Using glusterfs is it possible? Then how?</div><div id="yMail_cursorElementTracker_1518204099547"> </div><div id="yMail_cursorElementTracker_1518204100461">Thanks & Regards</div><div id="yMail_cursorElementTracker_1518204113848">Ranjith <div id="ymail_android_signature"><a href="https://overview.mail.yahoo.com/mobile/?.src=Android">Sent from Yahoo Mail on Android</a></div></div> ------=_Part_1968242_1358094662.1518204324810--

4 3

Importing Libvirt Kvm Vms to oVirt Status: Released in oVirt 4.2 using ssh - Failed to communicate with the external provider
by maoz zadok 09 Feb '18

09 Feb '18

Hello there, I'm following https://www.ovirt.org/develop/release-management/features/virt/KvmToOvirt/ guide in order to import VMS from Libvirt to oVirt using ssh. URL: "qemu+ssh://host1.example.org/system" and get the following error: Failed to communicate with the external provider, see log for additional details. *oVirt agent log:* *- Failed to retrieve VMs information from external server qemu+ssh://XXX.XXX.XXX.XXX/system* *- VDSM XXX command GetVmsNamesFromExternalProviderVDS failed: Cannot recv data: Host key verification failed.: Connection reset by peer* *remote host sshd DEBUG log:* *Feb 7 16:38:29 XXX sshd[110005]: Connection from XXX.XXX.XXX.147 port 48148 on XXX.XXX.XXX.123 port 22* *Feb 7 16:38:29 XXX sshd[110005]: debug1: Client protocol version 2.0; client software version OpenSSH_7.4* *Feb 7 16:38:29 XXX sshd[110005]: debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000* *Feb 7 16:38:29 XXX sshd[110005]: debug1: Local version string SSH-2.0-OpenSSH_7.4* *Feb 7 16:38:29 XXX sshd[110005]: debug1: Enabling compatibility mode for protocol 2.0* *Feb 7 16:38:29 XXX sshd[110005]: debug1: SELinux support disabled [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: permanently_set_uid: 74/74 [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_KEXINIT sent [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_KEXINIT received [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: kex: algorithm: curve25519-sha256 [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: kex: client->server cipher: chacha20-poly1305(a)openssh.com <chacha20-poly1305(a)openssh.com> MAC: <implicit> compression: none [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: kex: server->client cipher: chacha20-poly1305(a)openssh.com <chacha20-poly1305(a)openssh.com> MAC: <implicit> compression: none [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: rekey after 134217728 blocks [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_NEWKEYS sent [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: Connection closed by XXX.XXX.XXX.147 port 48148 [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: do_cleanup [preauth]* *Feb 7 16:38:29 XXX sshd[110005]: debug1: do_cleanup* *Feb 7 16:38:29 XXX sshd[110005]: debug1: Killing privsep child 110006* *Feb 7 16:38:29 XXX sshd[109922]: debug1: Forked child 110007.* *Feb 7 16:38:29 XXX sshd[110007]: debug1: Set /proc/self/oom_score_adj to 0* *Feb 7 16:38:29 XXX sshd[110007]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8* *Feb 7 16:38:29 XXX sshd[110007]: debug1: inetd sockets after dupping: 3, 3* *Feb 7 16:38:29 XXX sshd[110007]: Connection from XXX.XXX.XXX.147 port 48150 on XXX.XXX.XXX.123 port 22* *Feb 7 16:38:29 XXX sshd[110007]: debug1: Client protocol version 2.0; client software version OpenSSH_7.4* *Feb 7 16:38:29 XXX sshd[110007]: debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000* *Feb 7 16:38:29 XXX sshd[110007]: debug1: Local version string SSH-2.0-OpenSSH_7.4* *Feb 7 16:38:29 XXX sshd[110007]: debug1: Enabling compatibility mode for protocol 2.0* *Feb 7 16:38:29 XXX sshd[110007]: debug1: SELinux support disabled [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: permanently_set_uid: 74/74 [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: SSH2_MSG_KEXINIT sent [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: SSH2_MSG_KEXINIT received [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: kex: algorithm: curve25519-sha256 [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: kex: client->server cipher: chacha20-poly1305(a)openssh.com <chacha20-poly1305(a)openssh.com> MAC: <implicit> compression: none [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: kex: server->client cipher: chacha20-poly1305(a)openssh.com <chacha20-poly1305(a)openssh.com> MAC: <implicit> compression: none [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: rekey after 134217728 blocks [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: SSH2_MSG_NEWKEYS sent [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: Connection closed by XXX.XXX.XXX.147 port 48150 [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: do_cleanup [preauth]* *Feb 7 16:38:29 XXX sshd[110007]: debug1: do_cleanup* *Feb 7 16:38:29 XXX sshd[110007]: debug1: Killing privsep child 110008* *Feb 7 16:38:30 XXX sshd[109922]: debug1: Forked child 110009.* *Feb 7 16:38:30 XXX sshd[110009]: debug1: Set /proc/self/oom_score_adj to 0* *Feb 7 16:38:30 XXX sshd[110009]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8* *Feb 7 16:38:30 XXX sshd[110009]: debug1: inetd sockets after dupping: 3, 3* *Feb 7 16:38:30 XXX sshd[110009]: Connection from XXX.XXX.XXX.147 port 48152 on XXX.XXX.XXX.123 port 22* *Feb 7 16:38:30 XXX sshd[110009]: debug1: Client protocol version 2.0; client software version OpenSSH_7.4* *Feb 7 16:38:30 XXX sshd[110009]: debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000* *Feb 7 16:38:30 XXX sshd[110009]: debug1: Local version string SSH-2.0-OpenSSH_7.4* *Feb 7 16:38:30 XXX sshd[110009]: debug1: Enabling compatibility mode for protocol 2.0* *Feb 7 16:38:30 XXX sshd[110009]: debug1: SELinux support disabled [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: permanently_set_uid: 74/74 [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: SSH2_MSG_KEXINIT sent [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: SSH2_MSG_KEXINIT received [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: kex: algorithm: curve25519-sha256 [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: kex: client->server cipher: chacha20-poly1305(a)openssh.com <chacha20-poly1305(a)openssh.com> MAC: <implicit> compression: none [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: kex: server->client cipher: chacha20-poly1305(a)openssh.com <chacha20-poly1305(a)openssh.com> MAC: <implicit> compression: none [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: rekey after 134217728 blocks [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: SSH2_MSG_NEWKEYS sent [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: Connection closed by XXX.XXX.XXX.147 port 48152 [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: do_cleanup [preauth]* *Feb 7 16:38:30 XXX sshd[110009]: debug1: do_cleanup* *Feb 7 16:38:30 XXX sshd[110009]: debug1: Killing privsep child 110010* *Feb 7 16:38:30 XXX sshd[109922]: debug1: Forked child 110011.* *Feb 7 16:38:30 XXX sshd[110011]: debug1: Set /proc/self/oom_score_adj to 0* *Feb 7 16:38:30 XXX sshd[110011]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8* *Feb 7 16:38:30 XXX sshd[110011]: debug1: inetd sockets after dupping: 3, 3* *Feb 7 16:38:30 XXX sshd[110011]: Connection from XXX.XXX.XXX.147 port 48154 on XXX.XXX.XXX.123 port 22* *Feb 7 16:38:30 XXX sshd[110011]: debug1: Client protocol version 2.0; client software version OpenSSH_7.4* *Feb 7 16:38:30 XXX sshd[110011]: debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000* *Feb 7 16:38:30 XXX sshd[110011]: debug1: Local version string SSH-2.0-OpenSSH_7.4* *Feb 7 16:38:30 XXX sshd[110011]: debug1: Enabling compatibility mode for protocol 2.0* *Feb 7 16:38:30 XXX sshd[110011]: debug1: SELinux support disabled [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: permanently_set_uid: 74/74 [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: SSH2_MSG_KEXINIT sent [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: SSH2_MSG_KEXINIT received [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: kex: algorithm: curve25519-sha256 [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: kex: client->server cipher: chacha20-poly1305(a)openssh.com <chacha20-poly1305(a)openssh.com> MAC: <implicit> compression: none [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: kex: server->client cipher: chacha20-poly1305(a)openssh.com <chacha20-poly1305(a)openssh.com> MAC: <implicit> compression: none [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: rekey after 134217728 blocks [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: SSH2_MSG_NEWKEYS sent [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]* *Feb 7 16:38:30 XXX sshd[110011]: Connection closed by XXX.XXX.XXX.147 port 48154 [preauth]* Thank you!

3 5

Virt-viewer not working over VPN
by Vincent Royer 09 Feb '18

09 Feb '18

Hi, I asked this on the virt-viewer list, but it appears to be dead, so my apologies if this isn't the right place for this question. When I access my vm's locally using virt-viewer on windows clients, everything works fine, spice or vnc. When I access the same vm's remotely over a site-to-site VPN (setup between the two firewalls), it fails with an error: unable to connect to libvirt with uri: [none]. Similarly I cannot connect in a browser-based vnc session (cannot connect to host). I can resolve the DNS of the server from my remote client (domain override in the firewall pointing to the DNS server locally) and everything else I do seems completely unaware of the vpn link (SSH, RDP, etc). For example connecting to https://ovirt-enginr.mydomain.com works as expected. The only function not working remotely is virt-viewer. Any clues would be appreciated!

2 1

Re: [ovirt-users] Ovirt backups lead to unresponsive VM
by Alex K 09 Feb '18

09 Feb '18

Ok. I will reproduce and collect logs. Thanx, Alex On Jan 29, 2018 20:21, "Mahdi Adnan" <mahdi.adnan(a)outlook.com> wrote: I have Windows VMs, both client and server. if you provide the engine.log file we might have a look at it. -- Respectfully *Mahdi A. Mahdi* ------------------------------ *From:* Alex K <rightkicktech(a)gmail.com> *Sent:* Monday, January 29, 2018 5:40 PM *To:* Mahdi Adnan *Cc:* users *Subject:* Re: [ovirt-users] Ovirt backups lead to unresponsive VM Hi, I have observed this logged at host when the issue occurs: VDSM command GetStoragePoolInfoVDS failed: Connection reset by peer or VDSM host.domain command GetStatsVDS failed: Connection reset by peer At engine logs have not been able to correlate. Are you hosting Windows 2016 server and Windows 10 VMs? The weird is that I have same setup on other clusters with no issues. Thanx, Alex On Sun, Jan 28, 2018 at 9:21 PM, Mahdi Adnan <mahdi.adnan(a)outlook.com> wrote: Hi, We have a cluster of 17 nodes, backed by GlusterFS storage, and using this same script for backup. we have no issues with it so far. have you checked engine log file ? -- Respectfully *Mahdi A. Mahdi* ------------------------------ *From:* users-bounces(a)ovirt.org <users-bounces(a)ovirt.org> on behalf of Alex K <rightkicktech(a)gmail.com> *Sent:* Wednesday, January 24, 2018 4:18 PM *To:* users *Subject:* [ovirt-users] Ovirt backups lead to unresponsive VM Hi all, I have a cluster with 3 nodes, using ovirt 4.1 in a self hosted setup on top glusterfs. On some VMs (especially one Windows server 2016 64bit with 500 GB of disk). Guest agents are installed at VMs. i almost always observe that during the backup of the VM the VM is rendered unresponsive (dashboard shows a question mark at the VM status and VM does not respond to ping or to anything). For scheduled backups I use: https://github.com/wefixit-AT/oVirtBackup The script does the following: 1. snapshot VM (this is done ok without any failure) 2. Clone snapshot (this steps renders the VM unresponsive) 3. Export Clone 4. Delete clone 5. Delete snapshot Do you have any similar experience? Any suggestions to address this? I have never seen such issue with hosted Linux VMs. The cluster has enough storage to accommodate the clone. Thanx, Alex

3 6

Cannot Remove Disk
by Donny Davis 09 Feb '18

09 Feb '18

Ovirt 4.2 has been humming away quite nicely for me in the last few months, and now I am hitting an issue when try to touch any api call that has to do with a specific disk. This disk resides on a hyperconverged DC, and none of the other disks seem to be affected. Here is the error thrown. 2018-02-08 10:13:20,005-05 ERROR [org.ovirt.engine.core.bll.storage.disk.RemoveDiskCommand] (default task-22) [7b48d1ec-53a7-497a-af8e-938f30a321cf] Error during ValidateFailure.: org.ovirt.engine.core.bll.quota.InvalidQuotaParametersException: Quota 6156b8dd-50c9-4e8f-b1f3-4a6449b02c7b does not match storage pool 5a497956-0380-021e-0025-00000000035e Any ideas what can be done to fix this?

3 11

Use the "hosted_engine" data domain as data domain for others VM
by yayo (j) 09 Feb '18

09 Feb '18

Hi, Is there any problem to use the "hosted_engine" data domain to put disk of others VM? I have created a "too big" "hosted_engine" data domain so I want to use that space... Thank you

3 2

Info about exporting from vSphere
by Gianluca Cecchi 09 Feb '18

09 Feb '18

Hello, I have this ind of situation. Source env: It is vSphere 6.5 (both vCenter Server appliance and ESXi hosts) where I have an admin account to connect to, but currently only to vCenter and not to the ESXi hosts The VM to be migrated is Windows 2008 R2 SP1 with virtual hw version 8 (ESXi 5.0 and later) and has one boot disk 35Gb and one data disk 250Gb. The SCSI controller is LSI logic sas and network vmxnet3 It has no snapshots at the moment I see in my oVirt 4.1.9 that I can import from: 1) VMware 2) VMware Virtual Appliance and found also related documentations in RHEV 4.1 Virtual Machine Management pdf Some doubts: - what is the best between the 2 methods if I can chose? Their Pros&Cons? - Does 1) imply that I also need the ESXi account? Currently my windows domain account that gives me access to vcenter doesn't work connecting to ESXi hosts - also it seems that 1) is more intrusive, while for 2) I only need to put the ova file into some nfs share... Thanks in advance, Gianluca

2 6

when creating VMs, I don't want hosted_storage to be an option
by Mike Farnam 09 Feb '18

09 Feb '18

Hi All - Is that a way to mark hosted_storage somehow so that it’s not available to add new VMs to? Right now it’s the default storage domain when adding a VM. At the least, I’d like to make another storage domain the default. Is there a way to do this? Thanks

6 8

oVirt CLI Question
by Andrei V 09 Feb '18

09 Feb '18

Hi, How to force power off, and then launch (after timeout e.g. 20sec) particular VM from bash or Python script? Is 20sec is enough to get oVirt engine updated after forced power off ? What happened with this wiki? Seems like it is deleted or moved. http://wiki.ovirt.org/wiki/CLI#Usage Is this project part of oVirt distro? It looks like in state of active development with last updates 2 months ago. https://github.com/fbacchella/ovirtcmd Thanks !

3 2

IndexError python-sdk
by David David 09 Feb '18

09 Feb '18

Hi all. python-ovirt-engine-sdk4-4.2.2-2.el7.centos.x86_64 Issue is that I cant upload a snapshot I get IndexError when do upload_disk_snapshots.py https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_d… Output: Traceback (most recent call last): File "snapshot_upload.py", line 298, in <module> images_chain = get_images_chain(disk_path) File "snapshot_upload.py", line 263, in get_images_chain base_volume = [v for v in volumes_info.values() if 'full-backing-filename' not in v ][0] IndexError: list index out of range

1 0

Re: [ovirt-users] vdsmd fails after upgrade 4.1 -> 4.2
by Frank Rothenstein 08 Feb '18

08 Feb '18

This is a multi-part message in MIME format. ------------MIME--520934545-23878-delim Content-Type: multipart/alternative; boundary="----------MIME--520934545-17562-delim" ------------MIME--520934545-17562-delim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Thomas=2C it seems you were right=2E I followed the instructions to enable hugepages via kernel command line and after reboot vdsmd starts correctly=2E =28I went back to 4=2E1=2E9 in between=2C added the kernel command line and= upgraded to 4=2E2=29 The docs/release notes should mention it - or did I miss it=3F Am Dienstag=2C den 06=2E02=2E2018=2C 17=3A17 -0800 schrieb Thomas Davis=3A= =3E sorry=2C make that=3A =3E=20 =3E hugeadm --pool-list =3E Size Minimum Current Maximum Default =3E 2097152 1024 1024 1024 * =3E 1073741824 4 4 4 =20 =3E=20 =3E=20 =3E On Tue=2C Feb 6=2C 2018 at 5=3A16 PM=2C Thomas Davis =3Ctadavis=40lbl= =2Egov=3E wrote=3A =3E =3E I found that you now need hugepage1g support=2E The error messages= =3E =3E are wrong - it=27s not truly a libvirt problem=2C it=27s hugepages1= g are =3E =3E missing for libvirt=2E =3E =3E=20 =3E =3E add something like=3A =3E =3E=20 =3E =3E default=5Fhugepagesz=3D1G hugepagesz=3D1G hugepages=3D4 hugepagesz= =3D2M =3E =3E hugepages=3D1024 to the kernel command line=2E =3E =3E=20 =3E =3E You can also do a =27yum install libhugetlbfs-utils=27=2C then do= =3A =3E =3E=20 =3E =3E hugeadm --list =3E =3E Mount Point Options =3E =3E /dev/hugepages rw=2Cseclabel=2Crelatime =3E =3E /dev/hugepages1G rw=2Cseclabel=2Crelatime=2Cpagesize=3D1G =3E =3E=20 =3E =3E if you do not see the /dev/hugepages1G listed=2C then vdsmd/libvirt= =3E =3E will not start=2E =3E =3E=20 =3E =3E=20 =3E =3E=20 =3E =3E=20 =3E =3E=20 =3E =3E=20 =3E =3E On Mon=2C Feb 5=2C 2018 at 5=3A49 AM=2C Frank Rothenstein =3Cf=2Ero= thenstein=40bo =3E =3E dden-kliniken=2Ede=3E wrote=3A =3E =3E =3E Hi=2C=20 =3E =3E =3E=20 =3E =3E =3E I=27m currently stuck - after upgrading 4=2E1 to 4=2E2 I cannot= start =3E =3E =3E the=20 =3E =3E =3E host-processes=2E=20 =3E =3E =3E systemctl start vdsmd fails with following lines in journalctl= =3A=20 =3E =3E =3E=20 =3E =3E =3E =3Csnip=3E=20 =3E =3E =3E=20 =3E =3E =3E Feb 05 14=3A40=3A15 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A vdsm=3A Running wait= =5Ffor=5Fnetwork=20 =3E =3E =3E Feb 05 14=3A40=3A15 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A vdsm=3A Running run=5F= init=5Fhooks=20 =3E =3E =3E Feb 05 14=3A40=3A15 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A vdsm=3A Running check= =5Fis=5Fconfigured=20 =3E =3E =3E Feb 05 14=3A40=3A15 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E sasldblistusers2=5B10440=5D=3A DIGEST-MD5 common mech free=20= =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A Error=3A=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A One of the modules is= not configured =3E =3E =3E to=20 =3E =3E =3E work with VDSM=2E=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A To configure the modul= e use the =3E =3E =3E following=3A=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A =27vdsm-tool configure= =5B--module =3E =3E =3E module-=20 =3E =3E =3E name=5D=27=2E=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A If all modules are not= configured =3E =3E =3E try to=20 =3E =3E =3E use=3A=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A =27vdsm-tool configure= --force=27=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A =28The force flag will= stop the =3E =3E =3E module=27s=20 =3E =3E =3E service and start it=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A afterwards automatical= ly to load the =3E =3E =3E new=20 =3E =3E =3E configuration=2E=29=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A abrt is already config= ured for vdsm=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A lvm is configured for= vdsm=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A libvirt is not configu= red for vdsm =3E =3E =3E yet=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A Current revision of mu= ltipath=2Econf=20 =3E =3E =3E detected=2C preserving=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A Modules libvirt are no= t configured=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet=20 =3E =3E =3E vdsmd=5Finit=5Fcommon=2Esh=5B10414=5D=3A vdsm=3A stopped during= execute=20 =3E =3E =3E check=5Fis=5Fconfigured task =28task returned with error code 1= =29=2E=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet system= d=5B1=5D=3A=20 =3E =3E =3E vdsmd=2Eservice=3A control process exited=2C code=3Dexited stat= us=3D1=20 =3E =3E =3E Feb 05 14=3A40=3A16 glusternode1=2Ebodden-kliniken=2Enet system= d=5B1=5D=3A =3E =3E =3E Failed to=20 =3E =3E =3E start Virtual Desktop Server Manager=2E=20 =3E =3E =3E -- Subject=3A Unit vdsmd=2Eservice has failed=20 =3E =3E =3E -- Defined-By=3A systemd=20 =3E =3E =3E -- Support=3A http=3A//lists=2Efreedesktop=2Eorg/mailman/listin= fo/systemd =3E =3E =3E -devel=20 =3E =3E =3E --=20 =3E =3E =3E -- Unit vdsmd=2Eservice has failed=2E=20 Frank Rothenstein=C2=A0 Systemadministrator Fon=3A +49 3821 700 125 Fax=3A=C2=A0+49 3821 700 190Internet=3A=C2=A0www=2Ebodden-kliniken=2Ede E-Mail=3A f=2Erothenstein=40bodden-kliniken=2Ede =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F BODDEN-KLINIKEN Ribnitz-Damgarten GmbH Sandhufe 2 18311 Ribnitz-Damgarten Telefon=3A 03821-700-0 Telefax=3A 03821-700-240 E-Mail=3A info=40bodden-kliniken=2Ede=20 Internet=3A http=3A//www=2Ebodden-kliniken=2Ede Sitz=3A Ribnitz-Damgarten=2C Amtsgericht=3A Stralsund=2C HRB 2919=2C Steuer= -Nr=2E=3A 079/133/40188 Aufsichtsratsvorsitzende=3A Carmen Schr=C3=B6ter=2C Gesch=C3=A4ftsf=C3=BChr= er=3A Dr=2E Falko Milski=2C MBA Der Inhalt dieser E-Mail ist ausschlie=C3=9Flich f=C3=BCr den bezeichneten= Adressaten bestimmt=2E Wenn Sie nicht der=20 vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten=2C be= achten Sie bitte=2C dass jede=20 Form der Ver=C3=B6ffentlichung=2C Vervielf=C3=A4ltigung oder Weitergabe des= Inhalts dieser E-Mail unzul=C3=A4ssig ist=2E=20 Wir bitten Sie=2C sofort den Absender zu informieren und die E-Mail zu l= =C3=B6schen=2E=20 =C2=A0 =C2=A0 =C2=A0 =C2=A9 BODDEN-KLINIKEN Ribnitz-Damgarten GmbH 2017 *** Virenfrei durch Kerio Mail Server und SOPHOS Antivirus *** ------------MIME--520934545-17562-delim Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =3Chtml=3E =3Cbody=3E Thanks Thomas,  it seems you were right. I followed the instructions to enable hugepages via kernel command line and after reboot vdsmd starts correctly. (I went back to 4.1.9 in between, added the kernel command line and<br= > upgraded to 4.2)  The docs/release notes should mention it - or did I miss it?  Am Dienstag, den 06.02.2018, 17:17 -0800 schrieb Thomas Davis: > sorry, make that: >  > hugeadm --pool-list >       Size = Minimum  Current  Maximum  Default >       2097152&nb= sp;    1024     1024   &n= bsp; 1024        * > 1073741824      =      4        &= nbsp;  4           4=       >  >  > On Tue, Feb 6, 2018 at 5:16 PM, Thomas Davis &= lt;<a href=3D"mailto:tadavis@lbl.gov">tadavis(a)lbl.gov</a>> wrote:</= font> > > I found that you now need hugepage1g supp= ort.  The error messages > > are wrong - it's not truly a libvirt prob= lem, it's hugepages1g are > > missing for libvirt. > >  > > add something like: > >  > > default_hugepagesz=3D1G hugepagesz=3D1G h= ugepages=3D4 hugepagesz=3D2M > > hugepages=3D1024 to the kernel command li= ne. > >  > > You can also do a 'yum install libhugetlb= fs-utils', then do: > >  > > hugeadm --list > > Mount Point     =      Options > > /dev/hugepages    &nb= sp;  rw,seclabel,relatime > > /dev/hugepages1G     = rw,seclabel,relatime,pagesize=3D1G > >  > > if you do not see the /dev/hugepages1G li= sted, then vdsmd/libvirt > > will not start. > >  > >  > >  > >  > >  > >  > > On Mon, Feb 5, 2018 at 5:49 AM, Frank Rot= henstein <f.rothenstein@bo > > dden-kliniken.de> wrote:<b= r> > > > Hi,  > > >  > > > I'm currently stuck - after upgradin= g 4.1 to 4.2 I cannot start > > > the  > > > host-processes.  > > > systemctl start vdsmd fails with fol= lowing lines in journalctl:  > > >  > > > <snip>  > > >  > > > Feb 05 14:40:15 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: vdsm: R= unning wait_for_network  > > > Feb 05 14:40:15 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: vdsm: R= unning run_init_hooks  > > > Feb 05 14:40:15 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: vdsm: R= unning check_is_configured  > > > Feb 05 14:40:15 glusternode1.bodden-= kliniken.net  > > > sasldblistusers2[10440]: DIGEST-MD5 = common mech free  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: Error: =  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: One of = the modules is not configured > > > to  > > > work with VDSM.  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: To conf= igure the module use the > > > following:  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: 'vdsm-t= ool configure [--module > > > module-  > > > name]'.  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: If all = modules are not configured > > > try to  > > > use:  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: 'vdsm-t= ool configure --force'  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: (The fo= rce flag will stop the > > > module's  > > > service and start it <br= > > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: afterwa= rds automatically to load the > > > new  > > > configuration.)  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: abrt is= already configured for vdsm  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: lvm is = configured for vdsm  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: libvirt= is not configured for vdsm > > > yet  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: Current= revision of multipath.conf  > > > detected, preserving <br= > > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: Modules= libvirt are not configured  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net  > > > vdsmd_init_common.sh[10414]: vdsm: s= topped during execute  > > > check_is_configured task (task retur= ned with error code 1).  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net systemd[1]:  > > > vdsmd.service: control process exite= d, code=3Dexited status=3D1  > > > Feb 05 14:40:16 glusternode1.bodden-= kliniken.net systemd[1]: > > > Failed to  > > > start Virtual Desktop Server Manager= .  > > > -- Subject: Unit vdsmd.service has f= ailed  > > > -- Defined-By: systemd <= br> > > > -- Support: <a href=3D"http://lists.= freedesktop.org/mailman/listinfo/systemd">http://lists.freedesktop.org/mail= man/listinfo/systemd</a> > > > -devel  > > > --  > > > -- Unit vdsmd.service has failed. &#= 13; = =3CBR /=3E =3CBR /=3E =3Cfont face=3D=22Arial=22 style=3D=22font-size=3A 12px=3B font-family=3A A= rial=3B=22=3E=3Cspan style=3D=22font-size=3A 12px=3B=22=3E=3C/span=3E=3C/fo= nt=3E=3Cdiv=3E=3Cfont face=3D=22arial=22 size=3D=222=22=3E=3Cfont=3E=3Cfont= =3E=3Cfont=3E=3Cbr=3EFrank Rothenstein=26nbsp=3B=3C/font=3E=3C/font=3E=3C/f= ont=3E=3Cfont=3E=3Cfont=3E=3Cbr=3E=3Cbr=3ESystemadministrator=3Cbr=3EFon=3A= +49 3821 700 125=3Cbr=3EFax=3A=26nbsp=3B=3C/font=3E+49 3821 700 190=3C/fon= t=3E=3C/font=3E=3C/div=3E=3Cdiv=3E=3Cfont=3E=3Cfont face=3D=22arial=22 size= =3D=222=22=3EInternet=3A=26nbsp=3Bwww=2Ebodden-kliniken=2Ede=3Cbr=3EE-Mail= =3A f=2Erothenstein=40bodden-kliniken=2Ede=3Cbr=3E=3C/font=3E=3Cbr=3E=3C/fo= nt=3E=3Cspan style=3D=22font-size=3A 12px=3B font-family=3A arial=3B=22=3E= =3Cimg src=3D=22cid=3A547f8827=2Ef9d4cce7=2Epng=2Ed413ca20=22=3E=3C/span=3E= =3Cbr=3E=3Cfont face=3D=22arial=22 style=3D=22font-size=3A 12px=3B font-fam= ily=3A Arial=3B=22=3E=3Cspan style=3D=22font-size=3A 12px=3B=22=3E=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=3Cbr=3EBODDEN-KLINIKEN= Ribnitz-Damgarten GmbH=3C/span=3E=3Cbr=3E=3Cspan style=3D=22font-size=3A 1= 2px=3B=22=3ESandhufe 2=3C/span=3E=3Cbr=3E=3Cspan style=3D=22font-size=3A 12= px=3B=22=3E18311 Ribnitz-Damgarten=3C/span=3E=3Cbr=3E=3Cbr=3E=3Cfont size= =3D=221=22=3ETelefon=3A 03821-700-0=3Cbr=3ETelefax=3A 03821-700-240=3C/font= =3E=3Cbr=3E=3Cbr=3E=3Cfont size=3D=221=22=3EE-Mail=3A info=40bodden-klinike= n=2Ede =3Cbr=3EInternet=3A http=3A//www=2Ebodden-kliniken=2Ede=3C/font=3E= =3Cbr=3E=3Cbr=3E=3Cspan style=3D=22font-size=3A 12px=3B=22=3ESitz=3A Ribnit= z-Damgarten=2C Amtsgericht=3A Stralsund=2C HRB 2919=2C Steuer-Nr=2E=3A 079/= 133/40188=3C/span=3E=3Cbr=3E=3Cspan style=3D=22font-size=3A 12px=3B=22=3EAu= fsichtsratsvorsitzende=3A Carmen Schr=C3=B6ter=2C Gesch=C3=A4ftsf=C3=BChrer= =3A Dr=2E Falko Milski=2C MBA=3C/span=3E=3Cbr=3E=3Cbr=3E=3Cfont size=3D=221= =22 style=3D=22font-size=3A 12px=3B=22=3EDer Inhalt dieser E-Mail ist aussc= hlie=C3=9Flich f=C3=BCr den bezeichneten Adressaten bestimmt=2E Wenn Sie ni= cht der =3Cbr=3Evorgesehene Adressat dieser E-Mail oder dessen Vertreter se= in sollten=2C beachten Sie bitte=2C dass jede =3Cbr=3EForm der Ver=C3=B6ffe= ntlichung=2C Vervielf=C3=A4ltigung oder Weitergabe des Inhalts dieser E-Mai= l unzul=C3=A4ssig ist=2E =3Cbr=3EWir bitten Sie=2C sofort den Absender zu i= nformieren und die E-Mail zu l=C3=B6schen=2E =3C/font=3E=3Cbr=3E=3Cspan sty= le=3D=22font-size=3A 12px=3B=22=3E=3Cbr=3E=26nbsp=3B =26nbsp=3B =26nbsp=3B= =C2=A9 BODDEN-KLINIKEN Ribnitz-Damgarten GmbH 2017=3C/span=3E=3Cbr=3E=3Csp= an style=3D=22font-size=3A 12px=3B=22=3E*** Virenfrei durch Kerio Mail Serv= er und SOPHOS Antivirus ***=3C/span=3E=3C/font=3E=3C/div=3E=3CBR /=3E =3C/body=3E =3C/html=3E ------------MIME--520934545-17562-delim-- ------------MIME--520934545-23878-delim Content-Type: image/png; name="547f8827.f9d4cce7.png" Content-Transfer-Encoding: base64 Content-Disposition: inline Content-ID: <547f8827.f9d4cce7.png.d413ca20> iVBORw0KGgoAAAANSUhEUgAAAMgAAABACAYAAABfuzgrAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAEYJSURBVHhe7b0HWJVXuja8KYotJqZOJnOmfFNy Zs5kMr2kTBJjjb0rtpiqibF3o6KCUgUEu2IXu4gVO4qKoiIqzYKoFBVsdNibfX/3vV52YjIzHvOf //uu+a6Lxyz2+6531Wc991PWu/aODbVUS7X0L6kWILVUS4+gWoDUUi09gmoBUku19AiqBUgt1dIj qBYgtVRLj6BagNRSLT2CagFSS7X0CKoFSC3V0iPo/wxAnPpTXXPhNFePQ98sZxp5bLJ6qiHnN+7+ W/rHkv+Tuq48/n1oHP+snKGHHnxd+l+Q2mN6ZJlv01eFH13rXz21etNf6993p39ex5X7/6VFF/3L uo/Dd1ENP1Xq6xrfpMcGSDmTb3Q8hm/IwNB1aRixKRvDN17B2LUXMHzpcYSdKMapYocph2oHUHmP 6QFKy50oYVYeU3qRA/MPXsFfB8/FH0euwn99thDvjl2KgA3HkFoE3GSZSiZ7NYfqqOIVsOd8FiZE H8eI9akYvfEyRq9OwZfr0jFsQzaCE8pw7LYd+Q4Hilm2lKmy3M66GkUV4rMrMW7dOQxdn4Ehm67C Z30SJq85hrHrUxB0KB/7OKhLdgfKWNrBLu1V1XBUcgSVRTh1KQfj1p/CmLWnMDjmMoatSoXPlkwM 4f2odakYsS4RBy7dYE1gx4nzGLMyERO3ZsN/TzruMs+oBfsDODmWCt6rD9H25HwMmbMdV+4+QGU1 +2LHziqn6b8MdlNWFH0oHSPWnMFo9jl2RQKuFGp2LETeqq39N6oxaAXnE30MN3MLUVBehQkbzmDo pkyMjk5CWNwVlErjMDmrq5kqmey4zaX5bOF+rt1FjFxzGvNjE9WdUU6xx9MwemUSxm2+jADWv8qy 4qOjPA8OctfBUg67VojrknqH89iDi/c0LuDagxIMX7wfYzZfxNA157FwzymTTyYg7nwuhkafwfiN GZiwOAGnLxeypWpUVpaj1FmN0/mVmLwpHYOWHMS5tGxTKzz2AiZwvYesyyavL5O/yZi4Kgmjl5HP G9NY9rjhVXUV570qAcM2puOL6BQk5mh8HHjJbRSVlRl5pESYzwKu9cToEwiPS1VN/kfJtBejmmPQ c/Hg2/TYABEbfvNJJGztFsDWMQq2ZmFo0jMKnn8djAZvj4CtVQjc2vjis3l7jZBz5EAxQUI6nF+O DjNi4PX3oajL9FzP2fjNxP34vc9hNOkehvqvDcDTrUajQ2g8LpXYcbOSQuM0q4M5W4/A9vZ42Lot YR/h8GrhC4+/jYXtnSCmGfBqOhI/6TgE0+PScdklXRQEOCsw9+Q92N7yha39YtjaLIbb34fD441h zJsA25tfwr3paLw0IBzDorYbEJcZlDA5i7E9JQe29/w532DWnw9bi3C82M4fjTtMQhPOs2G70Qja vNt0N335NrY5iSkY7t0WY9ouLQDJTtQ7y0EdgQdMoikbLsD25y+w71quERI4mDhcThlFvNA4NI3+ M2PYJ/tvMwfPe89G0hXCzs4nlXZc5PP/HLoGtj8Ow4eh29Ussu6X4sWPl3K8c2Fr6Ys/j9qCXHav tu12O6tKhTiRyiWxNZ8GW1vO6d0Z6O6zytSXcHy5NI7rOoP1I/g8DIF7rXlUVRWgyvFAUGFBowLh uzkdtr+MwpaUAnN/Ivcu3N/9kvVDYGsajL6hMSZf5LflJHkzle3OR923fRF9II251SihcN7iVbeg fbC9PgmvDo5UD4Z+/wnXrFkoeb+a6x+CFzqH4wftffH99lN5HcC+JllyRrK9Q/mQXLZbhF9+FIGK qnIuPydKZVJMxjpoJQSSaxV2/MdHi/GHYcusipwTqu5zyQV/iwffpscGyH3K+6ufkfmdo+Deazl+ zwU4ywUoKK3A1HmbKbwz4fXBWk5mMtaeL0JxjUDkck1/1i8MdTuF4MmOAeg0dR2O5ZdCeuISyyTd r0Avn6Vo0HoibK2D8dchC5FMkGhCopgjKVxICnmPVWjYKRQh2zKQVVqF2MtleH/OETzVYiS+12UK hckPb41bRSEjLqlNNd35yUXw6BIOW9eFsHVahKnbzuNURTV2XClG/4CN+I9eM2HrEoY6nXzRZtwi ZNyrpBVRr3asSb6Fup9s5HMKS5c5GLPpCshO5FdUIr+4DJdKy6mRLCs3JWoHGnTwR4MP15E/C/B8 v3k4mStR5yioKOxcIGvhnQjdmwvbX4fj0HXZVOZUsg0+rOKEi3mhhVLZT0N3cc4U4h5r8MMPFuL8 dS44QS/qvuA0hdwPzcctwQPVZ92sokr89AsKE+dat3Mwmk7eibtiInlsJwidpq4Dl/jh1YnKpVsU 6nSdDW/fNaZN0fTV++D+HoWvxyLU916EJ7vMxKmbpWYtymmlHVI8lbKP4DyyCYQvsTPttrk/d/se nqQAe3ovJw/mo3fIZpMvCt6eTP6HcS5r0ZjA23r8MnOrzFznJZUSHAH4Sc9gXLxTRCDaNWQ0m7gO np3CUa/HYvz0wyVIIA7zyO+s8kpco5LI4Brb5SnQMjbptxDuA7bA1mcrFdQC9KqZU7W8EAFaypqU V+nALwcvx1uTNph71YW9xFgQWeX/EUCE1j8MXWYEVQz425BFuFsD9+LKajKdaO9Jgeq7AX+fvInT t8xa/2nL4N6OC9JlMZ7ruwRnqE41EC6ZYbz0muxMg3YEQb9NBNoMvDdjmxFG0Zodh6gZ5sHWaxPq tZqGrSfEXFpQpkKm0WuOolFHCnpvanEu7qDIbQYkonlnaUHaz4KbN61Phwi6HWdMvbsSGH767aIW pEC5fxANjzbT0JoAc9EyAsTWezXcerNuxzD40AWwiCOmG1butJOxlhaYvnIv6rw3FXX7r2Cd9Sw/ B3/5YiGkW1WitMwSbEmyb+xV2N4Yg53ZN8kjPq0iE8kIeaVFXDCXK/Zp6G4KMeftvRHPDViM09ct jiRepGD+bRIFcQES82RVyD26DlklXPwRBKj3UtTrNgvNp+5BYQ1AHHJZCZBKClQGh+LWnlaiRxS8 es1Fv6CNpl0tpe+6Q6jTYRa8uE7u3edwncPxu09DjXts7AYFCaVyhO2YufsiFdckbEuzLEha4X08 0W46PLrTilFJDJi91eSL/DbTgvTkXHqsg1vLMGxMzDL5p/MK8CzHYGs1D4uOal0JRro94tbrY8jL Nv5o2HMu/qO7Hy4STZaYW2MtMopBq2nnPKhIKHc2b4GElrelP1Yl55qyBtAOliNIcgmqn3w4H699 WQMQSSIBVE0XVH3+jwAitL88kGbPOxpeXefinRFLcd88sYTNvTM1bV8CpPNCtKaAS89sy8hBwxZj 4daTWqXbUnwenWzAUFlRSr+bC24vRXGZNe0PllIrdiZTus5Hvc6hrGsxfuWeRGof5nvHwqPVFMQk SlDJREcpCqhtrvHuPZ9YAmADPPuuR6NW43Eo564Z05JLdwmaQHj2XkytOAez6a6JpU4utINaSNd/ CTjK9ufBs9tCeLYP/cpl2JR6Gx7vc9z9oij08zF29VmTbwSytARVZHgl+xf5rtoHrza0YrQ0bgM2 w12L1WYmRi1NMGDVWFx/QuLour0xGvE5+cowYDP+FYW40llGRWRpncERBEhPWZAVePKj1ThQUIVL ReV448Op8Gw7AyNiUq0mKyW+TlqQCvzwMyqwPstQt2sI3pywDbel1dicNKSDQmLnTSbZbWs7ne0K +CHoMSPatKOZTFq1Fx7tgwiOcLj3mQv3/isJmBB8EHHIrKcsEcrEHzsC9l62LMgli1+p1P71qSQ8 6F3Y2s1Br6AtJl8UvPMc15YWxHsd6nZcgKjTdwxf3h4dAq+2vugammgUJSqyONYSo4ybTd0Erx6R cOsYip/3nYVL1BxlBujVBJFllSXcDo7erUMovMSrbovg9vEezm0j6nePQPwlWTeOmXImRhRSGb08 aDHenLrVgMFwmm0pRpMUGn5+ix7fxWL67Qi6UBR2WYvfD1lihFMCL01ua0n/23sF3JqOwazY04YB 0+gO2VrS3+0fTSGcjaijF2viEw7NQcxSY1bLbJOWnLpuwOXVLRL16BaNXHnUDHhunMwzrZa3LMRM LD0sgDCocpYarSYhn72Tblg7ai7vDajTIxwDIy3tFXb2PoWWLlYP+qftQzAvNt5iQlUZqkuLDINC TuezX8YZPWQd16D3nHiVwJbTl2jeA2m5qPm6zMaQ1ZmGqazJ4Nqad0UNRyfM3YznegTjswOcAy2l rcsSeHgvxjOdfbEyQf4210iVSEE7rsD29xHYlWkF+I4SzkAs4OMK/mPrJv/jgA20fLIgy9Hw083Y yxX0nr0LjZt+jraTFxutXlxVAafDiBauEDz/S3GJN10nuVjT4nBXXXKMRpjILYoV0sk0t04BBNJy avsIdPNbY+alIfhuiEdjWqYJiTfILz+jrNyZnu8WgXkHtdqkMlmyagQdzKIFmYjdVxRFABcK7qNR +5lw701l1mEe+oR+DZCZ286Sx6Go128N3FpHYv0dYNaFPLqJn+OH3aebzQBjY6sL6OJSefLy7fHr 4SHF1X0JXvKei1TKuMRc5R4wThSXymgRVPb5D5ehuc9GdA5nDMX23b6g0mM88l+fhPOpiDEtrewt ume/+GQBXpuyxdRXkvLQ5kUNq/6BvhNAfj4wCm696DJRy/zxy804zrxTnNyHK2hC21N7tpqObmMj UVBm+ZG//XwBBYV1+qzCE138cfSSpTUVNBmTxkLS5mL4rrQc1Gc88HTvSPqeoejkv9uALDKemqqt XCzGOZ1nI/JYjpmMXJFyaRN+pjOmqdecWrE/LVjHCLw1JJS5wII0ulgdwugmRbFuOBYQIIbke9IC iSWHbxbi+e4+jKtYpst6/HFaonHvDqVk4vvdJ3HB6Wr0WYpPN+RAo5dzYOInJu0IiQJX78UTHX0R c/MeRu68RhcnDJ70423UbC92m4kTecWGHxUsH76b8/ndACRczzVzkIelkEmjUb+Gc5zg0IjttEIB FJB5aPzxRrTbWk2BXQTPd8cZhWTmX/Op8pcelOEnwxiD0AcXAN6YvIMWVg9r2mRpbQoYgHRk8E8X SwDpPHW54aGS38bDVE4R2HOnHGO2p6F+z3DGZxFoTI/hSbqqJ2+XWVqXFBZ/jUH6UOy6XBOD0MVq 3JEKpQctSIf5tCAuN6YGIB0C0bjXIri3CkGfbWXwHLyVQjwd27I0c/ZPoZfKcjgsBfHuxBi4M260 dVtH13w1DlMjyWmSvdI6XCx2GAGXemjUKRhdJ843vPj1p5SVtlyzgfvZfjh6UQGojHh1l3L360EL 8bbPFmMxDEDIGxdA/hl9J4C8MpjagYj26jmH5i8Mr47fiB+9HwqPluPh1X81PovJxy2zGJa/+F+f 0u3qRX+WluGpLr64eNeavJ5J85e6uE1hPXqF/qh3JBpQ+9XtGoFWNIMSmODdZG5XTroP3ZbOkQg/ lm/ql3GyVTXW5xY5U6fZeFPGrctCvD4o0OQvzaCL1YbWoQ/H3Xku5m87YvJlpqtLLc2rhf157ymo 581AniD88ZBdyCe3Dp67hO91Hse+GVv1W4mX6G69/fk8vDFkFt78JAx/GjQDK/cfNW34LI7FU4yh NmXfNbsybw2fw0B5Fjz60vJRsNpNWQeJkTgTFJsOzze/QEJ+gVEAEvbr7O8Kp3KZE7NCYFqLqdHw 7LUAdWlRPWmZbX3oX/eMRr0OQTh27ZYRVM3AmgUBQgvys5G08Iy3PORiESAuAAsg0rkCSAYlxaPD 1wDp7b/OlNHYfNfFw71NEHZlFZp5NJ9CxdZ+Gp7ietvahuL1sZuRwzFK2Hy2JNNbmEALYgEkhXxs RBDIJbR1nI+ewVZsI5q5nS4WrXA9Kqtnuy9Ew48ZJ/SmteM6T9tkbQdXlDvMelfXuK1NJ3C+nai0 em2hwlmKVz+NwtufhKLpRzPQYlAA/th1uCkneNVt74+Ooy1rsSk5D09155p3IVBpyb///nzMPZxl FHIu45bfDFyAv0+INoAwSlq8+f8DIBLoVz6n39qLDODCNeo7D93m7UGXaUvxk64UJAamdXssxBcL D+AmF0Zo/sPnc81ORJ0P1qF+p5lILqSGYL6dLpYGR55Y5CjDoay7aER/v05PCiqFudmX602ZRXEn yEgG+dodYQA5L8EKvqrtnFqlSlDAuGgK0G19t8KjyyK8M9ACyIq0O2ZnzNZrJce3AJFbLbdNpstR YS1EYmERftTXj8EghaDbSvxqyCbcIrd2XrhGwfCncAqcy/Dq59H4InALPp+1Al8ErEWvGQsZDyWZ Nqat3IWnO8zA3izLHy+kHni+My0a4zVb99Wo2ykIH4db27HBOy/B9tfB2J1XiJiLuWj8zmjUb+YL 2+sj4fZGP7w7aKIRwAGh1ICd51E45qEJAVqn+wq6O0vJzwi80i8QV2mlpW4qjRmmRqUF+ZEsCAXQ 1jngGwCRI2I5JdW4yMbrUKBs3aOMInLtYokvU9ccgHtLP+xLVyAOZBRV47f9p8LWYgI8B3AuXeah Z+hO8yyC7qTbayMZg1gu1tnbtCDU5LbeVAoCSMhDANmRSnAvQuOeUWjSgYDXGPtyTag867eYiqOZ VjRb5uSa1GwjvzV+HQFC15huc2Pyv0fwHgyaFYNPZizBiPC1GDAhxJSTBDSgPLYdt8jca5b+G46x 7iyON4rADsdz3UJw7A5dLM7yNwPn4a3RUaas2FPtZBRDeXSJ4rfpsQGijv9rEAfchwPvtgSvTt6C TOYJweuPpcKzJ58R8R6tp2Pa+gRTvvWXK+DVhbHJ+9RsXWdja+ZdY8q1o+J0qgSXpcakbuGi2Ly5 wBIqIr9HSJzJX7/nMO/pD9Ont3UOwir6x4YqCUEmIT8+32GZ9vfjCJAF6DI6whSJOn0Xbgy8TZud lmL2tpNGEFRJbrnGvjn/Hhp2mUlBDGfZ2Wjnu8sog3UXbtK9YtDXnfPqGImJGy0fXAsiZtKNNnGI 5jN51R40aDUVx64yt4p2gfFR1Em6IL3Iq/676W4twPPtGZhfysaiE4yL/jQMOwruYvCmBNje8qEr wPinM+fX+ksMW2X13z8yyQiIF63HswyWv9hZwnguBB6dF6A+BXtwVAJLkSotGyIL8lNjQRYTSLQg k74JECu2qcYVTtpLAOkWZdrxnvb1zl3AhiN0k2bhNK25ZefJh5OZaNKdAJbge1Prt52B7SnXsCj+ Buq+MRxxWZYFOU2ANOxIRdZLAFmInkFfb/P6bSdAOi1E497RaNAyCIM25OLJTxQzEqS0Dq3Hb8N9 LWT1fQqrNZ83J1IWtPFD9/zp/ktwnIyXdZXVFd+tUtYLYhtB13TCarO2GrUsUXMfuuRtw1B/YCyt eCjaTlqFS+THX4ZGocXYpSwhcHCpaD0EEEtd/iM9NkCE6z8PoU/YNYoCuwh/GLHMuA0ircMTPYjY PhTEzsvwyw/mmYn4bjiOpzqQud2Z320ZQg6nWcvkoCCREfZKikKFpT0WJ15l22Qa3Qhbp0iMj7bc oajt8WQktfj7KxngTcSygxkmH7QeEnIJ7JebGANp8eivetDvnLrSeju8Jvku6lHotVVq60iAbE82 +XpT7iyViDPAT2SQ3ov99taCRNL3jzX5Mak3ac0iOSbt9sz+ahfLrjfJjGHs1HYWtIHx89fjex2m IN4lWNUlxoJ2W8RxtQsz83midwQVTCjeX5WGhu/5YO/1O9h+9hpW7E7BvJ3nMftAJqbHHEFqid3w +pOwA/BkcGzrsRTf+3gd4rmCrw+jxu3AuKT/JoIpEAnZ1hzYITKLq/CrkeQd4xS3bnPwjs9O3JIA 8KnTrl1D8Vm7XQRIO7bbbSPqtZuPftO/FuQA8tz2jj8OZ8iCUKuKwaSxqxPYZrilkXssxq+HrsTg Lblwf3049pqdIrpYBffQoGOIxWuu40dB0SZfFBybQiEOtraA20RiC9n02fJ9cO8wk/nkb9v5iNyj 158cYc2mw19HUWkw9tFu25OMS09RVPSkmny30yW3m5emxZy5ky7/QjQjoDTaUv4RQK4Wl+Bn3my/ Pd32PlzbZn4YsOkyfj1mM9r6rlQX7IyrxLac8kYkxNZ0v0GPDRB1+qdBEfSLFTgtxhvDLRBU2auM MPxmGCffhW5Kj7V4+YsYpFNODl/JxpMtxlBA1sKt5zp8suKQ0doO7SJVVKKqooK+Z4kUOjUmgdCd WpQC+b0egYjLzDPCv2RfMgV3Eeq8v4rmeRLWJl03gCxixFvCCcmevDtxHRqQmU/3W4pnOvggqbDM 1F129IbZRjTWhWY/mMJoyMGRV1rA7DlzDxeIC/HpdlqLEJzPs0z8lqRLaNSDC05fuU77YGr2ZAMI u+IeO7nh1FYv4yDm+S3dgu+1m4i9V2/XgEZ/HSaYfHfKajR5n0LQZjbcGWzW78OYjG5VQpblmhiU W2rDrI+u9Pl54DYGzFQ6VCzPfrQaifediD6aiRc7TCA/6J70j8G7kzaiiMNxOhy4RID84hOuTU+u A93dtyduQhYZZTSjNiTKqH+pKbM5PVtTf9T5cBfd0tn4IPDrN97BGxMYkM/BgatmUxfV0qxcHN21 +3INvDpR2ZAf7nKzqf0bMMiOO18DEFqQunoX5s3gu8NiDAlZYfJF4VtT4GXiE64DLdeis0W4Rsb9 vOsEuo50tygb3+s/H5fvSDosXd58EpVAu1AqgzV4oc8cXOCCyrIS6WTSA1RXMYNeSKnDiXqMpVpO sPpTC7lG0J3Yf/4aGrXxRV1atLp6P+JNq0JP588T5ltt0WLBvG7gZY1X8W36TgD5/SACgPGBrctS /HnkMiMAElYh+9k+oWQcF6jvCvxwYITZcbjKQfYI4aBazIVbl1X4X32DccWMjMSK95lU9yrTE92p oXR0pZ0/Oo+bWyNiQOgWarVudHO6z+Nkx2Hp8RumjiWIwJx9DKbbT8GT1HD1247FyBWxZqwS8/Xn stneKAoTBZRB4sTdZwwDlQSP2NM38UKbafCiK2VrORFtgzcx16INKTlo2Jtz7bkcnm0DMTE20yiC h4ZvQKhxTJi7Fo1a+2J71h2TbwTS8cA8O8mO3Ol2utPnN9ZRAXer6TiSX6P9K7gyjgpq6yqU8NI1 rw+Dd1NZUIv23IDnP16Fg9d11IPBu6/ALiCsN3HXgn0XTPlz98pooZagbu8ouFFZvD2JATXzNV5X m3oPkkFhsCk+0nuDDn7o7LvIiKTS1I06ajIKcRlSO5xdNRWZjqnwLj63Ck0UY3SIQJ0B2u5nPETh 25VuxV3JBTUA6U1B7L4cn8ysOc5BCtyWTgVB2REo283FklPW3Mcu3AWv7rTSPTiXbovwcY311jzf nbgenl0j4d5tPp7vPRvnOQmtm/grOdZaaF76dGec23TUQl5xvixQoAFXWn0MmCOrOB11+2+wXkRz /O1DY613eHLzGfPoQARDOtPut+mxASKh/MMXlobXC8FXx27F/ptVSMwroItDf/ndCajbdwk83/XB 4j2ut87UWOTzzwZQKJoHo0EPPzSfthwHC0ug96bavdl9rRh/m7Sdi01t2T4Er30Wjhv3JN5W4LTy 6EUykBqzJ80kA9ZhO7Kw9epNrE6/hY8Wn4Ib+23QQ29jZ6P5hPVmG1BMk/Buv5AHL/r1tl56P7AR 76/PwN4bhdiYfQudlpzHC+0C0PDvY+gGTkLnkDXmsCTKLXGKPk8Xq0cEPLrOR4MuYfh45XnEc1wn bt7HcWr/5Bu3cKW4zPQ1Y9VuNGgTgm1Z98yYjVYqo4og88X0hYl3UJ+m3tZlGdz7cSytZ2J7TqGp a7SWsxqOalpiqjFTn9QnhJat5xYK3GZ8v98cnLxuWbzMu1UUHM63l+KNFXip8xRkUDhT6Fv8bthK uDOG8OocirdoQXYzJjp6/ZbZ9Yq/nIvrRcVIkQV5j1aViqx+b+02xRhBk1L5cmM8GtCKHsnW3hqh VU7r4KC7WG65k1GJt9BEMWWHUHh4L0GdVj6ITbH2LQWQhu3o0hAcitk+9IsywBLN3M41bM/8jwnA NsHYdsGyOvJAXv64Zi4918DzvWnYmXzNtNeU1tGLMY0n5/KDvhFYcf4ujuTd4dhuIuFqPg5n5RnA KB5pSJC1m2xZEDstirbTUZ5DT6XEeBjNJm9CHbajTQ8vBvSvj1xo+tbWhf7qUGcRE//7B3psgEh4 fvwRJ9mdk+lEJL4XgZfen4vnu5LZzSaRAfS1uy7AgMhE6yBuBYdfcccw6Si9idcmbINnx3HU1B/j Ge/paDpxDVoOi8APdY7qjRHU0v5o5hOLkwSdIWovUfjG/eyLbXenNm1B/5sC0LhLCDyb0Ty3nER/ mgFnUz94r72MNFbVlEukRkhbEnLQ4E26eG1pgVouRB2O+YUW7O/vtCrNpuPJVjPwg1YT6Gatx1W7 AjXWK7MEceWJS3DvQqZ2pEJoTleLAHiiRxieoAv3XPvxeOKdwfDZFG+C9UFzY+hKTsNexiDq3wTq FXlUeXcMUGVpBy6Ih1czX9TpSC38OoN0glRqwCyK/GrGNeUPbTf2CyI4mjFW6LKQFnI8MggoKQ3x c+CaY+QFXZY2gWjYchx6B25CIof+/U+5Nh2oqbvMh2enWXim+yw82W4qnu4ajEbvTcXIoGXmBWO9 Fn6sS3fpzcloO26Z0dgCgM/KA7C9Ngbx6QS3k+tXTufKTn5UlZuXohKq4Uv3oW6L8YwHp6JR0xHY eSbfjDkp9w6eaEleEzy25pPxecBi5lo0Y8MZ8p/5bSJQv/UkbDhUcyqBtDrlDtffB3X6cH3fGY+/ fhpqNn/+MIkK4q3p8PRmPi3l0+T9M5380KTzTDzZOQAN/tzH8E/Atr0zFm1GzVFzhior+MSej9KS +2Yb/WxZNZ5uPwnuBHSdZlPQYsQCSznRRdZbdK2R7v9HAKlyVMJv2S58vvwYPlh9BkOXH8aYeVsx dflejI6KQ8DuVGpncz7VoLhajLVzObjo6lxp2ZlsjFi1Hf0DNqDjmCXoMSkKn4bFYPTS3QSRdeRY AlDG+MQuH5N0JvUSBkZuxqhV7I8LOCpqN0Ys3Iapa/ZhRORGrDudhwtcYdcOh0NOs44P0C8/kXYd IyPWY8iygxiy6hhG8XP8oq0Ys2w3xq47irlxGWajQcIhWDhlJ0vJcjaRSCs1kPMbuuwIRrLu4CX7 MGbFQUxYcwBjF2+Hz7Kd2HUm3bgwsUfOYHTYOmQyUDVUTeGqInR0/oltqYyAND5yPUYt2oYRdMlS 7zywNKyTs5aloYtVVfPiU8cnVuw7hT5hmzGGgbPP4s24fUcxRKnhb3pROYYu3oUJq/ZjwoLNGBe6 GueKnJi24QTzOc6V8exnN8Ys3o3xDIaHR+3F5wt24WhKBvI5mCGzN+LLaPJj4Q4s3VazG0aKS0rD 2AXbGAsUm9jSMIJuSHWF4SyKyjUyYFjYCq7ZTn5GIyPvgcnLvluM4RFr8DnX54tFsVgbdwQ6GC2K S8rE4Pmc99I9GDt3PddUEGAMWlVl+D5i+X58wTGOWRyLsaGrcPpGPoK3nsbIqP0YEbUP41ce5Hx2 YsyS3ZxfHIYtPwjfZZY7ppGNWrIdC7YdMveOmvcoqCg0B0UFIFma2HPXMJ5jHrt4J+ZRsRky21g6 3FPJf5pbzYAfoscDiN52l0sPaqkfJmnqhxvlohNIGlQZyzrl8GingGOWoEgQLd3OT1YTusWgr/K4 KBIAAUWAcu2i/PfEyVELW3v9GqPYJrZYo1NbyhXk1L7y9KmkZxqDRK9adWhJpFIlHq5x/WtifwrY H+pLuywO1q4i4yvJN83F1a+LdG2Bg4CsJqgcRWb8rhMGas1Vvma5SWzdvCOw2vwmZzhSgfIbvfwz 0oysMprfV6STvgKqLpl0pSRumtIcm2nfzjXVJgVJ9TVWMw7+0aeeiBtyx02+iXx18U9IcyF/1Ibq fXPk6vlfVXyIDK+dZqxqQ7NTLbNuHKfyy5ij9XA9/6of3TC+sjwVbRRVsOQ/9vmYFoQVS2VuK4yp NYypZA80vcXlFYYh2lGSv+osKzaDoe5kLYqlAlYGos5KJ8pYRrnmOxBVHDYFgtaPfFQehdp+l3Ou wAPmSRdbZdmGnVPV2S29M6FWsJKumaeF0xdfzPagRqbdIH21R/84Zfah8zby7nWsRfeWYKo/lmRf YlGZhFrLLg7yQ+XUipZKrbpApiRRtHoiSXnQWmlXS2Oo5Dj1JSBBVGUttqsV3jkFBuoqHVDkvbNK SucerZ2u1YYleGrfIaHV3M08tZoaNzlrEvvUvqSZt84uaY4sQtKYVFrnHyUgausrdSHh1lhVXQVV R2pe1kLn7c068L+auhZf+JjJCJJDXgET56CTzKZPMVBAYGMSVvFFs9OdFQSzttpXXcmCdqHMM6Wa gZhr5nM+WiOj2FlKrfKJ4Yna1RzEU620QzzRmpMfeq6kOmZINUnlrMOf4oBxoK0xq2Ezb85JPGTL FlT18Jv02ADRYS/JlgTanLszZ+2rUMyOZAl0crRa5/PL2am4a/piQTHe7NQ46QZV06WROWMZaV4y rIrlBDqnhL6KLWn3h/fS6uXs0M5YRmvqYH0tgOyEXflMAthXSWNUnyyruatdwwytrm40aHFRXBLY zDFxjVnZald76hyXq44x1WVGWFRFd67FV3I1peL646zk8nEOYk0ReVXKzl1HPIx2Nq6UDhdyrFQq JSbWKUd5xX1WE/MocPyoZEdqv8JsP3JhGWiC7qasiwG3BmwUg9WeBETjMHOtKSPhFcvVjpZC/FWZ ryaiwSvpWoVc165nYiAb1DpIyMgVVmVlKRbzJSPqZZd1MOPRrPVcjbmS5IXjEQPNuyMLzBqvqcZk /moOylciA2paIol3KmkNSfPQONSyhmkpSc1f/RpVqFxzrTy1o7JSjUaJGiupa5YzY+ZTKVwCU3Ud evZP6LFjEK3NN0gaRe8zeKkdfTNodaijxYwD9MJGzDX1xGkyyjVJM+USas9KBlK8kx4137gTkypu sm2V/CapHVcyc+Q/CzBfC675FiIXQOurPOOiiRHqWdqGTLUEnrXIGCk/E7KYJahx+DQhNaoF0Ax0 X8N064Hy1bOsES8fIsMDkr5/4VAMZYSCiRpUZU1ta/VNK9JdOlNmstSWhmok3QzAaEkHweaghtA7 F9OfNHKNYKi42hD+v1p0JtfRiSrNTc+knR3WQUPNX8+tdvQWWcqGPTIJWIaHBpiMLXgv3SsoG1fF WBH2SECoLfFO/DEKjG06zbjIMwb4emR0EpNiUhfX9E/PLGJFbQYYKZCQu0iDZA2TVMvFET3S2Fme Aq/xahxac/PUPKtZa12bpHnqU8/VHnlUA2RjrXhl5Edd8vPb9NgAkbCvPXIZYQwE1+9JQmlpOc7d eIAlO0/hJvv7dc9JyGJw5yqrhdPOlzoXMa7EnF1ncOpKPq+duHTxOnMrDWu0X69FMFR1Dw/Ky7Hp 2EUsjD2KlTF7cY3Brxj87QlY07TIYrFF6vMeecL/DKWlp6BcOzIkF0MEQbWpeiI7rzJuWXvn34Bn DeNU76v+DaM1Q8uA36MArFy/H5FLYxETl4hSfZnnn5DGmsdHP3/HG0n5d4y/bnZZcu+Sp8m4Q7Wf V1SKTQcOI7/Y+l6EhF9JYLcEWAMS4Ci8FO4iftopsBJ6fe/cjI2jkttaQXOkuE6AclbeJQi0XSuh 0Aw1c4GGwbL5qw0CWUByRycdtMnA9gQcCboBg9ClGI0f+ur/gwr59vrqAWsRbNXGSnL1KaAKlmXl Zfl1Ulcy4UoCnTZHstlmBjVp8n07jt+vRjwZcoFNXGMXlottAaNS7WiO8lrkFtkVC+l0suCmEmqV 95y7lJ85xmQ8Eo2F1pdPWdhqzGgC1bRAbtaVFyrOJzV8Fn8VE1Y9PkBuUN26vz4EMxMy0WJkGL4I WozllGyfrRnIybsBW6tAhMSlI2j9QTPcCxkXsTG9BD7LdiE5M8vsMvVfloaE3Gr0D1yPv30UhLRz F+G35gCmbz6NdftO4Ub2VTPgi/zz04/m4vMFccw/ip+1Hox9abeQea8C01YegP+81cgtqkA6Ob02 MRv+i9dhRWIOdqXfgf/ynThXYNmEfSnXMGTaHLTtNxbXiitw7HIBRgVFYUlcilmAKzkPEHHgAuJO ncfIsEV4oacPzl2/aRZv6sJYrIreYXiaeKMQMek5mLEpARsOZNBIismCdAmyKYRtRi2BT+BiJJxL w4b9CeYruVEcz6Yj5zE2ci0SC4CI5TuQcOmueYH6bIsB+HLDAYxbu9fs0885lIxf9h6L8+ws9mI2 nm/9IZJvCT5aS1kSLigXzkommwJCF4jmSPeyMEp6820tM//ygfIMoEiuZ65/VrmHr113WgFyjxbH tWFh8CTTL80iQWJxtaZvr+iHJkoJjCqnbAwLaVPGBOBq4+u2JexX2fReuhszT+Sg1bKjeCP6In4x Lw0/CE3H90Ky8KOI2/hLVD5eX5iB/lvTsPBikflagerqjZLmU1lWQReVwCQgHWanVO9qtHl9l2Xs RulouJRyVqSA0O1XfTNgPVDiPGRQtLZVxnzyglTCa/ONHFp+B0FeQXfysQGi70D89P1IzEstwxAK z6DAKASeteO3n841LLC1DuGiJ6H9+IUYt+o4wpZH47lOPpi+5SheeLUFDlzOxi9HbUPo3kxM2HwW vxowCxdzCrHvhhMTNmXgJ2/2RsqFi2asKWzw1ZEb4bvDOp/T1m8nmo9dgRROKoGpl080Xus3Bluy yvFCex9MWXcE9ZpPxIcRseg4OhIthgRgPcHx627jcYpofaXneKw+dQV7rxYjmYr/ey2GYPbebPgt WYcmrUdi/Yk0hO86CVtbX2P1/vBBICIO3sDIgOUE2AosPpYJr7f6wSc2CT98exASzli/vCHZiTp+ BbY/fGGudSKAQ0IeV6Ru2wBMWbwRLYbPwcvvR8Bn7ma80sUXSVychu8MwsSY0+juvxatJizC2rR8 /LTXVEQlX4f/zpN4od1YpNxWixZAlFyCrh9gqDRBfo3Q1+Q/TK7yKusCia4fl9S6dIDlupHhxm2R a8XB814y5cKL5NCSNj63Uw3KTeYq3mW+Xtoe5xBnpdxBjzVZ+OHEbXAbsQY2n51wjzgBm/9h2EJP w23WOdimHUd931Nwn3ESdQOT8YRvCuqPS4T74J34VVgSZqbewVmLJRRyzoXWVjJvVH9N/KLxSm1J +Wl8wqdiC43TigeFDNmvIl5X4g7N4k1eScq+3HgISTduG/xU0gJVyyWlK/fYALnCcfz+i8UESRia j7FeOPkcLcTbY1YYi+HeORLn+Dl503G8MzYK4Zvi8Pqk1aqKZ/7YDfuyc/Cz4Vsx92guJm0/jT8P X2KepXCuL/cNwLxdqbheUIZPRvpi9oEreG1CDCZtsF4oeYcdxN8HhSGZ8xu4+AD6+ixFu8HTEU// 5M8D5xlmvNRlBnbkFGDu3hPo7rsUY9bG4S9DI8yEm01Zj0Grz2DP7TsYOD8Gv/54FvwP5MI3eiea TlphQLnwcAae8p6H0/fL8OPewfg46hgGzFiNwUExWHXhKn7yvp/1VnbwQsQcTjd1tBjTYs+hcSt/ c32e6Rftx+Jk7k3U778GGZS0ceuT8I5fnDlR8PNus5DMig3fHIoTtDKBu07gzc/DsfbCbfy8px+m 77iB4cvP4EedfQgQCh0Xz/wiyUOCLuHX+wMXfRsIrjyR8lRe5Pr870g1JVByIMU7OS0OClS18QE0 S+uQqMGmhqHC8sH0+rqK4+Ct6h7js1HxOfhF8BE8HZAIz9BE2GYcRt3ZF+AWlgHP2Zdhi7gKW1Aa QXKBKQXukSnMO406s9NQ3z8L9XxzUT/kHstkwSMwCa+E7MHSJEmeBUxtRFgWjr3SsminVK6g5EFj kFzqsfihH0uqgI4CCRKFHHK5cfX0uy0dY9Pww2lrEXcl19SpMEqBbhZj6scGSD4H9OJ7IxG4Lwe/ 6z0ZezNzMecUATJ0juGR7feDkFLqMD/7M2D+IcykT/63MVGGyY1f7YiD1/Lw8mcrEJNZgskbDuGt 4fNMu81HLkJbn/XmurCsChl5ReZbe3/9YjnmHrpqBvyjnsGYdfAKvIP3YEb8bYxbugPvDQ/GtjwH Xv10AZI40yfb+mDt2RsI23oYr306BYLWzz6JwJdHcvGLz+YgnurE9sf+OFh4H80nRyPg+C0ExOzH 7wfOMhpz3p4svNgt3HyN+OUBs7GT4FPfGv+s/el8NsoaF61o7NF0k6/44dDNItR5bRwulzkNgOr/ 3hsnr91A/d5L6E5WYPiKI3hzylak0/b/Z69wJHHlnnn9MxzJr8L0DUfQckgk3bdC/O2DcGRwnbVI P203CWk1Z9W1uC6BF0noBQjluT4FGF1/GwQuS+K6flyqpsDLL5cSoLdPWFRRmCo455qvBMv10nab DjBJOPkhHiqW3FFoR68NF/HkuB14YnoCnolIhy2A1mIxQTDnPGxhV1A/4AbqTLqCp/xvo77fdTSY fY3AyCBITsEtYD8aTN+PZycexXNjT6LhRFp2n5NwC08lWJJRb/hutJ1/BduuVxn+G1WhCLuUVxWU RMV/jH8Ui2i/1FnFldJ3f+j66XdUdDhIv/CltY2huW86Jwk23+OoM+MQNmXmfMtF+w4Ake5o/Zkv 9mWVYmrUBgz1nYN58Vfxoe9iPOAAW41fQm27DJ1HBCOd3IrYsAudJy8wdX/buh+OXs1D+4lLsD4h DZtPpqHZp9OxYuch/KnXSPT3W4Upc9aYt+Zazhu0lR1GLYD3qNnoN9QXo9ckGeGcsuEk3hqzhJp9 FdoNC0LU2WK0nLjSLMzPe/ni0KU8REZvxdDQFdiRXYif9ZmBplM2ISDhDnSOt9uUpeg3ZS7aTZiL 7gGrMX3ldnwwc5npc//pLPzO2x8HUq8jNO483hrmz3hnB1bHJWPr2Sy8N9rPgMd79AIkJFuxkl4v KaaYx/JtP52GEZGb0fKjybh07wF++0k4TuYUY8b6fejltxoX7znQdtg8pJVUoxfnNdg/Gl2GhCAp 7z62nEhHl6FhuMqVOXTpOt7pO9m8oRYJEC5L4AKLku7larkA4PoUuco8XE/X/4werucixwMG6Oa7 59YZLAmTdhmlmTVvCZ2znM/t+tEEy6XZdceBvlvz0WRaIur4XUC98KuoE5wKr8DTaBR+Fh6zzsAj +BxdqAt4Pvwmnpl5A89Ou4pnp6Th6UlJeM7nGF4OO4nPDt6GP9c1trAUB+6XYnN+GYJTS/DmspN4 OoQuGGMV24xcvEjwTdyTgYRi64f0zCxMzEQmaidVmwXOBxZABCDFbCwiO3iOGJpxtAA/HbMTTxOI 9YOvw2syw4L4M0bO1Z7RDlQUjw0QWQmRTJdLF+lanVJ5mes7fKAvvqgTIVvJWmarvphpGMyk8koq I7+/gHPSboceCsHmuZm1Vc/V68PLrL5V35pNDdXUOXHtATafLcCKE3fw5J964MPp1jfnZFa14ArE 1Zbq66sFInnPD9iUbqWdcrX1RlI/KitBEOm7WubFJlvTy0w9U8nce9YY9Vjtqj0905BUWmXUt+5V Rv2ojD5dz1z3qu96selKEnZXejjfZUF07QKFyFVHn/+KHgaRiC2S1eS+NiH0Y3M6vMnBaINMkynn QMvtVaiij651Xnu7HP1izuPFaXFo6H8KtkC6TsE3aBHy4BF2CfVmpeCpwBQ8Ny0DzwVnoWHoJdhC aEmCThJIB/DLsGMYuTublrPU8Fcr+TVftGWg/TWnkaPoAideWcP2Q1NplSjYU7fiJb8dmHL6Jk5w fBqP6ornFTWxh+RIQ9fnSTYyM/EOXglnzDP+INzo3j0ZcQMNfTPRaPAOBO5OMP2Yo3zfDSBkmhgo hjMZJvJTbSj40X66fj1Q91oa6/2DgigtIHPMCxm6AFwM80JNtVjGCBY/NQGrTbYg349oF1Zk5fif AYo2JyU0YoIROtbTpBVuKUfX2lIUWtWMyt5kV0fTCnDkXC7ulJFhzK+kNqmgA60+jR9hCnPV5aKo PybV1U/LmJ7UGZdLx1C0UOZe0WA1IeSk7TJv0Plhxl/FaTvodajcfS4S5yhnnW2JN2KO+EGRNG0p KYg0c9M2aU2e69r8ZCjb+O+SCzSmi4fqCDSu5Mr7Nn27vKxSGcfkWldUkFOl/NQvAeqSda4wbaQL 2GHHVTQKTaLQn4ZX8EnUCz0Lr9DzqBuaTouRCc+wy3APvQK34KvwCMk3n7ZZqbQk8XhpwSGMTr+N o1xoAcNIg05nqAP2Ix5V8MapU2xmt6qK2dUmzu248zDcQnbDfUkObLPpwk05giYzj+LtqGQEXyhC 7N0SHLpbhv2FxVid+wDjTuWiS3QyXgk6gXqTjjMGugLbfLp1cxj/sN5LfocxOPYqzj+wXjtI9iQP 0gaPDxAJjNSIKxmh1+JT6JnMAUUjYVwoU6amvNmTtpLTvMGm7jTHKHgv7EjYTB2lmjra7zZ5yhbr uIjVhAIDKz7lM73JLaEgW4IFxz1OiuMgE6sr+IyMdnCWmihHqGaM8DuqmE8BqJL/rP60lWleICrp wKDEUkSB0wE9nUg23NKBvLvsk/X4n4kEq7lwTh1pp85hJ/pWmsZVTQVgN/v1BQSHAj32YSeINAi5 AJq3mQUTeWP9Zi51pXnJZuVVk096taa5u4T3UcllQUQPWwQXcB6+1+e/ItWtIH+0g3Wf835QzHno TZ/64Ycs3DHqkjarU/Cs3154hFLAwq7D5p+OuuGZaMAY4amgU2gSmkzX6izqzrrM2IHPQ2lRFuXD No0Be/AxDDx2C3Gcrna57pAf2lZ16t0LeWZiGvahrQFFDebXiuXu6RukJdLvdrrbxei4jVbAJwlu c9l+eLYV8PsmoZFvPJ6fsgcvTd6DH3x5AF7jtjK+iEW9gIPwCjnDsWQaC+QewfqTt+KPy09h881i s0ur+Sms0nxRKaVZ8R0BYo5MaCFNK5yFFpYaypSRGPOvAEMBIUtZjEEd7yWkUqquN5fmDSgXX/Ji JFfHUbQzo1UwWl2Coja4YKqnWlWFfCxQqLFiFmPoyHE4NBb7bbZt7bfYFaBRELTQ5WXSB06U8VMn OyvoG+nHl40/bgbLumyr2lnKZZC/rRdvmgMfSgFwXGZIXDFZEKP5eS+jYH01VB4tgaV71eOdXjJJ +Kv11pm80rjM22mDUNVTWQHeUizmyIYR3Jr00L0AIl5ZifcPJVdZCfzDbtU3QMAPk19za6cCMXN/ iOxcBFfdr4h5BuO8lMXOYP0lWUVoufIUnpq6Gw2DU+AVkQWPmRcJglx4Bl3HkwSCx/SzeCIk3SSv 4DRjRYy2DjpHzb0Z3rsysYu6Qu6lIf3eUZkUSBlxUUJOyntgHpUGOWNcJCNbGp4RCY69SrWrzJb6 WwuS0WTKQTSeQ4CEXKRFyII7Xbo6BGndmWfQMDCD8c8NuGkTIESbACm8TkYDgvvXoXuwObfUnLLW jnoZ+SIZlQ40Jwyo2JxUeN8BIFpkjlIaT9pai8DJOHhdrjVgo/qFjUpqHv1TP1pAHZEgrIwLpgFo 0hJ6PTfHLmRBBBAtlOqKGWqf4NOvn5i6ymK/dj6UL6+zVxISWX0d1dD+vNrVqyqO0ICIYsQylnau qCxm8xVcD52tovsgIVHfpi+95NJJLL3mso5WaJxEiWlIhkGmvYI3ZizK1pAloKaGtlhZhkm+q/p1 MHjVmTUn29bbawNy88xqW3N8OOmBPg2Lmcy9xmAqiSdMrGh9f6EmsYBJqkctbyyYqvLTsIR/rLna uQaWu1tRwfUyYFDj+lRH7KNmIEY4dV1D2lCNPF+ApitO4qmQg/T7j8MjMBnus+k2zboEL98L+EHA ZTwx5TyempUDd9/LdKtuUhizjXvl4Z8Mj2nH8KMZB7A26/7XJyu0QCUU9CIqmVLmWLrIHGaVc6kC moMZSk2SMjWGu+Zar0IYu6NV0G40mrgbTeYSiLNo0QLP0ZJdQKPZlwhQgmYmg3q/bLp6sjB0p8IT 4HO6AOdrfgLXCKJ+/EOpgjIoL6O8iOtQwlT8+EG6RS7Gukj3rr/W58PXrs+Hk+jh6394KDLXVj9f P6Iw8K9yXUW/vv76mcj13Lp6OD38zEWqazHLlUyZmio1H1ZeDX19r79Wr67n1kisv9an6/q7kRRO FRfKLiuo4KmMUlGDfvO+TgLDWwMESosW1yCXmbI85vwTn6mMoqdiVmCJGr0g51RaWu6Ntm4ltoI/ cO3WHSxMzUbLXVl4ioJtm3qUAqbt2VzLVQq+gvrh1MzUxk1mnsT3/c8xCM+ki0UtHUpNvpjlFjIQ n7kfPw7ci3H7LpmdPvVq3rSzL6kxA1lJO8daTZdX/xsDuXPVxRyxhlKs+fA5BbasSBGmxWNzWFY3 io2oNLWD+c6ceDwxkZbELwuNp1zD01Oz0dCfYGHMYZt5EC/MOIzX5hxHwNHryGL9r9ZDmk1xI8ek I/GGzEP9sdJ3BEgt/d8iWctSWqIHVSXEBt1DptIyxmD8lIBXOktQUX2Pn0V44CglAOim0KXT3r9i H6N+BRiZbkmUAKaDhCYMtTY45HenUEDX3AaGxhej1dp8fH/qadQfdwyNfc7giennGU9cRd0AAoDx hC2Ubsqsc/CISIFn5CkGyifgMY9u1OwMuIekoS4/GwSewBNTd6LjqiQGyXKaBFjhVqOWGOpTEZYF cIV4cvGMK85yZQyMdbZMUJL7c54g2V9QhS3Z9xCVcg3bbjzAUYJHrh+5YgL8FE5t1OE8vBiwBx5h h+hqJeCp4L34U/hhfLY9GwvySnGEZWTB5CEYy2SO6WsUVvAv2AoS36ZagPybkn4o2sT9XDUtnJKO 0JcZjS/LoEOGJRQ5u1l0l+grua4lYDopLX/9AkESd6McG68Uwf94Dj7blo62a9LwU7pNDaeepKVI Z7BN9yi8jEHtLTQOykcDuieN/VPxxMzTaMIAt2FQEurNOg3P0PMURGro+bQYc7UzlYknwi7iybEH 8BZ9/NlnCoxm1zh01L26XOO03EtO4atk7pmvX9iUwRBoJfDaJYu+UYjB+86jU0wK3l6TiLZbUtBu VTwGbEzAwA174HPoNA7dLDPxg3G/WEcvh+dcvY7pV3Owl9f6zcaNl+/hCv038cJsxLFjxcbGDBvr YdlPJT7+B6oFyL8rSblRynOulWJvSj62X7+P6JulmHu5AuGpFZifWoVFpxwIP1IE37hrmLjjIoZu SkO/6GR0XZWMV4N24Vehe/GLyCP40ZyjeHbWETQMSEWdmWlwn3aG8cJp1AtIoXU4h7r02+sHnEdd XwbZQQy8Q26gztwCxhKZ8Aw5Cy9ahSdDT/JZEhoz+K4fkEVLkQfPoFy4RVyD59Rk/MwnEaO3F5iA XrtTt/lZQgGspGhWO6nvhRCZC6FeOwCKZymSMmwCkvanrvHR3PSb+Hj3aXTakozWWzPRbl8h2u29 jY+O3ERI2l2cZNVjBUWIzirCyNizmL37HG6UVeGeEEKSdyaQ7cm7h0E7UjFt1xkUFhfTQtF+2S3V YS/XWy7B0dpO10is0fwj1QLk35S0GaZ08a4d4eev42/Rx2Ebu4Jani6Ebwp96+uw+VCIJ1xFvekn 4DXtKOr6MF6YrJSIeiEZqMPkHkS3iEKv9xG2UMYHs5So+eUyzcqgkJ9FveBkAuAsGs48hhe1RetP KxGeyXiD7pTeFYSfhW32ebjTSngxzvDyv456fvl4ZnoqfjwpDn1WnseRAutlngRU73/sdPcczgcE xx0Knt5jUPoViWt3UDt81ADaG9SVrM3a1ByM2XwK3TZlodXG6+i++x5arrmED/fcwsLMezhP6VX7 2gSydjIA/YTg+7vi0SwmASNP3MT8pEKsPHYTfrEX0S8qBuMTEnHwahb5yF60fV51H1VV9zgmvT2z NljkWLksWi1A/h8ivbIqQSGX0ApQRblFdiw6lIOmYQloNHkbA+cj9Lep4WdRcAkEz8BUNIrMhkfA BdSN1BvtVHhGEBiBF+AVmWWOfTQJp6UgIOoolghLZXCdBs+wdLgxeYamo07oRbpTGXgmOIPAuUgQ sf4cBufzc2CLuAT3CFohBr1PBx5F302MM64VmhHK4GnX0NgDAsP6SjPvyyiEJdqwt8AjQCh+ECgS 9bWAS3fx4eaz6Lz2AjpvzkbHmEJ0XJ+DT7dfx6ILRcY9lLsoTW/ihgr2pE0Ju/WrBzr+MyXxJt7e lI6/7MxBq5gbmLA/FwevFSHHJfT6w6SdT+1YWrGQrIeJgix0mKTC36RagPybkpZRxwPNOyGzr2ky DV2mlK25kodum+ny+KyDze8MNfwVavssxhJJ8AhORz0KuldAGpqE0R2iW9WYVqQ+A+n64ZcMcNxo PTwiGT/QKrgzrw7r6t1GXdarF3wJHjNpfYIFDlqpyHxaIcYo0w+hwcR16LT+GN29EtT8NqS1eUbh 016gzqdJoOXmCDiSTfn3EuRkCmAcg4FZZ/MwcMc59IrNRAsC472dBXh3RzFaxlWh27o0TDiQjURO W21U0BLpf6pj/Y6Atql10kDtsmXTJ3DjngNbTudg2flbiL1bhdPkk2IOvebSqzsZHQFY4zAWjklQ VvxmnojHZmNDrX2TagHyb0paOlfwWLN7i3K6FiVcdWlhLbS0st5V+GcBzSlYL89KxoszT+IZv0Q8 FZSMejOTUT80k27RRTTQuwt/Wo3AdHiE0hKEE0wRegOt7VkCIYBWJDCD8QcBo+MbkQTR7DS40QXz nBSP/ww6hpG7MnBSb1JJTsFAFkKyxUFqJzolpxTBu09iwt5zGJ5wA902XkSXDblov+wyOi87iw7L k/He6vN4L+Yq2u28jRZMrXfdw3tbGWdsu4+usXk4+sA4ZJwf51p1Gw7zZSidnLtPXlSbZwKmrIfd cde8r7C48zUpR+WMq0cwCQyuJF66NgusfStx0cVpa24PUy1A/k1JSy4gSBtbiQJDbVpGlXi/6gGK KRj6FZYi+vUugThX7MSStHv4kH78K7MO41n/eNhm0A0LSSIICBb/U6jvl2RepHmG6Bh6qnnD7BZ6 me7VRXj4837yCQbtCWgYvAtNpsXgtciDCDxZgJN3SsxumZEhHdUpvw+nfr+McmXibWYV8/rC/XLs LijB0Pir6LDlDDrEXUaLDRfQY8NF9Iy5xrxrdIOuo/W2PHSIyUbPzZkYtDkNOwsqcJnCLE2v0xHW 3pLeZrMfWg9tDitHc1Usov+ToZ0uqJPxhFwlKQz9L9pkLWQJqsinO+TKfQMlvSblP7lQwoOSrg1I 9EZGDpfOUdQC5P8dkprTOwz5EwpsFWTS73aYs2ySJD1jOblfTmpYEwzrC7DmGxtmJymJF1Gp9zDl IIPWdcloHpOHX0Vdw4thF9DA9zjcxsfhhaBE/CT0BP6w4AzarMvAx3syMGrXKazLyId+NeArknRW VjO+thMIlWbn6T5FS5GAOf2rIyN6vc1xSzvLPVL8sL/wNlZnXMGME/nwPX0XY47ewYiEQkw5cwcL 0vOQxIbUlpHacrajb0GZebFZZlVxnmrPyK54oheK+v/C6LW7vCKWUbZkXsBw0qo59b0Qc4xIDwQd qg8dDdKvx+jLXWKQ+uBjluIcNA9rR+vbVAuQf1eSVGiBzdtmgUCJ1zVnVszP6fDT8hUoWObXQSpZ RZ6186v3gxIAyYLERC/K9EMJF8scSC0qR8rdYlwq1f9a2W6+gyNQSUOrvJpWXTbDcSiDV+qT/+mZ 2pbLY8FRkspkjvDoqaWLpZNdsigLJ9AU8oGSrmUh9cyQBFqmyPRVk2pIbZk/GoN4oQNTNahQ2PBV 6GB4wYq6V1IbGpN6UYxh6jLT1T7LmCJM4tk/o1qA1FItPYJqAVJLtfQIqgVILdXSI6gWILVUS4+g WoDUUi09gmoBUku19AiqBUgt1dIjqBYgtVRLj6BagNRSLT2CagFSS7X0CKoFSC3V0iOoFiC1VEv/ koD/DQ4+w6kmMAFSAAAAAElFTkSuQmCC ------------MIME--520934545-23878-delim--

1 0

Re: [ovirt-users] ovn problem - Failed to communicate with the external provider, see log for additional details.
by George Sitov 08 Feb '18

08 Feb '18

Thank you! It was certifucate problem. I returned it to pki and all work. 8 февр. 2018 г. 4:44 ПП пользователь "Marcin Mirecki" <mmirecki(a)redhat.com> написал: Hello George, Probably your engine and provider certs do not match. The engine pki should be in: /etc/pki/ovirt-engine/certs/ The provider keys are defined in the SSL section of the config file (/etc/ovirt-provider-ovn/conf.d/...): [SSL] https-enabled=true ssl-key-file=... ssl-cert-file=... ssl-cacert-file=... You can compare the keys/certs using openssl. Was the provider created using egine-setup? For testing purposes you can change the "https-enabled" to false and try connecting using http. Thanks, Marcin On Thu, Feb 8, 2018 at 12:58 PM, Ilya Fedotov <kosha79(a)gmail.com> wrote: > Hello, Georgy > > Maybe, the problem have the different domain name and name your node > name(local domain), and certificate note valid. > > > > with br, Ilya > > 2018-02-05 22:36 GMT+03:00 George Sitov <usual.man(a)gmail.com>: > >> Hello! >> >> I have a problem wiith configure external provider. >> >> Edit config file - ovirt-provider-ovn.conf, set ssl parameters. >> systemctl start ovirt-provider-ovn start without problem. >> In external proveder in web gui i set: >> Provider URL: https://ovirt.mydomain.com:9696 >> Username: admin@internal >> Authentication URL: https://ovirt.mydomain.com:35357/v2.0/ >> But after i press test button i see error - Failed to communicate with >> the external provider, see log for additional details. >> >> /var/log/ovirt-engine/engine.log: >> 2018-02-05 21:33:55,517+02 ERROR [org.ovirt.engine.core.bll.pro >> vider.network.openstack.BaseNetworkProviderProxy] (default task-29) >> [69fa312e-6e2e-4925-b081-385beba18a6a] Bad Gateway (OpenStack response >> error code: 502) >> 2018-02-05 21:33:55,517+02 ERROR [org.ovirt.engine.core.bll.pro >> vider.TestProviderConnectivityCommand] (default task-29) >> [69fa312e-6e2e-4925-b081-385beba18a6a] Command ' >> org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand' >> failed: EngineException: (Failed with error PROVIDER_FAILURE and code 5050) >> >> In /var/log/ovirt-provider-ovn.log: >> >> 2018-02-05 21:33:55,510 Starting new HTTPS connection (1): >> ovirt.astrecdata.com >> 2018-02-05 21:33:55,516 [SSL: CERTIFICATE_VERIFY_FAILED] certificate >> verify failed (_ssl.c:579) >> Traceback (most recent call last): >> File "/usr/share/ovirt-provider-ovn/handlers/base_handler.py", line >> 126, in _handle_request >> method, path_parts, content) >> File "/usr/share/ovirt-provider-ovn/handlers/selecting_handler.py", >> line 176, in handle_request >> return self.call_response_handler(handler, content, parameters) >> File "/usr/share/ovirt-provider-ovn/handlers/keystone.py", line 33, in >> call_response_handler >> return response_handler(content, parameters) >> File "/usr/share/ovirt-provider-ovn/handlers/keystone_responses.py", >> line 60, in post_tokens >> user_password=user_password) >> File "/usr/share/ovirt-provider-ovn/auth/plugin_facade.py", line 26, >> in create_token >> return auth.core.plugin.create_token(user_at_domain, user_password) >> File "/usr/share/ovirt-provider-ovn/auth/plugins/ovirt/plugin.py", >> line 48, in create_token >> timeout=self._timeout()) >> File "/usr/share/ovirt-provider-ovn/auth/plugins/ovirt/sso.py", line >> 62, in create_token >> username, password, engine_url, ca_file, timeout) >> File "/usr/share/ovirt-provider-ovn/auth/plugins/ovirt/sso.py", line >> 53, in wrapper >> response = func(*args, **kwargs) >> File "/usr/share/ovirt-provider-ovn/auth/plugins/ovirt/sso.py", line >> 46, in wrapper >> raise BadGateway(e) >> BadGateway: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed >> (_ssl.c:579) >> >> Whan i do wrong ? >> Please help. >> >> ---- >> With best regards Georgii. >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >

1 0

ovn problem - Failed to communicate with the external provider, see log for additional details.
by George Sitov 08 Feb '18

08 Feb '18

Hello! I have a problem wiith configure external provider. Edit config file - ovirt-provider-ovn.conf, set ssl parameters. systemctl start ovirt-provider-ovn start without problem. In external proveder in web gui i set: Provider URL: https://ovirt.mydomain.com:9696 Username: admin@internal Authentication URL: https://ovirt.mydomain.com:35357/v2.0/ But after i press test button i see error - Failed to communicate with the external provider, see log for additional details. /var/log/ovirt-engine/engine.log: 2018-02-05 21:33:55,517+02 ERROR [org.ovirt.engine.core.bll.provider.network.openstack.BaseNetworkProviderProxy] (default task-29) [69fa312e-6e2e-4925-b081-385beba18a6a] Bad Gateway (OpenStack response error code: 502) 2018-02-05 21:33:55,517+02 ERROR [org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand] (default task-29) [69fa312e-6e2e-4925-b081-385beba18a6a] Command 'org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand' failed: EngineException: (Failed with error PROVIDER_FAILURE and code 5050) In /var/log/ovirt-provider-ovn.log: 2018-02-05 21:33:55,510 Starting new HTTPS connection (1): ovirt.astrecdata.com 2018-02-05 21:33:55,516 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) Traceback (most recent call last): File "/usr/share/ovirt-provider-ovn/handlers/base_handler.py", line 126, in _handle_request method, path_parts, content) File "/usr/share/ovirt-provider-ovn/handlers/selecting_handler.py", line 176, in handle_request return self.call_response_handler(handler, content, parameters) File "/usr/share/ovirt-provider-ovn/handlers/keystone.py", line 33, in call_response_handler return response_handler(content, parameters) File "/usr/share/ovirt-provider-ovn/handlers/keystone_responses.py", line 60, in post_tokens user_password=user_password) File "/usr/share/ovirt-provider-ovn/auth/plugin_facade.py", line 26, in create_token return auth.core.plugin.create_token(user_at_domain, user_password) File "/usr/share/ovirt-provider-ovn/auth/plugins/ovirt/plugin.py", line 48, in create_token timeout=self._timeout()) File "/usr/share/ovirt-provider-ovn/auth/plugins/ovirt/sso.py", line 62, in create_token username, password, engine_url, ca_file, timeout) File "/usr/share/ovirt-provider-ovn/auth/plugins/ovirt/sso.py", line 53, in wrapper response = func(*args, **kwargs) File "/usr/share/ovirt-provider-ovn/auth/plugins/ovirt/sso.py", line 46, in wrapper raise BadGateway(e) BadGateway: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) Whan i do wrong ? Please help. ---- With best regards Georgii.

3 2

Engine AAA LDAP startTLS Protocol Issue
by Alan Griffiths 08 Feb '18

08 Feb '18

Hi, Trying to configure Engine to authenticate against OpenLDAP and I seem to be hitting a protocol bug. Attempts to test the login during the setup fail with 2018-02-07 12:27:37,872Z WARNING Exception: The connection reader was unable to successfully complete TLS negotiation: SSLException(message='Received fatal alert: protocol_version', trace='getSSLException(Alerts.java:208) / getSSLException(Alerts.java:154) / recvAlert(SSLSocketImpl.java:2033) / readRecord(SSLSocketImpl.java:1135) / performInitialHandshake(SSLSocketImpl.java:1385) / startHandshake(SSLSocketImpl.java:1413) / startHandshake(SSLSocketImpl.java:1397) / run(LDAPConnectionReader.java:301)', revision=0) Running a packet trace I see that it's trying to negotiate with TLS 1.0, but my LDAP server only support TLS 1.2. This looks like a regression as it works fine in 4.0. I see the issue in both 4.1 and 4.2 4.1.9.1 4.2.0.2 Should I submit a bug? Thanks, Alan

2 2

oVirt DR: ansible with 4.1, only a subset of storage domain replicated
by Luca 'remix_tj' Lorenzetto 08 Feb '18

08 Feb '18

Hello, i'm starting the implementation of our disaster recovery site with RHV 4.1.latest for our production environment. Our production setup is very easy, with self hosted engine on dc KVMPDCA, and virtual machines both in KVMPDCA and KVMPD dcs. All our setup has an FC storage backend, which is EMC VPLEX/VMAX in KVMPDCA and EMC VNX8000. Both storage arrays supports replication via their own replication protocols (SRDF, MirrorView), so we'd like to delegate to them the replication of data to the remote site, which is located on another remote datacenter. In KVMPD DC we have some storage domains that contains non critical VMs, which we don't want to replicate to remote site (in case of failure they have a low priority and will be restored from a backup). In our setup we won't replicate them, so will be not available for attachment on remote site. Can be this be an issue? Do we require to replicate everything? What about master domain? Do i require that the master storage domain stays on a replicated volume or can be any of the available ones? I've seen that since 4.1 there's an API for updating OVF_STORE disks. Do we require to invoke it with a frequency that is the compatible with the replication frequency on storage side. We set at the moment RPO to 1hr (even if planned RPO requires 2hrs). Does OVF_STORE gets updated with the required frequency? I've seen a recent presentation by Maor Lipchuk that is showing the automagic ansible role for disaster recovery: -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <lorenzetto.luca(a)gmail.com>

3 7

Spice Newb
by Marshall Mitchell 08 Feb '18

08 Feb '18

--_000_SN1PR20MB0670222DE294B753BA2AE843D6FC0SN1PR20MB0670namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm attempting to get my first install of oVirt going in full swing. I hav= e all the hosts installed and an engine running. All is smooth. I'm not try= ing to connect to the Spice console with my Remote Viewer and I have no clu= e how to figure out what port I should be connecting too. I've been all ove= r the web via google looking for a process to install / configure / verify = spice is operational, but I've not been lucky. How do I go about connecting= / finding the port numbers for my VM's? I did open the firewall range requ= ired. I appreciate the help. -Marshall --_000_SN1PR20MB0670222DE294B753BA2AE843D6FC0SN1PR20MB0670namp_ 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"> I’m attempting to get my first install of oVir= t going in full swing.  I have all the hosts installed and an engine r= unning. All is smooth. I’m not trying to connect to the Spice console= with my Remote Viewer and I have no clue how to figure out what port I should be connecting too. I’ve been all over the web= via google looking for a process to install / configure / verify spice is = operational, but I’ve not been lucky. How do I go about connecting / = finding the port numbers for my VM’s? I did open the firewall range required. I appreciate the help. <o:p></o:p> <o:p> </o:p> -Marshall<o:p></o:p> </div> </body> </html> --_000_SN1PR20MB0670222DE294B753BA2AE843D6FC0SN1PR20MB0670namp_--

2 1

Clear name_server table entries
by Carlos Rodrigues 08 Feb '18

08 Feb '18

Hi, I'm getting the following problem: https://bugzilla.redhat.com/show_bug.cgi?id=1530944#c3 and after fix DNS entries no /etc/resolv.conf on host, i have to many entries on name_server table: engine=# select count(*) from name_server; count ------- 31401 (1 row) I would like to know if may i delete this entries? Best regards, -- Carlos Rodrigues Engenheiro de Software Sénior Eurotux Informática, S.A. | www.eurotux.com (t) +351 253 680 300 (m) +351 911 926 110

2 2

Re: [ovirt-users] After realizing HA migration, the virtual machine can still get the virtual machine information by using the "vdsm-client host getVMList" instruction on the host before the migration.
by Petr Kotas 08 Feb '18

08 Feb '18

Hi Pym, the feature is know in testing. I am not sure when it will be released, but I hope for sooner date. Petr On Tue, Feb 6, 2018 at 12:36 PM, Pym <pym0914(a)163.com> wrote: > Thank you very much for your help, so is this patch released now? Where > can I get this patch? > > > > > > > At 2018-02-05 20:52:04, "Petr Kotas" <pkotas(a)redhat.com> wrote: > > Hi, > > I have experimented on the issue and figured out the reason for the > original issue. > > You are right, that the vm1 is not properly stopped. This is due to the > known issue in the graceful shutdown introduced in the ovirt 4.2. > The vm on the host in shutdown are killed, but are not marked as stopped. > This results in the behavior you have observed. > > Luckily, the patch is already done and present in the latest ovirt. > However, be ware that gracefully shutting down the host, will result in > graceful shutdown of > the VMs. This result in engine not migrating them, since they have been > terminated gracefully. > > Hope this helps. > > Best, > Petr > > > On Fri, Feb 2, 2018 at 6:00 PM, Simone Tiraboschi <stirabos(a)redhat.com> > wrote: > >> >> >> On Thu, Feb 1, 2018 at 1:06 PM, Pym <pym0914(a)163.com> wrote: >> >>> The environment on my side may be different from the link. My VM1 can be >>> used normally after it is started on host2, but there is still information >>> left on host1 that is not cleaned up. >>> >>> Only the interface and background can still get the information of vm1 >>> on host1, but the vm2 has been successfully started on host2, with the HA >>> function. >>> >>> I would like to ask a question, whether the UUID of the virtual machine >>> is stored in the database or where is it maintained? Is it not successfully >>> deleted after using the HA function? >>> >>> >> I just encounter a similar behavior: >> after a reboot of the host 'vdsm-client Host getVMFullList' is still >> reporting an old VM that is not visible with 'virsh -r list --all'. >> >> I filed a bug to track it: >> https://bugzilla.redhat.com/show_bug.cgi?id=1541479 >> >> >> >>> >>> >>> >>> >>> 2018-02-01 16:12:16，"Simone Tiraboschi" <stirabos(a)redhat.com> ： >>> >>> >>> >>> On Thu, Feb 1, 2018 at 2:21 AM, Pym <pym0914(a)163.com> wrote: >>> >>>> >>>> I checked the vm1, he is keep up state, and can be used, but on host1 >>>> has after shutdown is a suspended vm1, this cannot be used, this is the >>>> problem now. >>>> >>>> In host1, you can get the information of vm1 using the "vdsm-client >>>> Host getVMList", but you can't get the vm1 information using the "virsh >>>> list". >>>> >>>> >>> Maybe a side effect of https://bugzilla.redhat.com >>> /show_bug.cgi?id=1505399 >>> >>> Arik? >>> >>> >>> >>>> >>>> >>>> >>>> 2018-02-01 07:16:37，"Simone Tiraboschi" <stirabos(a)redhat.com> ： >>>> >>>> >>>> >>>> On Wed, Jan 31, 2018 at 12:46 PM, Pym <pym0914(a)163.com> wrote: >>>> >>>>> Hi: >>>>> >>>>> The current environment is as follows: >>>>> >>>>> Ovirt-engine version 4.2.0 is the source code compilation and >>>>> installation. Add two hosts, host1 and host2, respectively. At host1, a >>>>> virtual machine is created on vm1, and a vm2 is created on host2 and HA is >>>>> configured. >>>>> >>>>> Operation steps: >>>>> >>>>> Use the shutdown -r command on host1. Vm1 successfully migrated to >>>>> host2. >>>>> When host1 is restarted, the following situation occurs: >>>>> >>>>> The state of the vm2 will be shown in two images, switching from up >>>>> and pause. >>>>> >>>>> When I perform the "vdsm-client Host getVMList" in host1, I will get >>>>> the information of vm1. When I execute the "vdsm-client Host getVMList" in >>>>> host2, I will get the information of vm1 and vm2. >>>>> When I do "virsh list" in host1, there is no virtual machine >>>>> information. When I execute "virsh list" at host2, I will get information >>>>> of vm1 and vm2. >>>>> >>>>> How to solve this problem? >>>>> >>>>> Is it the case that vm1 did not remove the information on host1 during >>>>> the migration, or any other reason? >>>>> >>>> >>>> Did you also check if your vms always remained up? >>>> In 4.2 we have libvirt-guests service on the hosts which tries to >>>> properly shutdown the running VMs on host shutdown. >>>> >>>> >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > > > >

1 0

qcow2 images corruption
by Nicolas Ecarnot 07 Feb '18

07 Feb '18

Hello, TL; DR : qcow2 images keep getting corrupted. Any workaround? Long version: This discussion has already been launched by me on the oVirt and on qemu-block mailing list, under similar circumstances but I learned further things since months and here are some informations : - We are using 2 oVirt 3.6.7.5-1.el7.centos datacenters, using CentOS 7.{2,3} hosts - Hosts : - CentOS 7.2 1511 : - Kernel = 3.10.0 327 - KVM : 2.3.0-31 - libvirt : 1.2.17 - vdsm : 4.17.32-1 - CentOS 7.3 1611 : - Kernel 3.10.0 514 - KVM : 2.3.0-31 - libvirt 2.0.0-10 - vdsm : 4.17.32-1 - Our storage is 2 Equallogic SANs connected via iSCSI on a dedicated network - Depends on weeks, but all in all, there are around 32 hosts, 8 storage domains and for various reasons, very few VMs (less than 200). - One peculiar point is that most of our VMs are provided an additional dedicated network interface that is iSCSI-connected to some volumes of our SAN - these volumes not being part of the oVirt setup. That could lead to a lot of additional iSCSI traffic. From times to times, a random VM appears paused by oVirt. Digging into the oVirt engine logs, then into the host vdsm logs, it appears that the host considers the qcow2 image as corrupted. Along what I consider as a conservative behavior, vdsm stops any interaction with this image and marks it as paused. Any try to unpause it leads to the same conservative pause. After having found (https://access.redhat.com/solutions/1173623) the right logical volume hosting the qcow2 image, I can run qemu-img check on it. - On 80% of my VMs, I find no errors. - On 15% of them, I find Leaked cluster errors that I can correct using "qemu-img check -r all" - On 5% of them, I find Leaked clusters errors and further fatal errors, which can not be corrected with qemu-img. In rare cases, qemu-img can correct them, but destroys large parts of the image (becomes unusable), and on other cases it can not correct them at all. Months ago, I already sent a similar message but the error message was about No space left on device (https://www.mail-archive.com/qemu-block@gnu.org/msg00110.html) This time, I don't have this message about space, but only corruption. I kept reading and found a similar discussion in the Proxmox group : https://lists.ovirt.org/pipermail/users/2018-February/086750.html https://forum.proxmox.com/threads/qcow2-corruption-after-snapshot-or-heavy-… What I read similar to my case is : - usage of qcow2 - heavy disk I/O - using the virtio-blk driver In the proxmox thread, they tend to say that using virtio-scsi is the solution. Having asked this question to oVirt experts (https://lists.ovirt.org/pipermail/users/2018-February/086753.html) but it's not clear the driver is to blame. I agree with the answer Yaniv Kaul gave to me, saying I have to properly report the issue, so I'm longing to know which peculiar information I can give you now. As you can imagine, all this setup is in production, and for most of the VMs, I can not "play" with them. Moreover, we launched a campaign of nightly stopping every VM, qemu-img check them one by one, then boot. So it might take some time before I find another corrupted image. (which I'll preciously store for debug) Other informations : We very rarely do snapshots, but I'm close to imagine that automated migrations of VMs could trigger similar behaviors on qcow2 images. Last point about the versions we use : yes that's old, yes we're planning to upgrade, but we don't know when. Regards, -- Nicolas ECARNOT _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

Re: [ovirt-users] GUI trouble when adding FC datadomain
by Yaniv Kaul 07 Feb '18

07 Feb '18

On Feb 2, 2018 1:09 PM, "Roberto Nunin" <robnunin(a)gmail.com> wrote: Hi Yaniv Currently Engine is 4.2.0.2-1 on CentOS7.4 I've used using oVirt Node image 4.2-2017122007.iso LUN I need is certainly empty. (the second one in the list). Please file a bug with logs, so we can understand the issue better. Y. 2018-02-02 13:01 GMT+01:00 Yaniv Kaul <ykaul(a)redhat.com>: > Which version are you using? Are you sure the LUNs are empty? > Y. > > > On Feb 2, 2018 11:19 AM, "Roberto Nunin" <robnunin(a)gmail.com> wrote: > >> Hi all >> >> I'm trying to setup ad HE cluster, with FC domain. >> HE is also on FC. >> >> When I try to add the first domain in the datacenter, I've this form: >> >> [image: Immagine incorporata 1] >> >> So I'm not able to choose any of the three volumes currently masked >> towards the chosen host. >> I've tried all browser I've: Firefox 58, Chrome 63, IE 11, MS Edge, with >> no changes. >> >> Tried to click in the rows, scrolling etc. with no success. >> >> Someone has found the same issue ? >> Thanks in advance >> >> -- >> Roberto Nunin >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> -- Roberto Nunin

2 1