May 2016 - Users - oVirt List Archives

unreachable iso domain
by Fabrice Bacchella 21 May '16

21 May '16

--Apple-Mail=_00AFD7BD-2DBB-487F-96CD-3D6FDE49EB9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I try to attach an iso domain but it keep saying that it doesn't exist. = But if I look in = /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf, the directory = given in OVESETUP_CONFIG/isoDomainStorageDir exists and the logs says : =20 2016-05-19 19:23:23,900 ERROR = [org.ovirt.engine.core.vdsbroker.irsbroker.AttachStorageDomainVDSCommand] = (org.ovirt.thread.pool-8-thread-19) [78115edf] Command = 'AttachStorageDomainVDSCommand( = AttachStorageDomainVDSCommandParameters:{runAsync=3D'true', = storagePoolId=3D'17434f4e-8d1a-4a88-ae39-d2ddd46b3b9b', = ignoreFailoverLimit=3D'false', = storageDomainId=3D'2a9fe2d7-ea38-4ced-a274-32734b7b571b'})' execution = failed: IRSGenericException: IRSErrorException: Failed to = AttachStorageDomainVDS, error =3D Storage domain does not exist: = (u'2a9fe2d7-ea38-4ced-a274-32734b7b571b',), code =3D 358 Does code =3D 358 means something important ? --Apple-Mail=_00AFD7BD-2DBB-487F-96CD-3D6FDE49EB9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">I try to attach an iso domain but it keep saying that = it doesn't exist. But if I look in = /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf, the directory = given in OVESETUP_CONFIG/isoDomainStorageDir exists and the logs says = :</div><div style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D""> </div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">2016-05-19 19:23:23,900 ERROR = [org.ovirt.engine.core.vdsbroker.irsbroker.AttachStorageDomainVDSCommand] = (org.ovirt.thread.pool-8-thread-19) [78115edf] Command = 'AttachStorageDomainVDSCommand( = AttachStorageDomainVDSCommandParameters:{runAsync=3D'true', = storagePoolId=3D'17434f4e-8d1a-4a88-ae39-d2ddd46b3b9b', = ignoreFailoverLimit=3D'false', = storageDomainId=3D'2a9fe2d7-ea38-4ced-a274-32734b7b571b'})' execution = failed: IRSGenericException: IRSErrorException: Failed to = AttachStorageDomainVDS, error =3D Storage domain does not exist: = (u'2a9fe2d7-ea38-4ced-a274-32734b7b571b',), code =3D 358</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" class=3D""><br= class=3D""></div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">Does code =3D 358 means something = important ?</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D""> </div></body></html>= --Apple-Mail=_00AFD7BD-2DBB-487F-96CD-3D6FDE49EB9C--

3 2

gluster VM disk permissions
by Bill James 19 May '16

19 May '16

--------------060108010807030305050803 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit I tried posting this to ovirt-users list but got no response so I'll try here too. I just setup a new ovirt cluster with gluster & nfs data domains. VMs on the NFS domain startup with no issues. VMs on the gluster domains complain of "Permission denied" on startup. 2016-05-17 14:14:51,959 ERROR [org.ovirt.engine.core.dal.dbbroker.audi tloghandling.AuditLogDirector] (ForkJoinPool-1-worker-11) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM billj7-2.j2noc.com is down with error. Exit message: internal error: process exited while connecting to monitor: 2016-05-17T21:14:51.162932Z qemu-kvm: -drive file=/rhev/data-center/00000001-0001-0001-0001-0000000002c5/22df0943-c131-4ed8-ba9c-05923afcf8e3/images/2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25/a2b0a04d-041f-4342-9687-142cc641b35e,if=none,id=drive-virtio-disk0,format=raw,serial=2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25,cache=none,werror=stop,rerror=stop,aio=threads: Could not open '/rhev/data-center/00000001-0001-0001-0001-0000000002c5/22df0943-c131-4ed8-ba9c-05923afcf8e3/images/2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25/a2b0a04d-041f-4342-9687-142cc641b35e': Permission denied I did setup gluster permissions: gluster volume set gv1 storage.owner-uid 36 gluster volume set gv1 storage.owner-gid 36 files look fine: [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# ls -lah total 2.0G drwxr-xr-x 2 vdsm kvm 4.0K May 17 09:39 . drwxr-xr-x 11 vdsm kvm 4.0K May 17 10:40 .. -rw-rw---- 1 vdsm kvm 20G May 17 10:33 a2b0a04d-041f-4342-9687-142cc641b35e -rw-rw---- 1 vdsm kvm 1.0M May 17 09:38 a2b0a04d-041f-4342-9687-142cc641b35e.lease -rw-r--r-- 1 vdsm kvm 259 May 17 09:39 a2b0a04d-041f-4342-9687-142cc641b35e.meta I did check and vdsm user can read the file just fine. *If I change mod disk to 666 VM starts up fine.* ALso if I chgrp to qemu VM starts up fine. [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l 253f9615-f111-45ca-bdce-cbc9e70406df -rw-rw---- 1 vdsm qemu 21474836480 May 18 11:38 253f9615-f111-45ca-bdce-cbc9e70406df Seems similar to issue here but that suggests it was fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1052114 [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# grep 36 /etc/passwd /etc/group /etc/passwd:vdsm:x:36:36:Node Virtualization Manager:/:/bin/bash /etc/group:kvm:x:36:qemu,sanlock ovirt-engine-3.6.4.1-1.el7.centos.noarch glusterfs-3.7.11-1.el7.x86_64 qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64 qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64 libvirt-daemon-1.2.17-13.el7_2.4.x86_64 I also set libvirt qemu user to root, for import-to-ovirt.pl script. [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# grep ^user /etc/libvirt/qemu.conf user = "root" [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# gluster volume info gv1 Volume Name: gv1 Type: Replicate Volume ID: 062aa1a5-91e8-420d-800e-b8bc4aff20d8 Status: Started Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: ovirt1-gl.j2noc.com:/ovirt-store/brick1/gv1 Brick2: ovirt2-gl.j2noc.com:/ovirt-store/brick1/gv1 Brick3: ovirt3-gl.j2noc.com:/ovirt-store/brick1/gv1 Options Reconfigured: performance.readdir-ahead: on performance.quick-read: off performance.read-ahead: off performance.io-cache: off performance.stat-prefetch: off cluster.eager-lock: enable network.remote-dio: enable cluster.quorum-type: auto cluster.server-quorum-type: server features.shard: on features.shard-block-size: 64MB storage.owner-uid: 36 storage.owner-gid: 36 [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# gluster volume status gv1 Status of volume: gv1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovirt1-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 2046 Brick ovirt2-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 22532 Brick ovirt3-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 59683 NFS Server on localhost 2049 0 Y 2200 Self-heal Daemon on localhost N/A N/A Y 2232 NFS Server on ovirt3-gl.j2noc.com 2049 0 Y 65363 Self-heal Daemon on ovirt3-gl.j2noc.com N/A N/A Y 65371 NFS Server on ovirt2-gl.j2noc.com 2049 0 Y 17621 Self-heal Daemon on ovirt2-gl.j2noc.com N/A N/A Y 17629 Task Status of Volume gv1 ------------------------------------------------------------------------------ There are no active volume tasks any ideas on why ovirt thinks it needs group of qemu?? --------------060108010807030305050803 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 bgcolor="#FFFFFF" text="#000000"> I tried posting this to ovirt-users list but got no response so I'll try here too. <div class="moz-text-html" lang="x-unicode"> I just setup a new ovirt cluster with gluster & nfs data domains. VMs on the NFS domain startup with no issues. VMs on the gluster domains complain of "Permission denied" on startup. 2016-05-17 14:14:51,959 ERROR [org.ovirt.engine.core.dal.dbbroker.audi tloghandling.AuditLogDirector] (ForkJoinPool-1-worker-11) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM billj7-2.j2noc.com is down with error. Exit message: internal error: process exited while connecting to monitor: 2016-05-17T21:14:51.162932Z qemu-kvm: -drive file=/rhev/data-center/00000001-0001-0001-0001-0000000002c5/22df0943-c131-4ed8-ba9c-05923afcf8e3/images/2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25/a2b0a04d-041f-4342-9687-142cc641b35e,if=none,id=drive-virtio-disk0,format=raw,serial=2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25,cache=none,werror=stop,rerror=stop,aio=threads: Could not open '/rhev/data-center/00000001-0001-0001-0001-0000000002c5/22df0943-c131-4ed8-ba9c-05923afcf8e3/images/2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25/a2b0a04d-041f-4342-9687-142cc641b35e': Permission denied I did setup gluster permissions: gluster volume set gv1 storage.owner-uid 36 gluster volume set gv1 storage.owner-gid 36 files look fine: [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# ls -lah total 2.0G drwxr-xr-x 2 vdsm kvm 4.0K May 17 09:39 . drwxr-xr-x 11 vdsm kvm 4.0K May 17 10:40 .. -rw-rw---- 1 vdsm kvm 20G May 17 10:33 a2b0a04d-041f-4342-9687-142cc641b35e -rw-rw---- 1 vdsm kvm 1.0M May 17 09:38 a2b0a04d-041f-4342-9687-142cc641b35e.lease -rw-r--r-- 1 vdsm kvm 259 May 17 09:39 a2b0a04d-041f-4342-9687-142cc641b35e.meta I did check and vdsm user can read the file just fine. If I change mod disk to 666 VM starts up fine. ALso if I chgrp to qemu VM starts up fine. [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l 253f9615-f111-45ca-bdce-cbc9e70406df -rw-rw---- 1 vdsm qemu 21474836480 May 18 11:38 253f9615-f111-45ca-bdce-cbc9e70406df Seems similar to issue here but that suggests it was fixed: <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1052114">https://bugzilla.redhat.com/show_bug.cgi?id=1052114</a> [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# grep 36 /etc/passwd /etc/group /etc/passwd:vdsm:x:36:36:Node Virtualization Manager:/:/bin/bash /etc/group:kvm:x:36:qemu,sanlock ovirt-engine-3.6.4.1-1.el7.centos.noarch glusterfs-3.7.11-1.el7.x86_64 qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64 qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64 libvirt-daemon-1.2.17-13.el7_2.4.x86_64 I also set libvirt qemu user to root, for import-to-ovirt.pl script. [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# grep ^user /etc/libvirt/qemu.conf user = "root" [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# gluster volume info gv1 Volume Name: gv1 Type: Replicate Volume ID: 062aa1a5-91e8-420d-800e-b8bc4aff20d8 Status: Started Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: ovirt1-gl.j2noc.com:/ovirt-store/brick1/gv1 Brick2: ovirt2-gl.j2noc.com:/ovirt-store/brick1/gv1 Brick3: ovirt3-gl.j2noc.com:/ovirt-store/brick1/gv1 Options Reconfigured: performance.readdir-ahead: on performance.quick-read: off performance.read-ahead: off performance.io-cache: off performance.stat-prefetch: off cluster.eager-lock: enable network.remote-dio: enable cluster.quorum-type: auto cluster.server-quorum-type: server features.shard: on features.shard-block-size: 64MB storage.owner-uid: 36 storage.owner-gid: 36 [root@ovirt1 prod 2ddf0d0e-6a7e-4eb9-b1d5-6d7792da0d25]# gluster volume status gv1 Status of volume: gv1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovirt1-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 2046 Brick ovirt2-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 22532 Brick ovirt3-gl.j2noc.com:/ovirt-store/bric k1/gv1 49152 0 Y 59683 NFS Server on localhost 2049 0 Y 2200 Self-heal Daemon on localhost N/A N/A Y 2232 NFS Server on ovirt3-gl.j2noc.com 2049 0 Y 65363 Self-heal Daemon on ovirt3-gl.j2noc.com N/A N/A Y 65371 NFS Server on ovirt2-gl.j2noc.com 2049 0 Y 17621 Self-heal Daemon on ovirt2-gl.j2noc.com N/A N/A Y 17629 Task Status of Volume gv1 ------------------------------------------------------------------------------ There are no active volume tasks any ideas on why ovirt thinks it needs group of qemu?? </div> </body> </html> --------------060108010807030305050803--

1 0

100% memory usage on desktop environments
by Nicolás 19 May '16

19 May '16

Hi, Probably not an oVirt issue, but maybe someone can help. I've deployed a pretty basic VM (ubuntu 14.04 server, 4GB RAM, 4 CPUs, 15GB storage). Each time I install an additional desktop environment (Gnome, KDE, whatever...), CPU usage rises to 100% all time to the extreme that interacting with the machine becomes impossible (maybe a mouse movement is propagated 3 minutes later or so...). To debug this, I installed LXDE, which is a lightweight desktop environment based on Xorg. I could see there is an Xorg process consuming one of the CPUs and the machine stops responding as far as the desktop environment goes. I have not changed anything in the configuration file. I could also see this only happens when QXL is chosen as the display driver. When CIRRUS is chosen, everything works smoothly and CPU is ~100% idle. The downside is that we want to use SPICE and CIRRUS won't allow it. Why does this happen? Is this an OS-side driver issue? Any hint how can it be fixed? Thanks. Nicolás

4 3

oVirt All-in-One upgrade path and requested improvements
by Neal Gompa 19 May '16

19 May '16

Hello, I recently found out that oVirt "deprecated" the All-in-One configuration option in oVirt 3.6 and removed it in oVirt 4.0. This is a huge problem for me, as it means that my oVirt machines don't have an upgrade path. My experiments with the self-hosted engine have ended in failure for a couple of reasons: * The hosted engine deploy expects that a FQDN is already paired with an IP address. This is obviously false in most home environments, and even in the work environment where I use oVirt regularly. There's no workaround for this (except having a third machine to run the engine!), and this utterly breaks the only way to use oVirt in a DHCP-centric environment where I may not control the network addressing. * Other error states have caused the whole thing to break and just leave the system a broken mess. With no way to clean up, I'm left guessing how to undo everything, which is hellish and leads me to just wipe the whole system and start over. In addition, I was hoping that there would be improvements with the single system case, rather than destruction of this capability. Some of the improvements are things I think would be useful in even a multi-node setup, too. For example, I would like to see live migration capabilities with local storage across datacenters, as this capability in vMotion makes deployments a lot more flexible. Sometimes, local storage is really the only way to get the kind of speed needed for some workloads, and being able to offer some kind of HA for VMs on local storage would be excellent. In addition to being useful for all-in-one setups, it's quite useful for self-hosted engine configurations, too. It's also rather irritating that there's no way to migrate stuff from shared storage to local storage and back. On top of that, datacenters that have local storage can't have shared storage or vice versa. On top of that, it looks like the all-in-one code is being kept around anyway for the oVirt Live stuff, so why not just keep the capability and improve it? oVirt should become the best virtualization solution for everyone, not just people who have access to huge datacenters where all the conditions are perfect. -- 真実はいつも一つ！/ Always, there's only one truth!

3 3

[ANN] oVirt 4.0.0 First Beta Release is now available for testing
by Sandro Bonazzola 19 May '16

19 May '16

The oVirt Project is pleased to announce the availability of the First Beta Release of oVirt 4.0.0 for testing, as of May 19th, 2016 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 release is available now for: * Fedora 23 * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 * oVirt Next Generation Node 4.0 See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is already available [4]. * A new oVirt Next Generation Node is already available [4] * A new oVirt Engine Appliance is already available [4] * A new oVirt Guest Tools ISO is already available [4] * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.0 alpha release highlights: http://www.ovirt.org/release/4.0.0/ * 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.0.0/ [4] http://resources.ovirt.org/pub/ovirt-4.0_beta1/iso/ [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Re: [ovirt-users] oVirt hosted-engine setup stuck in final phase registering host to engine
by Ralf Schenk 19 May '16

19 May '16

This is a multi-part message in MIME format. --------------0CC9A5CD7BA82A048CB9D135 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, don't waste time on it. I reinstalled ovirt-hosted-engine-ha.noarch an then after some time engine magically started. I'm now adding hosts to the engine and will deploy two other instances of the engine on two other hosts to get it highly available. So far my gluster seems usable inside the engine and the hosts. If its interesing for you: I also setup up HA nfs-ganesha on the hosts to provide NFS Shares to multiple VM's (will be php-fpm Backends to Nginx) in an efficient way. I also tested and benchmarked (only sysbench) using one host as MDS for pNFS with gluster FSAL. So I'm able to mount my gluster via "mount ... type nfs4 -o minorversion=1" an am rewarded with pnfs=LAYOUT_NFSV4_1_FILES in "/proc/self/mountstats". I can see good network distribution and connections to multiple servers of the cluster when benchmarking an NFS mount. What I don't understand: Engine and also setup seem to have a problem with my type 6 bond. That type proved to be best in glusterfs and nfs performance and distribution over my 2 network-interfaces. Additionally I'm loosing my IPMI on shared LAN if I use a type 4 802.3ad Bond. Thats what i have: eth0___bond0_________br0 (192.168.252.x) for VMs/Hosts eth1__/ \__bond0.10_ovirtmgmt (172.16.252.x, VLAN 10) for Gluster, NFS, Migration, Management Is this ok ? Thanks a lot for your effort. I hope that I can give back something to the community by actively using the mailing-list. Bye Am 18.05.2016 um 16:36 schrieb Simone Tiraboschi: > Really really strange, > adding Martin here. > > > > On Wed, May 18, 2016 at 4:32 PM, Ralf Schenk <rs(a)databay.de > <mailto:rs@databay.de>> wrote: > > Hello, > > When I restart (systemctl restart ovirt-ha-broker ovirt-ha-agent) > broker seems to fail: (from journalctl -xe) > > -- Unit ovirt-ha-agent.service has begun starting up. > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: Traceback > (most recent call last): > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker", line 25, in > <module> > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: > broker.Broker().run() > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/broker.py", > line 56, in run > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: > self._initialize_logging(options.daemon) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/broker.py", > line 131, in _initialize_logging > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: > level=logging.DEBUG) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: hdlr = > FileHandler(filename, mode) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__ > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: > StreamHandler.__init__(self, self._open()) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File > "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: stream = > open(self.baseFilename, self.mode) > May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: IOError: > [Errno 6] No such device or address: '/dev/stdout' > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: Traceback (most > recent call last): > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent", line 25, in > <module> > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: agent.Agent().run() > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", > line 77, in run > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: > self._initialize_logging(options.daemon) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", > line 159, in _initialize_logging > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: > level=logging.DEBUG) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: hdlr = > FileHandler(filename, mode) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__ > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: > StreamHandler.__init__(self, self._open()) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File > "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: stream = > open(self.baseFilename, self.mode) > May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: IOError: [Errno > 6] No such device or address: '/dev/stdout' > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service: > main process exited, code=exited, status=1/FAILURE > May 18 16:26:19 microcloud21 systemd[1]: Unit > ovirt-ha-broker.service entered failed state. > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service > failed. > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-agent.service: > main process exited, code=exited, status=1/FAILURE > May 18 16:26:19 microcloud21 systemd[1]: Unit > ovirt-ha-agent.service entered failed state. > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-agent.service > failed. > May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service > holdoff time over, scheduling restart. > > Of course /dev/stdout exists: > > [root@microcloud21 ~]# ls -al /dev/stdout > lrwxrwxrwx 1 root root 15 May 18 12:29 /dev/stdout -> /proc/self/fd/1 > -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------0CC9A5CD7BA82A048CB9D135 Content-Type: multipart/related; boundary="------------69E1DCACD77B617618016FDF" --------------69E1DCACD77B617618016FDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hello, don't waste time on it. I reinstalled ovirt-hosted-engine-ha.noarch an then after some time engine magically started. I'm now adding hosts to the engine and will deploy two other instances of the engine on two other hosts to get it highly available. So far my gluster seems usable inside the engine and the hosts. If its interesing for you: I also setup up HA nfs-ganesha on the hosts to provide NFS Shares to multiple VM's (will be php-fpm Backends to Nginx) in an efficient way. I also tested and benchmarked (only sysbench) using one host as MDS for pNFS with gluster FSAL. So I'm able to mount my gluster via "mount ... type nfs4 -o minorversion=1" an am rewarded with pnfs=LAYOUT_NFSV4_1_FILES in "/proc/self/mountstats". I can see good network distribution and connections to multiple servers of the cluster when benchmarking an NFS mount. What I don't understand: Engine and also setup seem to have a problem with my type 6 bond. That type proved to be best in glusterfs and nfs performance and distribution over my 2 network-interfaces. Additionally I'm loosing my IPMI on shared LAN if I use a type 4 802.3ad Bond. Thats what i have: <tt>eth0___bond0_________br0 (192.168.252.x) for VMs/Hosts</tt><tt> </tt><tt>eth1__/ \__bond0.10_ovirtmgmt (172.16.252.x, VLAN 10) for Gluster, NFS, Migration, Management</tt> Is this ok ? Thanks a lot for your effort. I hope that I can give back something to the community by actively using the mailing-list. Bye <div class="moz-cite-prefix">Am 18.05.2016 um 16:36 schrieb Simone Tiraboschi: </div> <blockquote cite="mid:CAN8-ONr-48CYUXhTNs571DQu=_jCN3uOXUhDBKPSGyTdVzZw0w@mail.gmail.com" type="cite">Really really strange, <div>adding Martin here.</div> <div> </div> <div> </div> <div class="gmail_extra"> <div class="gmail_quote">On Wed, May 18, 2016 at 4:32 PM, Ralf Schenk <<a moz-do-not-send="true" href="mailto:rs@databay.de" target="_blank">rs(a)databay.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor="#FFFFFF" text="#000000"> Hello, When I restart (systemctl restart ovirt-ha-broker ovirt-ha-agent) broker seems to fail: (from journalctl -xe) <tt>-- Unit ovirt-ha-agent.service has begun starting up.</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: Traceback (most recent call last):</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker", line 25, in <module></tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: broker.Broker().run()</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/broker.py", line 56, in run</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: self._initialize_logging(options.daemon)</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/broker.py", line 131, in _initialize_logging</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: level=logging.DEBUG)</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: hdlr = FileHandler(filename, mode)</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: StreamHandler.__init__(self, self._open())</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: stream = open(self.baseFilename, self.mode)</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-broker[2429]: IOError: [Errno 6] No such device or address: '/dev/stdout'</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: Traceback (most recent call last):</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent", line 25, in <module></tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: agent.Agent().run()</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 77, in run</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: self._initialize_logging(options.daemon)</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 159, in _initialize_logging</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: level=logging.DEBUG)</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: hdlr = FileHandler(filename, mode)</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: StreamHandler.__init__(self, self._open())</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: stream = open(self.baseFilename, self.mode)</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 ovirt-ha-agent[2430]: IOError: [Errno 6] No such device or address: '/dev/stdout'</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service: main process exited, code=exited, status=1/FAILURE</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: Unit ovirt-ha-broker.service entered failed state.</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service failed.</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-agent.service: main process exited, code=exited, status=1/FAILURE</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: Unit ovirt-ha-agent.service entered failed state.</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-agent.service failed.</tt><tt> </tt><tt>May 18 16:26:19 microcloud21 systemd[1]: ovirt-ha-broker.service holdoff time over, scheduling restart.</tt><tt> </tt> Of course /dev/stdout exists: <tt>[root@microcloud21 ~]# ls -al /dev/stdout</tt><tt> </tt><tt>lrwxrwxrwx 1 root root 15 May 18 12:29 /dev/stdout -> /proc/self/fd/1</tt><tt> </tt> </div> </blockquote> </div> </div> </blockquote> <div class="moz-signature">-- <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part2.29C79524.2BD951A4@databay.de" height="30" border="0" width="151"></td> </tr> <tr> <td valign="top"> Ralf Schenk fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail <a href="mailto:rs@databay.de">rs(a)databay.de</a> </td> <td width="30"> </td> <td valign="top"> Databay AG Jens-Otto-Krag-Straße 11 D-52146 Würselen <a href="http://www.databay.de">www.databay.de</a> </td> </tr> <tr> <td colspan="3" valign="top"> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) </td> </tr> </tbody> </table> <hr color="#000000" noshade="noshade" size="1" width="100%"> </div> </body> </html> --------------69E1DCACD77B617618016FDF Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part2.29C79524.2BD951A4(a)databay.de> Content-Disposition: inline; filename="logo_databay_email.gif" R0lGODlhlwAeAMQAAObm5v9QVf/R0oKBgfDw8NfX105MTLi3t/r6+sfHx/+rrf98gC0sLP8L EhIQEKalpf/g4ZmYmHd2dmppaf8uNP/y8v8cIv+Ym//AwkE/P46NjRwbG11cXP8ABwUDA/// /yH5BAAAAAAALAAAAACXAB4AAAX/4CeOYnUJZKqubOu+cCzPNA0tVnfVfO//wGAKk+t0Ap+K QMFUYCDCqHRKJVUWDaPRUsFktZ1G4AKtms9o1gKsFVS+7I5ll67bpd647hPQawNld4KDMQJF bA07F35aFBiEkJEpfXEBjx8KjI0Vkp2DEIdaCySgFBShbEgrCQOtrq+uEQcALQewrQUjEbe8 rgkkD7y5KhMZB3drqSoVFQhdlHGXKQYe1dbX2BvHKwzY1RMiAN7j1xEjBeTmKeIeD3cYCxRf FigvChRxFJwkBBvk5A7cpZhAjgGCDwn+kfslgto4CSoSehh2BwEEBQvowDAUR0EKdArHZTg4 4oDCXBFC/3qj9SEluZEpHnjYQFIGgpo1KgSasYjNKBImrzF4NaFbNgIjCGRQeIyVKwneOLzS cLCAg38OWI4Y4GECgQcSOEwYcADnh6/FNjAwoGFYAQ0atI4AAFeEFwsLFLiJUQEfGH0kNGAD x8+oNQdIRQg+7NCaOhIgD8sVgYADNsPVGI5YWjRqzQTdHDDIYHRDLokaUhCglkFEJi0NKJhl 0RP2TsvXUg88KiLBVWsZrF6DmMKlNYMqglqTik1guN8OBgAgkGCpB+L9ugK4iSCBvwEfECw1 kILrBpa1jVCQIQBRvbP+rlEcQVAoSevWyv6uhpwE12uEkQAAZucpVw1xIsjkgf8B863mQVYt eQATCZYJZJ5WBfij2wfpHcEeHGG8Z+BMszVWDXkfKLhceJhBSAJ+1ThH32AfRFZNayNAtUFi wFSTSwEHJIYAAQU84IADwyjIEALU9MchG+vFgIF7W2GDI2T7HfjBgNcgKQKMHmwjgnCSpeCb ULRkdxhF1CDY40RjgmUAA/v1J5FAKW2gGSZscBFDMraNgJs1AYpAAGYP5jJoNQ4Y4Gh8jpFg HH9mgbmWo1l6oA4C3Ygp6UwEIFBfNRtkMIBlKMLnAXgAXLWhXXH85EIFqMhGGZgDEKArABGA ed0HI4bk5qgnprCYSt88B6dqS0FEEAMPJDCdCJYViur/B1BlwGMJqDTwnhqxJgUpo0ceOQ4D 0yEakpMm/jqCRMgWm2I1j824Y6vLvuuPjHnqOJkIgP6xzwp5sCFNsCFp88Gxh11lrjfDcNrc CEx64/CD3iAHlQcMUEQXvcA+qBkBB4Q2X1CusjBlJdKMYAKI6g28MbKN5hJsBAXknHOwutn4 oFYqkpqAzjnPbE0u1PxmwAQGXLWBbvhuIIEGEnRjlAHO4SvhbCNAkwoGzEBwgV9U0lfu2WiX OkDEGaCdKgl0nk2YkWdPOCDabvaGdkAftL1LlgwCM+7Tq11V71IO7LkM2XE0YAHMYMhqqK6U V165CpaHukLmiXFO8XSVzzakX+UH6TrmAajPNxfqByTQec41AeBPvSwIALkmAnuiexCsca3C BajgfsROuxcPA8kHQJX4DAIwjnsAvhsvfXHWKEwDAljg7sj03L9wwAQTxOWD2AE0YP75eCkw cPfs+xACADs= --------------69E1DCACD77B617618016FDF-- --------------0CC9A5CD7BA82A048CB9D135--

1 0

thin provisioned vm suspend
by Dobó László 19 May '16

19 May '16

Hi, I have an annoying problem with thin provisioned vms, which are on iscsi lvm. When I'm copying big files, qemu often suspending the vm while vdsm extending the volume. (VM test2 has been paused due to no Storage space error) Can i tune this free space detection behavior somehow? - should be good to start lvextend much more earlier. Regards, enax

1 0

Re: [ovirt-users] 100% memory usage on desktop environments
by Karli Sjöberg 18 May '16

18 May '16

--_000_5534f35e19cb423287f13a0e5159163cexch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTggbWFqIDIwMTYgNzo0OCBlbSBza3JldiBOaWNvbMOhcyA8bmljb2xhc0BkZXZlbHMu ZXM+Og0KPg0KPg0KPg0KPiBFbCAxOC8wNS8xNiBhIGxhcyAxODoxMSwgS2FybGkgU2rDtmJlcmcg ZXNjcmliacOzOg0KPj4NCj4+DQo+PiBEZW4gMTggbWFqIDIwMTYgNzowMyBlbSBza3JldiBOaWNv bMOhcyA8bmljb2xhc0BkZXZlbHMuZXM+Og0KPj4gPg0KPj4gPiBIaSBLYXJsaSwNCj4+ID4NCj4+ ID4gRWwgMTgvMDUvMTYgYSBsYXMgMTY6NTksIEthcmxpIFNqw7ZiZXJnIGVzY3JpYmnDszoNCj4+ ID4+DQo+PiA+Pg0KPj4gPj4gRGVuIDE4IG1haiAyMDE2IDU6NDkgZW0gc2tyZXYgTmljb2zDoXMg PG5pY29sYXNAZGV2ZWxzLmVzPjoNCj4+ID4+ID4NCj4+ID4+ID4gSGksDQo+PiA+PiA+DQo+PiA+ PiA+IFByb2JhYmx5IG5vdCBhbiBvVmlydCBpc3N1ZSwgYnV0IG1heWJlIHNvbWVvbmUgY2FuIGhl bHAuIEkndmUgZGVwbG95ZWQgYQ0KPj4gPj4gPiBwcmV0dHkgYmFzaWMgVk0gKHVidW50dSAxNC4w NCBzZXJ2ZXIsIDRHQiBSQU0sIDQgQ1BVcywgMTVHQiBzdG9yYWdlKS4NCj4+ID4+DQo+PiA+PiBK dXN0IHNwaXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBhbnkgb3Ro ZXIgT1MgZm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVzdCByZWxh dGVkIHJhdGhlciB0aGFuIG9WaXJ0Lg0KPj4gPj4NCj4+ID4+IC9LDQo+PiA+DQo+PiA+DQo+PiA+ IEkgdHJpZWQgYSB2YW5pbGxhIGNlbnRvcy03LjEgYXMgd2VsbCBhbmQgdGhlIHNhbWUgaGFwcGVu cy4gSSdtIG9mIHRoZSBzYW1lIG9waW5pb24gdGhhdCB0aGlzIGlzIG1vcmUgYSBndWVzdCByZWxh dGVkIGlzc3VlLCBpdCdzIGp1c3QgSSdkIGxpa2UgdG8gZmluZCBvdXQgd2h5IHRoaXMgb25seSBo YXBwZW5zIHdpdGggUVhMIGFuZCBub3Qgd2l0aCBDSVJSVVMuDQo+PiA+DQo+PiA+IFRoYW5rcy4N Cj4+DQo+PiBWZXJ5IGludGVyZXN0aW5nLiBBcmUgeW91ciBob3N0cyBhbGwgb2YgdGhlIHNhbWUg YXJjaGl0ZWN0dXJlKGZhbWlseSk/DQo+Pg0KPj4gL0sNCj4NCj4NCj4gQWN0dWFsbHkgd2UgaGF2 ZSBhIG5pY2UgbWl4dHVyZSBvZiBtYW51ZmFjdHVyZXJzLiBXZSBydW4gNyBob3N0cywgcGFpcmVk IDQtMi0xIGluIHJlbGF0aW9uIHRvIGFyY2hpdGVjdHVyZS4gQWxsIG9mIHRoZW0gaGF2ZSB0aGUg c2FtZSByZXNvdXJjZXMsIHRob3VnaCAoQ1BVcyArIFJBTSkuIEluIHRoaXMgY2FzZSwgSSBjYW4n dCB0ZXN0IHRoZSBWTSBvbiBkaWZmZXJlbnQgaG9zdHMgYmVjYXVzZSB3ZSd2ZSBzZXBhcmF0ZWQg b25lIG9mIHRoZW0gKG9uZSBvZiB0aGUgIjQiKSBvbiBhIHN0YW5kYWxvbmUgb1ZpcnQgZGF0YWNl bnRlciBhcyB3ZSdyZSBtYWtpbmcgdGVzdHMgb24gaXQsIGJ1dCBJIHJlbWVtYmVyIHRoaXMgaGFz IGFscmVhZHkgaGFwcGVuZWQgdG8gbWUgaW4gdGhlIHBhc3QgKEkgZGlkbid0IGhhdmUgdGhlIHRp bWUgdG8gZGVidWcgaXQgYXQgdGhhdCB0aW1lLCB0aG91Z2gpLg0KDQpBbmQgaXQgZG9lc24ndCBo YXBwZW4gd2l0aCBhIHNpbWlsYXIgVk0gaW4gdGhlIG90aGVyIGRhdGFjZW50ZXIsIG9uIHRoZSBz YW1lIGhhcmR3YXJlPw0KDQovSw0KDQo+DQo+PiA+DQo+PiA+PiA+IEVhY2ggdGltZSBJIGluc3Rh bGwgYW4gYWRkaXRpb25hbCBkZXNrdG9wIGVudmlyb25tZW50IChHbm9tZSwgS0RFLA0KPj4gPj4g PiB3aGF0ZXZlci4uLiksIENQVSB1c2FnZSByaXNlcyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBl eHRyZW1lIHRoYXQNCj4+ID4+ID4gaW50ZXJhY3Rpbmcgd2l0aCB0aGUgbWFjaGluZSBiZWNvbWVz IGltcG9zc2libGUgKG1heWJlIGEgbW91c2UgbW92ZW1lbnQNCj4+ID4+ID4gaXMgcHJvcGFnYXRl ZCAzIG1pbnV0ZXMgbGF0ZXIgb3Igc28uLi4pLg0KPj4gPj4gPg0KPj4gPj4gPiBUbyBkZWJ1ZyB0 aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0IGRlc2t0b3ANCj4+ ID4+ID4gZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBzZWUgdGhlcmUgaXMgYW4g WG9yZyBwcm9jZXNzDQo+PiA+PiA+IGNvbnN1bWluZyBvbmUgb2YgdGhlIENQVXMgYW5kIHRoZSBt YWNoaW5lIHN0b3BzIHJlc3BvbmRpbmcgYXMgZmFyIGFzIHRoZQ0KPj4gPj4gPiBkZXNrdG9wIGVu dmlyb25tZW50IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUNCj4+ID4+ ID4gY29uZmlndXJhdGlvbiBmaWxlLg0KPj4gPj4gPg0KPj4gPj4gPiBJIGNvdWxkIGFsc28gc2Vl IHRoaXMgb25seSBoYXBwZW5zIHdoZW4gUVhMIGlzIGNob3NlbiBhcyB0aGUgZGlzcGxheQ0KPj4g Pj4gPiBkcml2ZXIuIFdoZW4gQ0lSUlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9v dGhseSBhbmQgQ1BVIGlzDQo+PiA+PiA+IH4xMDAlIGlkbGUuIFRoZSBkb3duc2lkZSBpcyB0aGF0 IHdlIHdhbnQgdG8gdXNlIFNQSUNFIGFuZCBDSVJSVVMgd29uJ3QNCj4+ID4+ID4gYWxsb3cgaXQu DQo+PiA+PiA+DQo+PiA+PiA+IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJcyB0aGlzIGFuIE9TLXNp ZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuDQo+PiA+PiA+IGl0IGJlIGZpeGVkPw0K Pj4gPj4gPg0KPj4gPj4gPiBUaGFua3MuDQo+PiA+PiA+DQo+PiA+PiA+IE5pY29sw6FzDQo+PiA+ PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ PiA+IFVzZXJzIG1haWxpbmcgbGlzdA0KPj4gPj4gPiBVc2Vyc0BvdmlydC5vcmcNCj4+ID4+ID4g aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+PiA+DQo+PiA+ DQo+DQo+DQo= --_000_5534f35e19cb423287f13a0e5159163cexch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <FB71D56CC5642648899F4418B36F144C(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxOCBtYWogMjAxNiA3OjQ4IGVtIHNrcmV2IE5pY29sw6FzICZsdDtuaWNvbGFz QGRldmVscy5lcyZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBF bCAxOC8wNS8xNiBhIGxhcyAxODoxMSwgS2FybGkgU2rDtmJlcmcgZXNjcmliacOzOjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBEZW4gMTggbWFqIDIwMTYgNzowMyBl bSBza3JldiBOaWNvbMOhcyAmbHQ7bmljb2xhc0BkZXZlbHMuZXMmZ3Q7Ojxicj4NCiZndDsmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEhpIEthcmxpLDxicj4NCiZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IEVsIDE4LzA1LzE2IGEgbGFzIDE2OjU5LCBLYXJsaSBTasO2YmVyZyBl c2NyaWJpw7M6PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IERlbiAxOCBtYWogMjAxNiA1OjQ5IGVtIHNrcmV2IE5pY29s w6FzICZsdDtuaWNvbGFzQGRldmVscy5lcyZndDs6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgSGksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgUHJvYmFibHkgbm90IGFuIG9WaXJ0IGlz c3VlLCBidXQgbWF5YmUgc29tZW9uZSBjYW4gaGVscC4gSSd2ZSBkZXBsb3llZCBhIDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsgcHJldHR5IGJhc2ljIFZNICh1YnVudHUgMTQuMDQgc2VydmVy LCA0R0IgUkFNLCA0IENQVXMsIDE1R0Igc3RvcmFnZSkuPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdXN0IHNwaXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/ IFRyaWVkIDE2LjA0LCBvciBhbnkgb3RoZXIgT1MgZm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBp dCBzb3VuZHMgbW9yZSBndWVzdCByZWxhdGVkIHJhdGhlciB0aGFuIG9WaXJ0Ljxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgL0s8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgSSB0cmllZCBhIHZhbmlsbGEg Y2VudG9zLTcuMSBhcyB3ZWxsIGFuZCB0aGUgc2FtZSBoYXBwZW5zLiBJJ20gb2YgdGhlIHNhbWUg b3BpbmlvbiB0aGF0IHRoaXMgaXMgbW9yZSBhIGd1ZXN0IHJlbGF0ZWQgaXNzdWUsIGl0J3MganVz dCBJJ2QgbGlrZSB0byBmaW5kIG91dCB3aHkgdGhpcyBvbmx5IGhhcHBlbnMgd2l0aCBRWEwgYW5k IG5vdCB3aXRoIENJUlJVUy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBU aGFua3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBWZXJ5IGludGVyZXN0aW5nLiBBcmUg eW91ciBob3N0cyBhbGwgb2YgdGhlIHNhbWUgYXJjaGl0ZWN0dXJlKGZhbWlseSk/PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAvSzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBY3R1 YWxseSB3ZSBoYXZlIGEgbmljZSBtaXh0dXJlIG9mIG1hbnVmYWN0dXJlcnMuIFdlIHJ1biA3IGhv c3RzLCBwYWlyZWQgNC0yLTEgaW4gcmVsYXRpb24gdG8gYXJjaGl0ZWN0dXJlLiBBbGwgb2YgdGhl bSBoYXZlIHRoZSBzYW1lIHJlc291cmNlcywgdGhvdWdoIChDUFVzICYjNDM7IFJBTSkuIEluIHRo aXMgY2FzZSwgSSBjYW4ndCB0ZXN0IHRoZSBWTSBvbiBkaWZmZXJlbnQgaG9zdHMgYmVjYXVzZSB3 ZSd2ZSBzZXBhcmF0ZWQgb25lIG9mIHRoZW0NCiAob25lIG9mIHRoZSAmcXVvdDs0JnF1b3Q7KSBv biBhIHN0YW5kYWxvbmUgb1ZpcnQgZGF0YWNlbnRlciBhcyB3ZSdyZSBtYWtpbmcgdGVzdHMgb24g aXQsIGJ1dCBJIHJlbWVtYmVyIHRoaXMgaGFzIGFscmVhZHkgaGFwcGVuZWQgdG8gbWUgaW4gdGhl IHBhc3QgKEkgZGlkbid0IGhhdmUgdGhlIHRpbWUgdG8gZGVidWcgaXQgYXQgdGhhdCB0aW1lLCB0 aG91Z2gpLjwvcD4NCjxwIGRpcj0ibHRyIj5BbmQgaXQgZG9lc24ndCBoYXBwZW4gd2l0aCBhIHNp bWlsYXIgVk0gaW4gdGhlIG90aGVyIGRhdGFjZW50ZXIsIG9uIHRoZSBzYW1lIGhhcmR3YXJlPzwv cD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgRWFjaCB0aW1lIEkgaW5zdGFsbCBhbiBh ZGRpdGlvbmFsIGRlc2t0b3AgZW52aXJvbm1lbnQgKEdub21lLCBLREUsIDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsgd2hhdGV2ZXIuLi4pLCBDUFUgdXNhZ2UgcmlzZXMgdG8gMTAwJSBhbGwg dGltZSB0byB0aGUgZXh0cmVtZSB0aGF0IDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgaW50 ZXJhY3Rpbmcgd2l0aCB0aGUgbWFjaGluZSBiZWNvbWVzIGltcG9zc2libGUgKG1heWJlIGEgbW91 c2UgbW92ZW1lbnQgPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyBpcyBwcm9wYWdhdGVkIDMg bWludXRlcyBsYXRlciBvciBzby4uLikuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgVG8gZGVidWcgdGhpcywgSSBpbnN0YWxsZWQgTFhERSwg d2hpY2ggaXMgYSBsaWdodHdlaWdodCBkZXNrdG9wIDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsgZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBzZWUgdGhlcmUgaXMgYW4gWG9y ZyBwcm9jZXNzIDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgY29uc3VtaW5nIG9uZSBvZiB0 aGUgQ1BVcyBhbmQgdGhlIG1hY2hpbmUgc3RvcHMgcmVzcG9uZGluZyBhcyBmYXIgYXMgdGhlIDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgZGVza3RvcCBlbnZpcm9ubWVudCBnb2VzLiBJIGhh dmUgbm90IGNoYW5nZWQgYW55dGhpbmcgaW4gdGhlIDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsgY29uZmlndXJhdGlvbiBmaWxlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEkgY291bGQgYWxzbyBzZWUgdGhpcyBvbmx5IGhhcHBlbnMg d2hlbiBRWEwgaXMgY2hvc2VuIGFzIHRoZSBkaXNwbGF5IDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsgZHJpdmVyLiBXaGVuIENJUlJVUyBpcyBjaG9zZW4sIGV2ZXJ5dGhpbmcgd29ya3Mgc21v b3RobHkgYW5kIENQVSBpcyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IH4xMDAlIGlkbGUu IFRoZSBkb3duc2lkZSBpcyB0aGF0IHdlIHdhbnQgdG8gdXNlIFNQSUNFIGFuZCBDSVJSVVMgd29u J3QgPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyBhbGxvdyBpdC48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyBXaHkgZG9lcyB0aGlzIGhh cHBlbj8gSXMgdGhpcyBhbiBPUy1zaWRlIGRyaXZlciBpc3N1ZT8gQW55IGhpbnQgaG93IGNhbiA8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGl0IGJlIGZpeGVkPzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFRoYW5rcy48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyBOaWNvbMOhczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFVzZXJzIG1haWxp bmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgVXNlcnNAb3ZpcnQub3JnPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlz dGluZm8vdXNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5534f35e19cb423287f13a0e5159163cexch24sluse_--

2 1

Linux guests vs. Spice/QXL?
by Uwe Laverenz 18 May '16

18 May '16

Hi all, I'm running some tests on OVirt (3.6.5.3) on CentOS 7 and almost everything works quite well so far. CentOS 6.x, Windows 7 and 2008R2 work fine with Spice/QXL, so my setup seems to be ok. Other Linux systems don't work: Debian 8, Fedora 23/24, CentOS 7.x, Kubuntu 16.04... CentOS 7.x even kills his X server every time the user logs out. X-) They all have in common that they show a fixed display resolution of 1024x768 pixels. This can not be changed manually and of course automatic display resizing doesn't work either. All machines have spice-vdagent and ovirt-guest-agent installed and running. Is this a local problem or is this known/expected behaviour? Is there anything I can do to improve this? thank you, Uwe

2 2

Re: [ovirt-users] 100% memory usage on desktop environments
by Karli Sjöberg 18 May '16

18 May '16

--_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTggbWFqIDIwMTYgNzowMyBlbSBza3JldiBOaWNvbMOhcyA8bmljb2xhc0BkZXZlbHMu ZXM+Og0KPg0KPiBIaSBLYXJsaSwNCj4NCj4gRWwgMTgvMDUvMTYgYSBsYXMgMTY6NTksIEthcmxp IFNqw7ZiZXJnIGVzY3JpYmnDszoNCj4+DQo+Pg0KPj4gRGVuIDE4IG1haiAyMDE2IDU6NDkgZW0g c2tyZXYgTmljb2zDoXMgPG5pY29sYXNAZGV2ZWxzLmVzPjoNCj4+ID4NCj4+ID4gSGksDQo+PiA+ DQo+PiA+IFByb2JhYmx5IG5vdCBhbiBvVmlydCBpc3N1ZSwgYnV0IG1heWJlIHNvbWVvbmUgY2Fu IGhlbHAuIEkndmUgZGVwbG95ZWQgYQ0KPj4gPiBwcmV0dHkgYmFzaWMgVk0gKHVidW50dSAxNC4w NCBzZXJ2ZXIsIDRHQiBSQU0sIDQgQ1BVcywgMTVHQiBzdG9yYWdlKS4NCj4+DQo+PiBKdXN0IHNw aXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBhbnkgb3RoZXIgT1Mg Zm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVzdCByZWxhdGVkIHJh dGhlciB0aGFuIG9WaXJ0Lg0KPj4NCj4+IC9LDQo+DQo+DQo+IEkgdHJpZWQgYSB2YW5pbGxhIGNl bnRvcy03LjEgYXMgd2VsbCBhbmQgdGhlIHNhbWUgaGFwcGVucy4gSSdtIG9mIHRoZSBzYW1lIG9w aW5pb24gdGhhdCB0aGlzIGlzIG1vcmUgYSBndWVzdCByZWxhdGVkIGlzc3VlLCBpdCdzIGp1c3Qg SSdkIGxpa2UgdG8gZmluZCBvdXQgd2h5IHRoaXMgb25seSBoYXBwZW5zIHdpdGggUVhMIGFuZCBu b3Qgd2l0aCBDSVJSVVMuDQo+DQo+IFRoYW5rcy4NCg0KVmVyeSBpbnRlcmVzdGluZy4gQXJlIHlv dXIgaG9zdHMgYWxsIG9mIHRoZSBzYW1lIGFyY2hpdGVjdHVyZShmYW1pbHkpPw0KDQovSw0KDQo+ DQo+PiA+IEVhY2ggdGltZSBJIGluc3RhbGwgYW4gYWRkaXRpb25hbCBkZXNrdG9wIGVudmlyb25t ZW50IChHbm9tZSwgS0RFLA0KPj4gPiB3aGF0ZXZlci4uLiksIENQVSB1c2FnZSByaXNlcyB0byAx MDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQNCj4+ID4gaW50ZXJhY3Rpbmcgd2l0aCB0 aGUgbWFjaGluZSBiZWNvbWVzIGltcG9zc2libGUgKG1heWJlIGEgbW91c2UgbW92ZW1lbnQNCj4+ ID4gaXMgcHJvcGFnYXRlZCAzIG1pbnV0ZXMgbGF0ZXIgb3Igc28uLi4pLg0KPj4gPg0KPj4gPiBU byBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0IGRl c2t0b3ANCj4+ID4gZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBzZWUgdGhlcmUg aXMgYW4gWG9yZyBwcm9jZXNzDQo+PiA+IGNvbnN1bWluZyBvbmUgb2YgdGhlIENQVXMgYW5kIHRo ZSBtYWNoaW5lIHN0b3BzIHJlc3BvbmRpbmcgYXMgZmFyIGFzIHRoZQ0KPj4gPiBkZXNrdG9wIGVu dmlyb25tZW50IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUNCj4+ID4g Y29uZmlndXJhdGlvbiBmaWxlLg0KPj4gPg0KPj4gPiBJIGNvdWxkIGFsc28gc2VlIHRoaXMgb25s eSBoYXBwZW5zIHdoZW4gUVhMIGlzIGNob3NlbiBhcyB0aGUgZGlzcGxheQ0KPj4gPiBkcml2ZXIu IFdoZW4gQ0lSUlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhseSBhbmQgQ1BV IGlzDQo+PiA+IH4xMDAlIGlkbGUuIFRoZSBkb3duc2lkZSBpcyB0aGF0IHdlIHdhbnQgdG8gdXNl IFNQSUNFIGFuZCBDSVJSVVMgd29uJ3QNCj4+ID4gYWxsb3cgaXQuDQo+PiA+DQo+PiA+IFdoeSBk b2VzIHRoaXMgaGFwcGVuPyBJcyB0aGlzIGFuIE9TLXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGlu dCBob3cgY2FuDQo+PiA+IGl0IGJlIGZpeGVkPw0KPj4gPg0KPj4gPiBUaGFua3MuDQo+PiA+DQo+ PiA+IE5pY29sw6FzDQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiA+IFVzZXJzIG1haWxpbmcgbGlzdA0KPj4gPiBVc2Vyc0BvdmlydC5vcmcN Cj4+ID4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+DQo+ DQo= --_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <00292E3F88DC80458009E189EFB6ABC9(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxOCBtYWogMjAxNiA3OjAzIGVtIHNrcmV2IE5pY29sw6FzICZsdDtuaWNvbGFz QGRldmVscy5lcyZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgS2FybGksPGJyPg0KJmd0Ozxi cj4NCiZndDsgRWwgMTgvMDUvMTYgYSBsYXMgMTY6NTksIEthcmxpIFNqw7ZiZXJnIGVzY3JpYmnD szo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRGVuIDE4IG1haiAy MDE2IDU6NDkgZW0gc2tyZXYgTmljb2zDoXMgJmx0O25pY29sYXNAZGV2ZWxzLmVzJmd0Ozo8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyBQcm9iYWJseSBub3QgYW4gb1ZpcnQgaXNzdWUsIGJ1dCBtYXli ZSBzb21lb25lIGNhbiBoZWxwLiBJJ3ZlIGRlcGxveWVkIGEgPGJyPg0KJmd0OyZndDsgJmd0OyBw cmV0dHkgYmFzaWMgVk0gKHVidW50dSAxNC4wNCBzZXJ2ZXIsIDRHQiBSQU0sIDQgQ1BVcywgMTVH QiBzdG9yYWdlKS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEp1c3Qgc3BpdGJhbGxpbmcg aGVyZTogMTQuMDQgb25seT8gVHJpZWQgMTYuMDQsIG9yIGFueSBvdGhlciBPUyBmb3IgdGhhdCBt YXR0ZXI/IEZvciBub3csIGl0IHNvdW5kcyBtb3JlIGd1ZXN0IHJlbGF0ZWQgcmF0aGVyIHRoYW4g b1ZpcnQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAvSzxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJIHRyaWVkIGEgdmFuaWxsYSBjZW50b3MtNy4xIGFzIHdlbGwgYW5kIHRoZSBz YW1lIGhhcHBlbnMuIEknbSBvZiB0aGUgc2FtZSBvcGluaW9uIHRoYXQgdGhpcyBpcyBtb3JlIGEg Z3Vlc3QgcmVsYXRlZCBpc3N1ZSwgaXQncyBqdXN0IEknZCBsaWtlIHRvIGZpbmQgb3V0IHdoeSB0 aGlzIG9ubHkgaGFwcGVucyB3aXRoIFFYTCBhbmQgbm90IHdpdGggQ0lSUlVTLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoYW5rcy48L3A+DQo8cCBkaXI9Imx0ciI+VmVyeSBpbnRlcmVzdGluZy4gQXJl IHlvdXIgaG9zdHMgYWxsIG9mIHRoZSBzYW1lIGFyY2hpdGVjdHVyZShmYW1pbHkpPzwvcD4NCjxw IGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBF YWNoIHRpbWUgSSBpbnN0YWxsIGFuIGFkZGl0aW9uYWwgZGVza3RvcCBlbnZpcm9ubWVudCAoR25v bWUsIEtERSwgPGJyPg0KJmd0OyZndDsgJmd0OyB3aGF0ZXZlci4uLiksIENQVSB1c2FnZSByaXNl cyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQgPGJyPg0KJmd0OyZndDsgJmd0 OyBpbnRlcmFjdGluZyB3aXRoIHRoZSBtYWNoaW5lIGJlY29tZXMgaW1wb3NzaWJsZSAobWF5YmUg YSBtb3VzZSBtb3ZlbWVudCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGlzIHByb3BhZ2F0ZWQgMyBtaW51 dGVzIGxhdGVyIG9yIHNvLi4uKS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyBUbyBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0 IGRlc2t0b3AgPGJyPg0KJmd0OyZndDsgJmd0OyBlbnZpcm9ubWVudCBiYXNlZCBvbiBYb3JnLiBJ IGNvdWxkIHNlZSB0aGVyZSBpcyBhbiBYb3JnIHByb2Nlc3MgPGJyPg0KJmd0OyZndDsgJmd0OyBj b25zdW1pbmcgb25lIG9mIHRoZSBDUFVzIGFuZCB0aGUgbWFjaGluZSBzdG9wcyByZXNwb25kaW5n IGFzIGZhciBhcyB0aGUgPGJyPg0KJmd0OyZndDsgJmd0OyBkZXNrdG9wIGVudmlyb25tZW50IGdv ZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUgPGJyPg0KJmd0OyZndDsgJmd0 OyBjb25maWd1cmF0aW9uIGZpbGUuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsgSSBjb3VsZCBhbHNvIHNlZSB0aGlzIG9ubHkgaGFwcGVucyB3aGVuIFFYTCBpcyBjaG9zZW4g YXMgdGhlIGRpc3BsYXkgPGJyPg0KJmd0OyZndDsgJmd0OyBkcml2ZXIuIFdoZW4gQ0lSUlVTIGlz IGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhseSBhbmQgQ1BVIGlzIDxicj4NCiZndDsm Z3Q7ICZndDsgfjEwMCUgaWRsZS4gVGhlIGRvd25zaWRlIGlzIHRoYXQgd2Ugd2FudCB0byB1c2Ug U1BJQ0UgYW5kIENJUlJVUyB3b24ndCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGFsbG93IGl0Ljxicj4N CiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJ cyB0aGlzIGFuIE9TLXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuIDxicj4NCiZn dDsmZ3Q7ICZndDsgaXQgYmUgZml4ZWQ/PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsgVGhhbmtzLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IE5pY29s w6FzPGJyPg0KJmd0OyZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsgVXNlcnMgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsgJmd0OyBVc2Vyc0BvdmlydC5vcmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGh0dHA6Ly9s aXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vyczxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_--

2 1