January 2018 - Users - oVirt List Archives

oVirt storage access failure from host
by Alex K 19 Jan '18

19 Jan '18

Hi All, I have a 3 server ovirt 4.1 selft hosted setup with gluster replica 3. I see that suddenly one of the hosts reported as unresponsive and at same time the /var/log/messages logged: ovirt-ha-broker ovirt_hosted_engine_ha.broker.listener.ConnectionHandler ERROR Error handling request, data: 'set-storage-domain FilesystemBackend dom_type=glusterfs sd_uuid=ad7b9e2a-7ae3-46ad-9429-5f5ef452eac8'#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py", line 166, in handle#012 data)#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py", line 299, in _dispatch#012 .set_storage_domain(client, sd_type, **options)#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py", line 66, in set_storage_domain#012 self._backends[client].connect()#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 462, in connect#012 self._dom_type)#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 107, in get_domain_path#012 " in {1}".format(sd_uuid, parent))#012BackendFailureException: path to storage domain ad7b9e2a-7ae3-46ad-9429-5f5ef452eac8 not found in /rhev/data-center/mnt/glusterSD Jan 15 11:04:56 v1 journal: vdsm root ERROR failed to retrieve Hosted Engine HA info#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/vdsm/host/api.py", line 231, in _getHaInfo#012 stats = instance.get_all_stats()#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 103, in get_all_stats#012 self._configure_broker_conn(broker)#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 180, in _configure_broker_conn#012 dom_type=dom_type)#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 177, in set_storage_domain#012 .format(sd_type, options, e))#012RequestError: Failed to set storage domain FilesystemBackend, options {'dom_type': 'glusterfs', 'sd_uuid': 'ad7b9e2a-7ae3-46ad-9429-5f5ef452eac8'}: Request failed: <class 'ovirt_hosted_engine_ha.lib.storage_backends.BackendFailureException'> At VDSM logs i see the following continuously logged: [jsonrpc.JsonRpcServer] RPC call VM.getStats failed (error 1) in 0.00 seconds (__init__:539) No errors seen at gluster at same time frame. Any hints on what is causing this issue? It seems a storage access issue but gluster was up and volumes ok. The VMs that I am running on top are Windows 10 and Windows 2016 64 bit. Thanx, Alex

2 2

correct settings for gluster based storage domain
by Artem Tambovskiy 19 Jan '18

19 Jan '18

I'm still troubleshooting the my oVirt 4.1.8 cluster and idea came to my mind that I have an issue with storage settings for hosted_engine storage domain. But in general if I have a 2 ovirt nodes running gluster + 3rd host as arbiter, how the settings should looks like? lets say I have a 3 nodes: ovirt1.domain.com (gluster + ovirt) ovirt2.domain.com (gluster + ovirt) ovirt3.domain.com (gluster) How the correct storage domain config should looks like? Option 1: /etc/ovirt-hosted-engine/hosted-engine.conf .... storage=ovirt1.domain.com:/engine mnt_options=backup-volfile-servers=ovirt2.domain.com:ovirt3.domain.com Option 2: /etc/ovirt-hosted-engine/hosted-engine.conf .... storage=localhost:/engine mnt_options=backup-volfile-servers=ovirt1.domain.com:ovirt2.domain.com:o virt3.domain.com Option 3: Setup a DNS record gluster.domain.com pointing to IP addresses of gluster nodes /etc/ovirt-hosted-engine/hosted-engine.conf .... storage=gluster.domain.com:/engine mnt_options= Of course its related not only to hosted engine domain, but to all gluster based storage domains. Thank you in advance! Regards, Artem

2 2

[ANN] oVirt 4.2.1 Second Release Candidate is now available
by Sandro Bonazzola 19 Jan '18

19 Jan '18

The oVirt Project is pleased to announce the availability of the oVirt 4.2.1 Second Release Candidate, as of January 18th, 2017 This update is a release candidate of the second in a series of stabilization updates to the 4.2 series. This is pre-release software. This pre-release should not to be used in production. [WARNING] right after we finished to compose the release candidate we discovered a regression in a disaster recovery flow causing wrong MAC address to be assigned to re-imported VMs. This release is available now for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node will be available soon [2] Additional Resources: * Read more about the oVirt 4.2.1 release highlights: http://www.ovirt.org/release/4.2.1/ * 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] http://www.ovirt.org/release/4.2.1/ [2] http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 2

Re: [ovirt-users] Problems with some vms
by Endre Karlson 19 Jan '18

19 Jan '18

One brick was at a point down for replacement. It has been replaced and all vols are up Status of volume: data Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovirt0:/gluster/brick3/data 49152 0 Y 22467 Brick ovirt2:/gluster/brick3/data 49152 0 Y 20736 Brick ovirt3:/gluster/brick3/data 49152 0 Y 23148 Brick ovirt0:/gluster/brick4/data 49153 0 Y 22497 Brick ovirt2:/gluster/brick4/data 49153 0 Y 20742 Brick ovirt3:/gluster/brick4/data 49153 0 Y 23158 Brick ovirt0:/gluster/brick5/data 49154 0 Y 22473 Brick ovirt2:/gluster/brick5/data 49154 0 Y 20748 Brick ovirt3:/gluster/brick5/data 49154 0 Y 23156 Brick ovirt0:/gluster/brick6/data 49155 0 Y 22479 Brick ovirt2:/gluster/brick6_1/data 49161 0 Y 21203 Brick ovirt3:/gluster/brick6/data 49155 0 Y 23157 Brick ovirt0:/gluster/brick7/data 49156 0 Y 22485 Brick ovirt2:/gluster/brick7/data 49156 0 Y 20763 Brick ovirt3:/gluster/brick7/data 49156 0 Y 23155 Brick ovirt0:/gluster/brick8/data 49157 0 Y 22491 Brick ovirt2:/gluster/brick8/data 49157 0 Y 20771 Brick ovirt3:/gluster/brick8/data 49157 0 Y 23154 Self-heal Daemon on localhost N/A N/A Y 23238 Bitrot Daemon on localhost N/A N/A Y 24870 Scrubber Daemon on localhost N/A N/A Y 24889 Self-heal Daemon on ovirt2 N/A N/A Y 24271 Bitrot Daemon on ovirt2 N/A N/A Y 24856 Scrubber Daemon on ovirt2 N/A N/A Y 24866 Self-heal Daemon on ovirt0 N/A N/A Y 29409 Bitrot Daemon on ovirt0 N/A N/A Y 5457 Scrubber Daemon on ovirt0 N/A N/A Y 5468 Task Status of Volume data ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: engine Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovirt0:/gluster/brick1/engine 49158 0 Y 22511 Brick ovirt2:/gluster/brick1/engine 49158 0 Y 20780 Brick ovirt3:/gluster/brick1/engine 49158 0 Y 23199 Self-heal Daemon on localhost N/A N/A Y 23238 Self-heal Daemon on ovirt0 N/A N/A Y 29409 Self-heal Daemon on ovirt2 N/A N/A Y 24271 Task Status of Volume engine ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: iso Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick ovirt0:/gluster/brick2/iso 49159 0 Y 22520 Brick ovirt2:/gluster/brick2/iso 49159 0 Y 20789 Brick ovirt3:/gluster/brick2/iso 49159 0 Y 23208 NFS Server on localhost N/A N/A N N/A Self-heal Daemon on localhost N/A N/A Y 23238 NFS Server on ovirt2 N/A N/A N N/A Self-heal Daemon on ovirt2 N/A N/A Y 24271 NFS Server on ovirt0 N/A N/A N N/A Self-heal Daemon on ovirt0 N/A N/A Y 29409 Task Status of Volume iso ------------------------------------------------------------------------------ There are no active volume tasks 2018-01-17 8:13 GMT+01:00 Gobinda Das <godas(a)redhat.com>: > Hi, > I can see some error in log: > [2018-01-14 11:19:49.886571] E [socket.c:2309:socket_connect_finish] > 0-engine-client-0: connection to 10.2.0.120:24007 failed (Connection > timed out) > [2018-01-14 11:20:05.630669] E [socket.c:2309:socket_connect_finish] > 0-engine-client-0: connection to 10.2.0.120:24007 failed (Connection > timed out) > [2018-01-14 12:01:09.089925] E [MSGID: 114058] > [client-handshake.c:1527:client_query_portmap_cbk] 0-engine-client-0: > failed to get the port number for remote subvolume. Please run 'gluster > volume status' on server to see if brick process is running. > [2018-01-14 12:01:09.090048] I [MSGID: 114018] > [client.c:2280:client_rpc_notify] 0-engine-client-0: disconnected from > engine-client-0. Client process will keep trying to connect to glusterd > until brick's port is available > > Can you please check gluster volume status and see if all bricks are up? > > On Wed, Jan 17, 2018 at 12:24 PM, Endre Karlson <endre.karlson(a)gmail.com> > wrote: > >> It's there now for each of the hosts. ovirt1 is not in service yet. >> >> 2018-01-17 5:52 GMT+01:00 Gobinda Das <godas(a)redhat.com>: >> >>> In the above url only data and iso mnt log present,But there is no >>> engine and vmstore mount log. >>> >>> On Wed, Jan 17, 2018 at 1:26 AM, Endre Karlson <endre.karlson(a)gmail.com> >>> wrote: >>> >>>> Hi, all logs are located here: https://www.dropbox.com/ >>>> sh/3qzmwe76rkt09fk/AABzM9rJKbH5SBPWc31Npxhma?dl=0 for the mounts >>>> >>>> additionally we replaced a broken disk that is now resynced. >>>> >>>> 2018-01-15 11:17 GMT+01:00 Gobinda Das <godas(a)redhat.com>: >>>> >>>>> Hi Endre, >>>>> Mount logs will be in below format inside /var/log/glusterfs : >>>>> >>>>> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_engine.log >>>>> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_data.log >>>>> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_vmstore.log >>>>> >>>>> On Mon, Jan 15, 2018 at 11:57 AM, Endre Karlson < >>>>> endre.karlson(a)gmail.com> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> What are the gluster mount logs ? >>>>>> >>>>>> I have these gluster logs. >>>>>> cli.log etc-glusterfs-glusterd.vol.log >>>>>> glfsheal-engine.log glusterd.log nfs.log >>>>>> rhev-data-center-mnt-glusterSD-ovirt0:_engine.log >>>>>> rhev-data-center-mnt-glusterSD-ovirt3:_iso.log >>>>>> cmd_history.log glfsheal-data.log glfsheal-iso.log >>>>>> glustershd.log rhev-data-center-mnt-glusterSD-ovirt0:_data.log >>>>>> rhev-data-center-mnt-glusterSD-ovirt0:_iso.log statedump.log >>>>>> >>>>>> >>>>>> I am running version >>>>>> glusterfs-server-3.12.4-1.el7.x86_64 >>>>>> glusterfs-geo-replication-3.12.4-1.el7.x86_64 >>>>>> libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64 >>>>>> glusterfs-libs-3.12.4-1.el7.x86_64 >>>>>> glusterfs-api-3.12.4-1.el7.x86_64 >>>>>> python2-gluster-3.12.4-1.el7.x86_64 >>>>>> glusterfs-client-xlators-3.12.4-1.el7.x86_64 >>>>>> glusterfs-cli-3.12.4-1.el7.x86_64 >>>>>> glusterfs-events-3.12.4-1.el7.x86_64 >>>>>> glusterfs-rdma-3.12.4-1.el7.x86_64 >>>>>> vdsm-gluster-4.20.9.3-1.el7.centos.noarch >>>>>> glusterfs-3.12.4-1.el7.x86_64 >>>>>> glusterfs-fuse-3.12.4-1.el7.x86_64 >>>>>> >>>>>> // Endre >>>>>> >>>>>> 2018-01-15 6:11 GMT+01:00 Gobinda Das <godas(a)redhat.com>: >>>>>> >>>>>>> Hi Endre, >>>>>>> Can you please provide glusterfs mount logs? >>>>>>> >>>>>>> On Mon, Jan 15, 2018 at 6:16 AM, Darrell Budic < >>>>>>> budic(a)onholyground.com> wrote: >>>>>>> >>>>>>>> What version of gluster are you running? I’ve seen a few of these >>>>>>>> since moving my storage cluster to 12.3, but still haven’t been able to >>>>>>>> determine what’s causing it. Seems to be happening most often on VMs that >>>>>>>> haven’t been switches over to libgfapi mounts yet, but even one of those >>>>>>>> has paused once so far. They generally restart fine from the GUI, and >>>>>>>> nothing seems to need healing. >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* Endre Karlson <endre.karlson(a)gmail.com> >>>>>>>> *Subject:* [ovirt-users] Problems with some vms >>>>>>>> *Date:* January 14, 2018 at 12:55:45 PM CST >>>>>>>> *To:* users >>>>>>>> >>>>>>>> Hi, we are getting some errors with some of our vms in a 3 node >>>>>>>> server setup. >>>>>>>> >>>>>>>> 2018-01-14 15:01:44,015+0100 INFO (libvirt/events) [virt.vm] >>>>>>>> (vmId='2c34f52d-140b-4dbe-a4bd-d2cb467b0b7c') abnormal vm stop >>>>>>>> device virtio-disk0 error eother (vm:4880) >>>>>>>> >>>>>>>> We are running glusterfs for shared storage. >>>>>>>> >>>>>>>> I have tried setting global maintenance on the first server and >>>>>>>> then issuing a 'hosted-engine --vm-start' but that leads to nowhere. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Gobinda >>>>>>> +91-9019047912 <+91%2090190%2047912> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> Gobinda >>>>> +91-9019047912 <+91%2090190%2047912> >>>>> >>>> >>>> >>> >>> >>> -- >>> Thanks, >>> Gobinda >>> +91-9019047912 <+91%2090190%2047912> >>> >> >> > > > -- > Thanks, > Gobinda > +91-9019047912 <+91%2090190%2047912> >

1 1

Re: [ovirt-users] oVirt home lab hardware
by Abdurrahman A. Ibrahim 19 Jan '18

19 Jan '18

One more thing, Do you have power switch? Best regards, Ab On 19 Jan 2018 10:44 am, "Abdurrahman A. Ibrahim" <a.rahman.attia(a)gmail.com> wrote: > Thank you Jayme for your reply, > > I have some concerns regarding space, noise and power consumption. > > Would you mind to share your experience regarding those three parameters > with us? > > Best regards, > Ab > > > > > On 18 Jan 2018 10:23 pm, "Jayme" <jaymef(a)gmail.com> wrote: > > For rackmount Dell R710's are fairly popular for home labs, they have good > specs and can be found at reasonable prices on ebay. > > On Thu, Jan 18, 2018 at 4:52 PM, Abdurrahman A. Ibrahim < > a.rahman.attia(a)gmail.com> wrote: > >> Hello, >> >> I am planning to buy home lab hardware to be used by oVirt. >> >> Any recommendations for used hardware i can buy from eBay for example? >> Also, have you tried oVirt on Intel NUC or any other SMB servers before? >> >> Thanks, >> Ab >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > >

1 0

Q: Optimal settings for DB hosting
by andreil1 19 Jan '18

19 Jan '18

Hi ! What is optimal setting for oVirt KVM guests for database hosting on Xeon server (2 x Xeon 4-core each) (in my case this is Firebird based accounting/stock control system with several clients active)? 1st of course its preallocated disk image. VirtO-SCSI enabled Migration disabled. Balloning disabled. CPU shares disabled Pass-through host CPU enabled What should be other CPU settings? For example, Xeon have 2 threads per core, should I set in oVirt 1 or 2 threads per virtual CPU? IO Threads on or off? Any idea of NUMA settings ? Node running 4 VMs total, CPU load is quite low, RAM is enough to preallocate for each VM + 4GB for node itself. Thanks in advance ! Andrei

1 0

web 404 after reinstall ovirt-engine
by 董青龙 19 Jan '18

19 Jan '18

------=_Part_69969_201422119.1516342255693 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGksIGFsbAogICAgICAgIEkgaW5zdGFsbGVkIG92aXJ0LWVuZ2luZSA0LjEuOC4yIGZvciB0aGUg c2Vjb25kIHRpbWUgYW5kIEkgZ290ICJzdWNjZXNzZnVsIiBhZnRlciBJIGV4Y3V0ZWQgImVuZ2lu ZS1zZXR1cCIuIEJ1dCBJIGdvdCAiNDA0IiB3aGVuIEkgdHJpZWQgdG8gYWNjZXNzIHdlYmFkbWlu IHBvcnRhbCB1c2luZyAiaHR0cHM6Ly9GUUROL292aXJ0LWVuZ2luZSIuIEJ5IHRoZSB3YXksIEkg Y291bGQgYWNjZXNzIHRoZSB3ZWIgYWZ0ZXIgSSBpbnN0YWxsZWQgb3ZpcnQtZW5naW5lIGZvciB0 aGUgZmlyc3QgdGltZS4gVGhlbiBJIGV4Y3V0ZWQgImVuZ2luZS1jbGVhbnVwIiBhbmQgInl1bSBy ZW1vdmUgb3ZpcnQtZW5naW5lIiBhbmQgaW5zdGFsbGVkIG92aXJ0LWVuZ2luZSBmb3IgdGhlIHNl Y29uZCB0aW1lLiBJIGFsc28gdHJpZWQgdG8gcmVtb3ZlIG92aXJ0LWVuZ2luZS1kd2ggYW5kIHBv c3RncmVzcWwgYnV0IGFmdGVyIEkgcmVpbnN0YWxsZWQgb3ZpcnQtZW5naW5lIEkgc3RpbGwgZ290 ICI0MDQiLgogICAgICAgIENhbiBJIGZpeCB0aGlzIHByb2JsZW0/IEhvcGUgc29tZSBjYW4gaGVs cCwgdGhhbmtzIQogICAgICAgIEhlcmUgYXJlIHNvbWUgbG9ncyBpbiAiL3Zhci9sb2cvb3ZpcnQt ZW5naW5lL2VuZ2luZS5sb2ciOgouLi4KMjAxOC0wMS0xOSAxMjo1NjowNiwyODgrMDggRVJST1Ig W29yZy5vdmlydC5lbmdpbmUudWkuZnJvbnRlbmQuc2VydmVyLmRhc2hib2FyZC5EYXNoYm9hcmRE YXRhU2VydmxldF0gKFNlcnZlclNlcnZpY2UgVGhyZWFkIFBvb2wgLS0gNjEpIFtdIENvdWxkIG5v dCBhY2Nlc3MgZW5naW5lJ3MgRFdIIGNvbmZpZ3VyYXRpb24gdGFibGU6IGphdmEuc3FsLlNRTEV4 Y2VwdGlvbjogamF2YXgucmVzb3VyY2UuUmVzb3VyY2VFeGNlcHRpb246IElKMDAwNDUzOiBVbmFi bGUgdG8gZ2V0IG1hbmFnZWQgY29ubmVjdGlvbiBmb3IgamF2YTovRU5HSU5FRGF0YVNvdXJjZQou Li4KQ2F1c2VkIGJ5OiBqYXZheC5yZXNvdXJjZS5SZXNvdXJjZUV4Y2VwdGlvbjogSUowMDA0NTM6 IFVuYWJsZSB0byBnZXQgbWFuYWdlZCBjb25uZWN0aW9uIGZvciBqYXZhOi9FTkdJTkVEYXRhU291 cmNlCi4uLgpDYXVzZWQgYnk6IGphdmF4LnJlc291cmNlLlJlc291cmNlRXhjZXB0aW9uOiBJSjAz MTA4NDogVW5hYmxlIHRvIGNyZWF0ZSBjb25uZWN0aW9uCi4uLgpDYXVzZWQgYnk6IG9yZy5wb3N0 Z3Jlc3FsLnV0aWwuUFNRTEV4Y2VwdGlvbjogRkFUQUw6IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9u IGZhaWxlZCBmb3IgdXNlciAiZW5naW5lIgouLi4KMjAxOC0wMS0xOSAxMjo1NjowNiwyOTIrMDgg V0FSTiAgW29yZy5vdmlydC5lbmdpbmUudWkuZnJvbnRlbmQuc2VydmVyLmRhc2hib2FyZC5EYXNo Ym9hcmREYXRhU2VydmxldF0gKFNlcnZlclNlcnZpY2UgVGhyZWFkIFBvb2wgLS0gNjEpIFtdIE5v IHZhbGlkIERXSCBjb25maWd1cmF0aW9ucyB3ZXJlIGZvdW5kLCBhc3N1bWluZyBEV0ggZGF0YWJh c2UgaXNuJ3Qgc2V0dXAuCjIwMTgtMDEtMTkgMTI6NTY6MDYsMjkyKzA4IElORk8gIFtvcmcub3Zp cnQuZW5naW5lLnVpLmZyb250ZW5kLnNlcnZlci5kYXNoYm9hcmQuRGFzaGJvYXJkRGF0YVNlcnZs ZXRdIChTZXJ2ZXJTZXJ2aWNlIFRocmVhZCBQb29sIC0tIDYxKSBbXSBEYXNoYm9hcmQgREIgcXVl cnkgY2FjaGUgaGFzIGJlZW4gZGlzYWJsZWQu ------=_Part_69969_201422119.1516342255693 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGksIGFsbDwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEkgaW5zdGFsbGVkIG92aXJ0LWVuZ2luZSA0LjEuOC4yIGZvciB0aGUgc2Vj b25kIHRpbWUgYW5kIEkgZ290ICJzdWNjZXNzZnVsIiBhZnRlciBJIGV4Y3V0ZWQgImVuZ2luZS1z ZXR1cCIuIEJ1dCBJIGdvdCAiNDA0IiB3aGVuIEkgdHJpZWQgdG8gYWNjZXNzIHdlYmFkbWluIHBv cnRhbCB1c2luZyAiaHR0cHM6Ly9GUUROL292aXJ0LWVuZ2luZSIuIEJ5IHRoZSB3YXksIEkgY291 bGQgYWNjZXNzIHRoZSB3ZWIgYWZ0ZXIgSSBpbnN0YWxsZWQgb3ZpcnQtZW5naW5lIGZvciB0aGUg Zmlyc3QgdGltZS4gVGhlbiBJIGV4Y3V0ZWQgImVuZ2luZS1jbGVhbnVwIiBhbmQgInl1bSByZW1v dmUgb3ZpcnQtZW5naW5lIiBhbmQgaW5zdGFsbGVkIG92aXJ0LWVuZ2luZSBmb3IgdGhlIHNlY29u ZCB0aW1lLiBJIGFsc28gdHJpZWQgdG8gcmVtb3ZlIG92aXJ0LWVuZ2luZS1kd2ggYW5kIHBvc3Rn cmVzcWwgYnV0IGFmdGVyIEkgcmVpbnN0YWxsZWQgb3ZpcnQtZW5naW5lIEkgc3RpbGwgZ290ICI0 MDQiLjwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbiBJIGZpeCB0aGlz IHByb2JsZW0/IEhvcGUgc29tZSBjYW4gaGVscCwgdGhhbmtzITwvZGl2PjxkaXY+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEhlcmUgYXJlIHNvbWUgbG9ncyBpbiAiL3Zhci9sb2cvb3ZpcnQt ZW5naW5lL2VuZ2luZS5sb2ciOjwvZGl2PjxkaXY+Li4uPC9kaXY+PGRpdj4yMDE4LTAxLTE5IDEy OjU2OjA2LDI4OCswOCBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS51aS5mcm9udGVuZC5zZXJ2ZXIu ZGFzaGJvYXJkLkRhc2hib2FyZERhdGFTZXJ2bGV0XSAoU2VydmVyU2VydmljZSBUaHJlYWQgUG9v bCAtLSA2MSkgW10gQ291bGQgbm90IGFjY2VzcyBlbmdpbmUncyBEV0ggY29uZmlndXJhdGlvbiB0 YWJsZTogamF2YS5zcWwuU1FMRXhjZXB0aW9uOiBqYXZheC5yZXNvdXJjZS5SZXNvdXJjZUV4Y2Vw dGlvbjogSUowMDA0NTM6IFVuYWJsZSB0byBnZXQgbWFuYWdlZCBjb25uZWN0aW9uIGZvciBqYXZh Oi9FTkdJTkVEYXRhU291cmNlPC9kaXY+PGRpdj4uLi48L2Rpdj48ZGl2PkNhdXNlZCBieTogamF2 YXgucmVzb3VyY2UuUmVzb3VyY2VFeGNlcHRpb246IElKMDAwNDUzOiBVbmFibGUgdG8gZ2V0IG1h bmFnZWQgY29ubmVjdGlvbiBmb3IgamF2YTovRU5HSU5FRGF0YVNvdXJjZTwvZGl2PjxkaXY+Li4u PC9kaXY+PGRpdj5DYXVzZWQgYnk6IGphdmF4LnJlc291cmNlLlJlc291cmNlRXhjZXB0aW9uOiBJ SjAzMTA4NDogVW5hYmxlIHRvIGNyZWF0ZSBjb25uZWN0aW9uPC9kaXY+PGRpdj4uLi48L2Rpdj48 ZGl2PkNhdXNlZCBieTogb3JnLnBvc3RncmVzcWwudXRpbC5QU1FMRXhjZXB0aW9uOiBGQVRBTDog cGFzc3dvcmQgYXV0aGVudGljYXRpb24gZmFpbGVkIGZvciB1c2VyICJlbmdpbmUiPC9kaXY+PGRp dj4uLi48L2Rpdj48ZGl2PjIwMTgtMDEtMTkgMTI6NTY6MDYsMjkyKzA4IFdBUk4gJm5ic3A7W29y Zy5vdmlydC5lbmdpbmUudWkuZnJvbnRlbmQuc2VydmVyLmRhc2hib2FyZC5EYXNoYm9hcmREYXRh U2VydmxldF0gKFNlcnZlclNlcnZpY2UgVGhyZWFkIFBvb2wgLS0gNjEpIFtdIE5vIHZhbGlkIERX SCBjb25maWd1cmF0aW9ucyB3ZXJlIGZvdW5kLCBhc3N1bWluZyBEV0ggZGF0YWJhc2UgaXNuJ3Qg c2V0dXAuPC9kaXY+PGRpdj4yMDE4LTAxLTE5IDEyOjU2OjA2LDI5MiswOCBJTkZPICZuYnNwO1tv cmcub3ZpcnQuZW5naW5lLnVpLmZyb250ZW5kLnNlcnZlci5kYXNoYm9hcmQuRGFzaGJvYXJkRGF0 YVNlcnZsZXRdIChTZXJ2ZXJTZXJ2aWNlIFRocmVhZCBQb29sIC0tIDYxKSBbXSBEYXNoYm9hcmQg REIgcXVlcnkgY2FjaGUgaGFzIGJlZW4gZGlzYWJsZWQuPC9kaXY+PC9kaXY+PGJyPjxicj48c3Bh biB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_69969_201422119.1516342255693--

3 4

The future of backups in oVirt 4.2+
by Jayme 19 Jan '18

19 Jan '18

I've been running a non-production oVirt setup for a while and plan on building a more robust oVirt setup for eventual production use. Part of that planning of course is backup/disaster recovery options. I've been playing around with a few options to backup oVirt, I'm sure most of you are aware of them. The github webfix it python scripts, and starting to look at bacchus as well although have not set it up or tested bacchus yet. The webfix it python script is fairly simple to setup and seems to work ok as intended, even on 4.2, but it's definitely clunky in terms of having to snapshot, clone, export. A lot of resource usage. I assume bacchus most likely uses the same method of snapshot/clone/export as well (due to what was available in oVirt at the time these scripts were written). My concerns with using something like these are: 1. It's using old 3x api -- which is fine for now but probably not with oVirt 4.3 2. Inefficient / resource intensive 3. Using export domain which is depreciated >From what I've read in oVirt documentation the Export domain is depreciated. I assume that this means that instead of a export domain you could instead create a regular data domain for backups that can be detached and attached to another environment, is that the correct assumption? I've also read that it might be possible to skip the cloning of the VM part and export snapshots directly. Is this now possible in 4.2 or will be in the future? if it is possible to perform VM backups without cloning to a new VM first is anyone aware of any scripts/software that is available now which takes advantage of that? Essentially all I want is a simple solution to backup my VMs to separate NFS storage. If for some reason my main storage crashes I then have the option to connect that backup NFS storage to a secondary stand alone oVirt instance and run my VMs from there until the primary oVirt instance is repaired. What I want to avoid is implementing an older more inefficient solution that might work for a while but will eventually no longer work due to ovIrt updates in the future. I know options like active-active failover and georeplication exist but that may be too complex for my needs although I would be interested in hearing about how some of you may be implementing these features. In summary, I'd trying to figure out what the best backup option may be going forward with oVirt in the future so I can implement the best option from the start rather than having to change it all around in the near future. Thanks!

4 6

Zombie kworker process on node took 100% CPU load
by Andrei V 18 Jan '18

18 Jan '18

Hi, I've got strange problem with oVirt Node 4.2 installed on CentOS 7 with mainline 4.14 kernel & HP ProLiant ML350. Kworker process loaded 1 cpu CPU core at 100%, and since it didn't finish even after several hours, it was clearly a zombie. I logged into each VM, and powered them off with "shutdown now". From SPICE console it was seen VMs halted. However, in oVirt engine web they have been marked with tripple green down arrow. An attempt to shutdown them completely with oVirt button resulted in error message something like "Can't shutdown VM because highly available and can't be moved". Sorry, I forgot to take screenshot. Its was also impossible to shutdown the node correctly, process freezes. After restart, everything seem to work correctly. Anyone have any idea how to cope with this kind of problem? Thanks in advance Andrei

1 0

docker, kubernetes and ovirt
by Nathanaël Blanchet 18 Jan '18

18 Jan '18

Hi all, Regarding to this video : https://www.youtube.com/watch?v=JyyST4ZKne8 and ovedou.blogspot.fr/2014/03/running-docker-container-in-ovirt.html, it appears that some stuff has been done in integrated docker into ovirt. I'm interested into these two UI plugins : docker-resources (I found it in samples-uiplugins) and the kubernetes one that I didn't find anywhere. Can anyone tell me if the development of that projects are definitively stopped and the reason why? -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

3 3

oVirt Node 4.1.8 -> 4.2 upgrade
by Ed Stout 18 Jan '18

18 Jan '18

Good Morning, Perhaps someone could clarify for me, please - to update oVirt Nodes from 4.1.8 -> 4.2, should I just be able to yum install the 4.2 release file, then yum update? Or, do I have to start with the 4.2 ISO then update from there? When I try the former it fails with dependency issues for the nodes, I did however manage to update a self hosted appliance engine to 4.2. I had a read through the mailing list archive and couldn't find similar issues, so perhaps I'm doing something wrong. --> Processing Dependency: lshw for package: vdsm-4.20.9.3-1.el7.centos.x86_64 --> Finished Dependency Resolution Error: Package: ovirt-hosted-engine-setup-2.2.3-1.el7.centos.noarch (ovirt-4.2) Requires: libvirt-daemon-config-network Error: Package: ovirt-hosted-engine-setup-2.2.3-1.el7.centos.noarch (ovirt-4.2) Requires: virt-install Error: Package: glusterfs-geo-replication-3.12.3-1.el7.x86_64 (ovirt-4.2-centos-gluster312) Requires: python-prettytable Error: Package: vdsm-4.20.9.3-1.el7.centos.x86_64 (ovirt-4.2) Requires: lshw Error: Package: glusterfs-events-3.12.3-1.el7.x86_64 (ovirt-4.2-centos-gluster312) Requires: python-prettytable You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest OS Version: RHEL - 7 - 4.1708.el7.centos OS Description: oVirt Node 4.1.8 Kernel Version: 3.10.0 - 693.11.1.el7.x86_64 KVM Version: 2.9.0 - 16.el7_4.8.1 LIBVIRT Version: libvirt-3.2.0-14.el7_4.5 VDSM Version: vdsm-4.19.43-1.el7.centos SPICE Version: 0.12.8 - 2.el7.1 GlusterFS Version: glusterfs-3.8.15-2.el7 CEPH Version: librbd1-0.94.5-2.el7 Cheers, Ed

5 8

gluster volume permission denied
by Bill James 18 Jan '18

18 Jan '18

I have one node in our cluster that has problems when migrating a VM if the VM is hosted on a gluster volume. If the VM is hosted on a NFS volume it migrates fine. /var/log/messages: Jan 16 14:36:09 ovirt1 libvirtd: 2018-01-16 22:36:09.769+0000: 9700: error : qemuProcessReportLogError:1862 : internal error: process exited while connecting to monitor: 2018-01-16T22:36:09.587405Z qemu-kvm: -drive file=/rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb/images/60 3271e4-3089-4779-aa1c-faf280fabd17/7c7f7726-4ab0-4047-9b91-e0817a139e90,format=raw,if=none,id=drive-virtio- disk0,serial=603271e4-3089-4779-aa1c-faf280fabd17,cache=none,werror=stop,rerror=stop,aio=threads: Could not open '/rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb/images/603271e4-3089-4779-aa1c-faf280fabd17/7c7f7726-4ab0-4047-9b91-e0817a139e90': Permission denied (libvirt/csapi1.test.j2noc.com.log says same thing) [root@ovirt1 test log]# ls -hl /rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb/images/603271e4-3089-4779-aa1c-faf280fabd17/7c7f7726-4ab0-4047-9b91-e0817a139e90 -rw-rw---- 1 vdsm kvm 20G Jan 16 15:32 /rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb/images/603271e4-3089-4779-aa1c-faf280fabd17/7c7f7726-4ab0-4047-9b91-e0817a139e90 lrwxrwxrwx 1 vdsm kvm 98 Jan 10 21:21 67b4d9aa-f174-436a-b5a1-ec7cee5f2edb -> /rhev/data-center/mnt/glusterSD/ovirt3-ks.test.j2noc.com:_gv3/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb engine.log: 2018-01-16 14:36:18,846-08 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (o rg.ovirt.thread.pool-6-thread-34) [78d8b38c] EVENT_ID: VM_MIGRATION_TRYING_RERUN(128), Correlation ID: e39 9da53-cd31-401c-bf63-16b118b8884c, Job ID: 4db6bd87-0da4-4358-acae-dc453c813969, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Failed to migrate VM csapi1.test.j2noc.com to Host ovirt1.test.j2n oc.com . Trying to migrate to another Host. ovirt-engine-tools-4.1.8.2-1.el7.centos.noarch glusterfs-3.8.15-2.el7.x86_64 vdsm-4.19.43-1.el7.centos.x86_64 libvirt-daemon-3.2.0-14.el7_4.7.x86_64 Let me know what logs would be useful in troubleshooting this. Thanks!

2 2

4.1.8: Run Once does not allow me to choose a CD Image to attach
by Derek Atkins 18 Jan '18

18 Jan '18

Hi, I upgraded from 4.0.6 to 4.1.8. I had created a VM in 4.0.6 but had never started it nor had I ever run it before I upgraded. I then upgraded to 4.1.8 (which went very smoothly), but then I tried to use the Run Once function to boot up and attach an ISO Image. However when I select Run Once, then Boot Options, the "Attach CD" option is unchecked and wont let me select it like I could in 4.0.6. If I try to select the checkbox I see the popup flash but the box remains unchecked. Is this a bug/regression in 4.1.8? I did clear my browser cache thinking that might be it, but no, that didn't help. The only thing I could do was Edit the VM, go to Boot options, select it there (which I could do) and then choose the ISO. THEN I could run it with the CD attached. Thanks, -derek -- Derek Atkins 617-623-3745 derek(a)ihtfp.com www.ihtfp.com Computer and Internet Security Consultant

3 4

4.2.0 Unable to create VM disk from VM Portal
by Vrgotic, Marko 18 Jan '18

18 Jan '18

--_000_B536AA2E93C94EFF948B2FB02AFDD203activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydCBjb21tdW5pdHksDQoNCkkgaGF2ZSBmb2xsb3dpbmcgc2V0dXA6DQo0IHNlcnZl cnMgYXMgZ2x1c3RlcmZzIHN0b3JhZ2U6IHByb3ZpZGluZyB2b2x1bWUgMSBmb3IgSG9zdGVkRW5n aW5lIGFkIHZvbHVtZSAyIGZvciBWTSBTdG9yYWdlDQo3IEh5cGVydmlzb3JzDQpTZWxmSG9zdGVk IEVuZ2luZSA0LjIuMCBjbGVhbiBpbnN0YWxsIChub3QgYW4gdXBncmFkZSkNCg0KUHJvYmxlbToN Ck1pc3Npbmcgb3B0aW9uIHRvIGFkZC9jcmVhdGUgVk0gZGlzayBmcm9tIFZNIFBvcnRhbCAvIGV2 ZW4gYXMgQWRtaW4gdXNlci4NCkkgaGF2ZSB0cmllZCB3aXRoIEFkbWluIHN1ZXIgYW5kIGNyZWF0 aW5nIHVzZXIg4oCcVGVzdOKAnSB3dGggUG93ZXJVc2VyIHJvbGUuDQpJbiBib3RoIGNhc2VzIHRo ZXJlIGlzIG5vdCBvcHRpb24gdG8gY3JlYXRlIG9yIGF0dGFjaCBkaXNrLg0KDQpJcyB0aGUgYXBw cm9hY2ggY2hhbmdlZCBzaW5jZSA0LjIuMD8gQW0gSSBtaXNzaW5nIGEgc2V0dGluZz8NClBsZWFz ZSBsZXQgbWUga25vdywgSSB3aWxsIHByb3ZpZGUgbW9yZSBkYXRhIGlmIG5lZWRlZC4NCg0KS2lu ZGx5IGF3YWl0aW5nIHlvdXIgcmVwbHkuDQoNCi0tDQpNZXQgdnJpZW5kZWxpamtlIGdyb2V0IC8g QmVzdCByZWdhcmRzLA0KTWFya28gVnJnb3RpYw0KU3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVyIENh cmUNCg0K --_000_B536AA2E93C94EFF948B2FB02AFDD203activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4BE36FEDD7A7564FA55EC61B84810D36(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5h bWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgb1Zp cnQgY29tbXVuaXR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SSBoYXZlIGZvbGxvd2luZyBzZXR1cDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+NCBzZXJ2ZXJzIGFzIGds dXN0ZXJmcyBzdG9yYWdlOiBwcm92aWRpbmcgdm9sdW1lIDEgZm9yIEhvc3RlZEVuZ2luZSBhZCB2 b2x1bWUgMiBmb3IgVk0gU3RvcmFnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij43IEh5cGVydmlzb3JzIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5TZWxmSG9zdGVkIEVuZ2luZSA0LjIuMCBjbGVhbiBpbnN0YWxsIChu b3QgYW4gdXBncmFkZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlByb2JsZW06PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1pc3Npbmcgb3B0aW9uIHRvIGFkZC9jcmVhdGUg Vk0gZGlzayBmcm9tIFZNIFBvcnRhbCAvIGV2ZW4gYXMgQWRtaW4gdXNlci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+SSBoYXZlIHRyaWVkIHdpdGggQWRtaW4gc3VlciBhbmQgY3JlYXRpbmcgdXNlciDigJxU ZXN04oCdIHd0aCBQb3dlclVzZXIgcm9sZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW4gYm90aCBjYXNl cyB0aGVyZSBpcyBub3Qgb3B0aW9uIHRvIGNyZWF0ZSBvciBhdHRhY2ggZGlzay48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklzIHRoZSBhcHByb2FjaCBjaGFuZ2Vk IHNpbmNlIDQuMi4wPyBBbSBJIG1pc3NpbmcgYSBzZXR0aW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Q bGVhc2UgbGV0IG1lIGtub3csIEkgd2lsbCBwcm92aWRlIG1vcmUgZGF0YSBpZiBuZWVkZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5LaW5kbHkgYXdhaXRpbmcg eW91ciByZXBseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0IiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPk1hcmtvIFZyZ290aWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjaztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+U3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVyIENhcmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B536AA2E93C94EFF948B2FB02AFDD203activevideocom_--

3 5

All in one adds host failure
by Pym 18 Jan '18

18 Jan '18

------=_Part_123075_1879919599.1516186973359 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGk6CgoKSSdtIGRvaW5nIG92aXJ0IGFsbCBpbiBvbmUuIEkgZmlyc3QgdXNlZCB0aGUgaXNvIG9m IG5vZGUgdG8gZG8gdGhlIGJhc2ljIGVudmlyb25tZW50LCBhbmQgdGhlbiBJIGRpZCB0aGUgc291 cmNlIGNvbXBpbGF0aW9uIGFuZCBpbnN0YWxsYXRpb24gb3ZpcnQgb24gdGhlIG5vZGUgZW52aXJv bm1lbnQuIFdoZW4gSSBhZGQgYSBOZXcgSG9zdCB0byB0aGUgd2ViIGludGVyZmFjZSBIb3N0LSA+ TmV3LCBpbiB0aGUgbG9nOiBBbnNpYmxlIHBsYXlib29rIGNvbW1hbmQgaGFzIGV4aXRlZCB3aXRo IHZhbHVlOiAxLCB0aGVuIEhvc3QgaW5zdGFsbGF0aW9uIGZhaWxlZC4KCgpUaGUgbG9ncyBhcmUg YXMgZm9sbG93czoKCgplbmdpbmUubG9nOgoiMjAxOC0wMS0wNSAxNDo0OTozMiw0NDUrMDggSU5G TyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9rZXIuYXVkaXRsb2doYW5kbGluZy5B dWRpdExvZ0RpcmVjdG9yXSAoVmRzRGVwbG95KSBbNzhjNmE5Y2ItZWNjNS00ZTQ0LTkzNjYtMTM5 NjBlZjA0NTU5XSBFVkVOVF9JRDogVkRTX0lOU1RBTExfSU5fUFJPR1JFU1MoNTA5KSwgSW5zdGFs bGluZyBIb3N0IHRjaHlwLXRlc3QuZWNyLmNvbS4gU3RhZ2U6IFRlcm1pbmF0aW9uLgoyMDE4LTAx LTA1IDE0OjQ5OjMyLDUwNiswOCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJy b2tlci5hdWRpdGxvZ2hhbmRsaW5nLkF1ZGl0TG9nRGlyZWN0b3JdIChFRS1NYW5hZ2VkVGhyZWFk RmFjdG9yeS1lbmdpbmUtVGhyZWFkLTEyKSBbNzhjNmE5Y2ItZWNjNS00ZTQ0LTkzNjYtMTM5NjBl ZjA0NTU5XSBFVkVOVF9JRDogVkRTX0FOU0lCTEVfSU5TVEFMTF9TVEFSVEVEKDU2MCksIEFuc2li bGUgaG9zdC1kZXBsb3kgcGxheWJvb2sgZXhlY3V0aW9uIGhhcyBzdGFydGVkIG9uIGhvc3QgdGNo eXAtdGVzdC5lY3IuY29tLgoyMDE4LTAxLTA1IDE0OjQ5OjMyLDUwNyswOCBJTkZPICBbb3JnLm92 aXJ0LmVuZ2luZS5jb3JlLmNvbW1vbi51dGlscy5hbnNpYmxlLkFuc2libGVFeGVjdXRvcl0gKEVF LU1hbmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZS1UaHJlYWQtMTIpIFs3OGM2YTljYi1lY2M1LTRl NDQtOTM2Ni0xMzk2MGVmMDQ1NTldIEV4ZWN1dGluZyBBbnNpYmxlIGNvbW1hbmQ6IC91c3IvYmlu L2Fuc2libGUtcGxheWJvb2sgLS1wcml2YXRlLWtleT0vaG9tZS9wYW4vb3ZpcnQtZW5naW5lL2V0 Yy9wa2kvb3ZpcnQtZW5naW5lL2tleXMvZW5naW5lX2lkX3JzYSAtLWludmVudG9yeT0vdG1wL2Fu c2libGUtaW52ZW50b3J5NDc3Nzg5MTU4Mjg1NTI2Nzg1NSAtLWV4dHJhLXZhcnM9aG9zdF9kZXBs b3lfY2x1c3Rlcl92ZXJzaW9uPTQuMiAtLWV4dHJhLXZhcnM9aG9zdF9kZXBsb3lfZ2x1c3Rlcl9l bmFibGVkPWZhbHNlIC0tZXh0cmEtdmFycz1ob3N0X2RlcGxveV92aXJ0X2VuYWJsZWQ9dHJ1ZSAt LWV4dHJhLXZhcnM9aG9zdF9kZXBsb3lfdmRzbV9wb3J0PTU0MzIxIC0tZXh0cmEtdmFycz1ob3N0 X2RlcGxveV9vdmVycmlkZV9maXJld2FsbD10cnVlIC0tZXh0cmEtdmFycz1ob3N0X2RlcGxveV9m aXJld2FsbF90eXBlPUZJUkVXQUxMRCAtLWV4dHJhLXZhcnM9YW5zaWJsZV9wb3J0PTIyIC0tZXh0 cmEtdmFycz1ob3N0X2RlcGxveV9wb3N0X3Rhc2tzPS9ob21lL3Bhbi9vdmlydC1lbmdpbmUvZXRj L292aXJ0LWVuZ2luZS9hbnNpYmxlL292aXJ0LWhvc3QtZGVwbG95LXBvc3QtdGFza3MueW1sIC0t ZXh0cmEtdmFycz1ob3N0X2RlcGxveV9vdm5fdHVubmVsaW5nX2ludGVyZmFjZT0xMjcuMC4wLjEg LS1leHRyYS12YXJzPWhvc3RfZGVwbG95X292bl9jZW50cmFsPW51bGwgL2hvbWUvcGFuL292aXJ0 LWVuZ2luZS9zaGFyZS9vdmlydC1lbmdpbmUvcGxheWJvb2tzL292aXJ0LWhvc3QtZGVwbG95Lnlt bAoyMDE4LTAxLTA1IDE0OjQ5OjMyLDc4OCswOCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LmNvbW1vbi51dGlscy5hbnNpYmxlLkFuc2libGVFeGVjdXRvcl0gKEVFLU1hbmFnZWRUaHJlYWRG YWN0b3J5LWVuZ2luZS1UaHJlYWQtMTIpIFs3OGM2YTljYi1lY2M1LTRlNDQtOTM2Ni0xMzk2MGVm MDQ1NTldIEFuc2libGUgcGxheWJvb2sgY29tbWFuZCBoYXMgZXhpdGVkIHdpdGggdmFsdWU6IDEK MjAxOC0wMS0wNSAxNDo0OTozMiw3OTIrMDggRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS5i bGwuaG9zdGRlcGxveS5JbnN0YWxsVmRzSW50ZXJuYWxDb21tYW5kXSAoRUUtTWFuYWdlZFRocmVh ZEZhY3RvcnktZW5naW5lLVRocmVhZC0xMikgWzc4YzZhOWNiLWVjYzUtNGU0NC05MzY2LTEzOTYw ZWYwNDU1OV0gSG9zdCBpbnN0YWxsYXRpb24gZmFpbGVkIGZvciBob3N0ICdkYmVmYTU4Yi0zZWUy LTQzOWItOGU5Zi03ZWNlNTcxYWJlMzInLCAndGNoeXAtdGVzdC5lY3IuY29tJzogMjUwCjIwMTgt MDEtMDUgMTQ6NDk6MzIsNzk2KzA4IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJv a2VyLlNldFZkc1N0YXR1c1ZEU0NvbW1hbmRdIChFRS1NYW5hZ2VkVGhyZWFkRmFjdG9yeS1lbmdp bmUtVGhyZWFkLTEyKSBbNzhjNmE5Y2ItZWNjNS00ZTQ0LTkzNjYtMTM5NjBlZjA0NTU5XSBTVEFS VCwgU2V0VmRzU3RhdHVzVkRTQ29tbWFuZChIb3N0TmFtZSA9IHRjaHlwLXRlc3QuZWNyLmNvbSwg U2V0VmRzU3RhdHVzVkRTQ29tbWFuZFBhcmFtZXRlcnM6e2hvc3RJZD0nZGJlZmE1OGItM2VlMi00 MzliLThlOWYtN2VjZTU3MWFiZTMyJywgc3RhdHVzPSdJbnN0YWxsRmFpbGVkJywgbm9uT3BlcmF0 aW9uYWxSZWFzb249J05PTkUnLCBzdG9wU3BtRmFpbHVyZUxvZ2dlZD0nZmFsc2UnLCBtYWludGVu YW5jZVJlYXNvbj0nbnVsbCd9KSwgbG9nIGlkOiBhZjBiOGQxCjIwMTgtMDEtMDUgMTQ6NDk6MzIs ODAzKzA4IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlNldFZkc1N0YXR1 c1ZEU0NvbW1hbmRdIChFRS1NYW5hZ2VkVGhyZWFkRmFjdG9yeS1lbmdpbmUtVGhyZWFkLTEyKSBb NzhjNmE5Y2ItZWNjNS00ZTQ0LTkzNjYtMTM5NjBlZjA0NTU5XSBGSU5JU0gsIFNldFZkc1N0YXR1 c1ZEU0NvbW1hbmQsIGxvZyBpZDogYWYwYjhkMQoyMDE4LTAxLTA1IDE0OjQ5OjMyLDgwOSswOCBF UlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5hdWRpdGxvZ2hhbmRsaW5n LkF1ZGl0TG9nRGlyZWN0b3JdIChFRS1NYW5hZ2VkVGhyZWFkRmFjdG9yeS1lbmdpbmUtVGhyZWFk LTEyKSBbNzhjNmE5Y2ItZWNjNS00ZTQ0LTkzNjYtMTM5NjBlZjA0NTU5XSBFVkVOVF9JRDogVkRT X0lOU1RBTExfRkFJTEVEKDUwNSksIEhvc3QgdGNoeXAtdGVzdC5lY3IuY29tIGluc3RhbGxhdGlv biBmYWlsZWQuIDI1MC4iCgoKb3ZpcnQtaG9zdC1kZXBsb3ktYW5zaWJsZS0yMDE4MDEwNTE0NDkz Mi0xMjcuMC4wLjEtNzhjNmE5Y2ItZWNjNS00ZTQ0LTkzNjYtMTM5NjBlZjA0NTU5LmxvZzoKIkVS Uk9SISBVbmV4cGVjdGVkIEV4Y2VwdGlvbjogW0Vycm5vIDEzXSBQZXJtaXNzaW9uIGRlbmllZAp0 byBzZWUgdGhlIGZ1bGwgdHJhY2ViYWNrLCB1c2UgLXZ2diIKCgpXaGF0IGFtIEkgZ29pbmcgdG8g ZG8gbm93IHRvIGFkZCBob3N0IHN1Y2Nlc3M/CgoKVGhhbmtzLgoK ------=_Part_123075_1879919599.1516186973359 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+PGRpdj5IaTo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PkknbSBkb2luZyBvdmlydCBhbGwgaW4gb25lLiBJIGZpcnN0IHVzZWQgdGhlIGlzbyBvZiBub2Rl IHRvIGRvIHRoZSBiYXNpYyBlbnZpcm9ubWVudCwgYW5kIHRoZW4gSSBkaWQgdGhlIHNvdXJjZSBj b21waWxhdGlvbiBhbmQgaW5zdGFsbGF0aW9uIG92aXJ0IG9uIHRoZSBub2RlIGVudmlyb25tZW50 LiBXaGVuIEkgYWRkIGEgTmV3IEhvc3QgdG8gdGhlIHdlYiBpbnRlcmZhY2UgSG9zdC0gJmd0O05l dywgaW4gdGhlIGxvZzogQW5zaWJsZSBwbGF5Ym9vayBjb21tYW5kIGhhcyBleGl0ZWQgd2l0aCB2 YWx1ZTogMSwgdGhlbiBIb3N0IGluc3RhbGxhdGlvbiBmYWlsZWQuPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5UaGUgbG9ncyBhcmUgYXMgZm9sbG93czo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PmVuZ2luZS5sb2c6PC9kaXY+PC9kaXY+PGRpdj48ZGl2PiIyMDE4LTAxLTA1IDE0OjQ5OjMyLDQ0 NSswOCBJTkZPJm5ic3A7IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1ZGl0 bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKFZkc0RlcGxveSkgWzc4YzZhOWNiLWVjYzUt NGU0NC05MzY2LTEzOTYwZWYwNDU1OV0gRVZFTlRfSUQ6IFZEU19JTlNUQUxMX0lOX1BST0dSRVNT KDUwOSksIEluc3RhbGxpbmcgSG9zdCB0Y2h5cC10ZXN0LmVjci5jb20uIFN0YWdlOiBUZXJtaW5h dGlvbi48L2Rpdj48ZGl2PjIwMTgtMDEtMDUgMTQ6NDk6MzIsNTA2KzA4IElORk8mbmJzcDsgW29y Zy5vdmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9rZXIuYXVkaXRsb2doYW5kbGluZy5BdWRpdExv Z0RpcmVjdG9yXSAoRUUtTWFuYWdlZFRocmVhZEZhY3RvcnktZW5naW5lLVRocmVhZC0xMikgWzc4 YzZhOWNiLWVjYzUtNGU0NC05MzY2LTEzOTYwZWYwNDU1OV0gRVZFTlRfSUQ6IFZEU19BTlNJQkxF X0lOU1RBTExfU1RBUlRFRCg1NjApLCBBbnNpYmxlIGhvc3QtZGVwbG95IHBsYXlib29rIGV4ZWN1 dGlvbiBoYXMgc3RhcnRlZCBvbiBob3N0IHRjaHlwLXRlc3QuZWNyLmNvbS48L2Rpdj48ZGl2PjIw MTgtMDEtMDUgMTQ6NDk6MzIsNTA3KzA4IElORk8mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29y ZS5jb21tb24udXRpbHMuYW5zaWJsZS5BbnNpYmxlRXhlY3V0b3JdIChFRS1NYW5hZ2VkVGhyZWFk RmFjdG9yeS1lbmdpbmUtVGhyZWFkLTEyKSBbNzhjNmE5Y2ItZWNjNS00ZTQ0LTkzNjYtMTM5NjBl ZjA0NTU5XSBFeGVjdXRpbmcgQW5zaWJsZSBjb21tYW5kOiAvdXNyL2Jpbi9hbnNpYmxlLXBsYXli b29rIC0tcHJpdmF0ZS1rZXk9L2hvbWUvcGFuL292aXJ0LWVuZ2luZS9ldGMvcGtpL292aXJ0LWVu Z2luZS9rZXlzL2VuZ2luZV9pZF9yc2EgLS1pbnZlbnRvcnk9L3RtcC9hbnNpYmxlLWludmVudG9y eTQ3Nzc4OTE1ODI4NTUyNjc4NTUgLS1leHRyYS12YXJzPWhvc3RfZGVwbG95X2NsdXN0ZXJfdmVy c2lvbj00LjIgLS1leHRyYS12YXJzPWhvc3RfZGVwbG95X2dsdXN0ZXJfZW5hYmxlZD1mYWxzZSAt LWV4dHJhLXZhcnM9aG9zdF9kZXBsb3lfdmlydF9lbmFibGVkPXRydWUgLS1leHRyYS12YXJzPWhv c3RfZGVwbG95X3Zkc21fcG9ydD01NDMyMSAtLWV4dHJhLXZhcnM9aG9zdF9kZXBsb3lfb3ZlcnJp ZGVfZmlyZXdhbGw9dHJ1ZSAtLWV4dHJhLXZhcnM9aG9zdF9kZXBsb3lfZmlyZXdhbGxfdHlwZT1G SVJFV0FMTEQgLS1leHRyYS12YXJzPWFuc2libGVfcG9ydD0yMiAtLWV4dHJhLXZhcnM9aG9zdF9k ZXBsb3lfcG9zdF90YXNrcz0vaG9tZS9wYW4vb3ZpcnQtZW5naW5lL2V0Yy9vdmlydC1lbmdpbmUv YW5zaWJsZS9vdmlydC1ob3N0LWRlcGxveS1wb3N0LXRhc2tzLnltbCAtLWV4dHJhLXZhcnM9aG9z dF9kZXBsb3lfb3ZuX3R1bm5lbGluZ19pbnRlcmZhY2U9MTI3LjAuMC4xIC0tZXh0cmEtdmFycz1o b3N0X2RlcGxveV9vdm5fY2VudHJhbD1udWxsIC9ob21lL3Bhbi9vdmlydC1lbmdpbmUvc2hhcmUv b3ZpcnQtZW5naW5lL3BsYXlib29rcy9vdmlydC1ob3N0LWRlcGxveS55bWw8L2Rpdj48ZGl2PjIw MTgtMDEtMDUgMTQ6NDk6MzIsNzg4KzA4IElORk8mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29y ZS5jb21tb24udXRpbHMuYW5zaWJsZS5BbnNpYmxlRXhlY3V0b3JdIChFRS1NYW5hZ2VkVGhyZWFk RmFjdG9yeS1lbmdpbmUtVGhyZWFkLTEyKSBbNzhjNmE5Y2ItZWNjNS00ZTQ0LTkzNjYtMTM5NjBl ZjA0NTU5XSBBbnNpYmxlIHBsYXlib29rIGNvbW1hbmQgaGFzIGV4aXRlZCB3aXRoIHZhbHVlOiAx PC9kaXY+PGRpdj4yMDE4LTAxLTA1IDE0OjQ5OjMyLDc5MiswOCBFUlJPUiBbb3JnLm92aXJ0LmVu Z2luZS5jb3JlLmJsbC5ob3N0ZGVwbG95Lkluc3RhbGxWZHNJbnRlcm5hbENvbW1hbmRdIChFRS1N YW5hZ2VkVGhyZWFkRmFjdG9yeS1lbmdpbmUtVGhyZWFkLTEyKSBbNzhjNmE5Y2ItZWNjNS00ZTQ0 LTkzNjYtMTM5NjBlZjA0NTU5XSBIb3N0IGluc3RhbGxhdGlvbiBmYWlsZWQgZm9yIGhvc3QgJ2Ri ZWZhNThiLTNlZTItNDM5Yi04ZTlmLTdlY2U1NzFhYmUzMicsICd0Y2h5cC10ZXN0LmVjci5jb20n OiAyNTA8L2Rpdj48ZGl2PjIwMTgtMDEtMDUgMTQ6NDk6MzIsNzk2KzA4IElORk8mbmJzcDsgW29y Zy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuU2V0VmRzU3RhdHVzVkRTQ29tbWFuZF0gKEVF LU1hbmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZS1UaHJlYWQtMTIpIFs3OGM2YTljYi1lY2M1LTRl NDQtOTM2Ni0xMzk2MGVmMDQ1NTldIFNUQVJULCBTZXRWZHNTdGF0dXNWRFNDb21tYW5kKEhvc3RO YW1lID0gdGNoeXAtdGVzdC5lY3IuY29tLCBTZXRWZHNTdGF0dXNWRFNDb21tYW5kUGFyYW1ldGVy czp7aG9zdElkPSdkYmVmYTU4Yi0zZWUyLTQzOWItOGU5Zi03ZWNlNTcxYWJlMzInLCBzdGF0dXM9 J0luc3RhbGxGYWlsZWQnLCBub25PcGVyYXRpb25hbFJlYXNvbj0nTk9ORScsIHN0b3BTcG1GYWls dXJlTG9nZ2VkPSdmYWxzZScsIG1haW50ZW5hbmNlUmVhc29uPSdudWxsJ30pLCBsb2cgaWQ6IGFm MGI4ZDE8L2Rpdj48ZGl2PjIwMTgtMDEtMDUgMTQ6NDk6MzIsODAzKzA4IElORk8mbmJzcDsgW29y Zy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuU2V0VmRzU3RhdHVzVkRTQ29tbWFuZF0gKEVF LU1hbmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZS1UaHJlYWQtMTIpIFs3OGM2YTljYi1lY2M1LTRl NDQtOTM2Ni0xMzk2MGVmMDQ1NTldIEZJTklTSCwgU2V0VmRzU3RhdHVzVkRTQ29tbWFuZCwgbG9n IGlkOiBhZjBiOGQxPC9kaXY+PC9kaXY+PGRpdj48ZGl2PjIwMTgtMDEtMDUgMTQ6NDk6MzIsODA5 KzA4IEVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1ZGl0bG9naGFu ZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKEVFLU1hbmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZS1U aHJlYWQtMTIpIFs3OGM2YTljYi1lY2M1LTRlNDQtOTM2Ni0xMzk2MGVmMDQ1NTldIEVWRU5UX0lE OiBWRFNfSU5TVEFMTF9GQUlMRUQoNTA1KSwgSG9zdCB0Y2h5cC10ZXN0LmVjci5jb20gaW5zdGFs bGF0aW9uIGZhaWxlZC4gMjUwLiI8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pm92aXJ0 LWhvc3QtZGVwbG95LWFuc2libGUtMjAxODAxMDUxNDQ5MzItMTI3LjAuMC4xLTc4YzZhOWNiLWVj YzUtNGU0NC05MzY2LTEzOTYwZWYwNDU1OS5sb2c6PC9kaXY+PGRpdj48ZGl2PiJFUlJPUiEgVW5l eHBlY3RlZCBFeGNlcHRpb246IFtFcnJubyAxM10gUGVybWlzc2lvbiBkZW5pZWQ8L2Rpdj48ZGl2 PnRvIHNlZSB0aGUgZnVsbCB0cmFjZWJhY2ssIHVzZSAtdnZ2IjwvZGl2PjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+V2hhdCBhbSBJIGdvaW5nIHRvIGRvIG5vdyB0byBhZGQgaG9zdCBzdWNjZXNz PzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzLjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjwv ZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxwPiZuYnNwOzwvcD48L3Nw YW4+ ------=_Part_123075_1879919599.1516186973359--

1 0

Ovirt 4.2 Windows guest tools
by Alex K 18 Jan '18

18 Jan '18

Hi all, Is the ISO at http://plain.resources.ovirt.org/pub/ovirt-4.2/iso/oVirt-toolsSetup/4.2-1.e… the latest guest tools? I'm interested for Windows 2016 and Windows 10. Thanx, Alex

2 2

Ovirt 4.2 Bug with Permissons on the Vm Portal?
by Thomas Fecke 17 Jan '18

17 Jan '18

--_000_29f4cad202e140c1bb149e33fd16af23DR1XEXCH02Besetcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Guys, i recently upgrade to 4.2 We used the User Portal before. Every User could see his VM=B4s, every Admi= n just could see his VM=B4s ( User View ). After the Update: Admin=B4s can see every VM in VM Portal The Users can=B4t see Vm=B4s anymore. The Portal is Empty. Role "UserVMMana= ger" is set. We tested some Scenarios: If the User create a new Virtual Machine, it is s= hown in the VM Portal. When he log out and in again -> VM is gone in his Vi= ew Admin View: The VM was created, Permission where set. Everything seems to b= e good. Any Ideas? Thanks Guys --_000_29f4cad202e140c1bb149e33fd16af23DR1XEXCH02Besetcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <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"> <p class=3D"MsoNormal"><span lang=3D"DE">Hello Guys,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE">i recently upgrade to 4.2<o:p></o:= p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE"><o:p> </o:p></span></p> <p class=3D"MsoNormal">We used the User Portal before. Every User could see= his<u> </u> VM=B4s, every Admin just could see his VM=B4s ( User View ).<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">After the Update:<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Admin=B4s can see every VM in VM Portal<o:p></o:p></= p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">The Users can=B4t see Vm=B4s anymore. The Portal is = Empty. Role “UserVMManager” is set.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">We tested some Scenarios: If the User create a new V= irtual Machine, it is shown in the VM Portal. When he log out and in again = -> VM is gone in his View<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Admin View: The VM was created, Permission where set= . Everything seems to be good.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Any Ideas? Thanks Guys<u><o:p></o:p></u></p> </div> </body> </html> --_000_29f4cad202e140c1bb149e33fd16af23DR1XEXCH02Besetcorp_--

4 5

Is there a way to rename the hosted engine VM name (not hostname)
by Jayme 17 Jan '18

17 Jan '18

Our oVirt environment was originally setup by someone else. The hosted engine VM has a custom name, but it seems to me like some of the hosted-engine tools such as hosted-engine --console for example expect the domain to be "HostedEngine'. I tried renaming it in the admin interface but changes are locked for the hostedengine VM. Is there a way that I can change the domain of the VM back to HostedEngine instead of the custom name?

1 0

[ANN] oVirt 4.1.9 Second Release Candidate is now available
by Lev Veyde 17 Jan '18

17 Jan '18

The oVirt Project is pleased to announce the availability of the oVirt 4.1.9 RC2 release, as of January 17th, 2017 This update is the ninth in a series of stabilization updates to the 4.1 series. This release is available now for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.1 See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Live is already available [2] - oVirt Node will be available soon [2] Additional Resources: * Read more about the oVirt 4.1.9 release highlights: http://www.ovirt.org/release/4.1.9/ * 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] http://www.ovirt.org/release/4.1.9/ [2] http://resources.ovirt.org/pub/ovirt-4.1-pre/iso/ -- Lev Veyde Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

[solved] Error while upgrading engine from 4.1.8 to 4.2
by Luca 'remix_tj' Lorenzetto 17 Jan '18

17 Jan '18

Hello, i just completed the upgrade of my engine appliance from 4.1.8 to 4.2.0.1. I would like to share the only error i've encountered while upgrading and running engine-setup: [ INFO ] Creating/refreshing Engine database schema [ ERROR ] schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql [ ERROR ] Failed to execute stage 'Misc configuration': Engine schema refresh failed After some search i found out that is an error linked to a bad configuration of one (or more) vm having "Memory Size" value set with an higher value than "Maximum Memory". In my case the vm with that error was HostedEngine. Editing the vm configuration by setting an appropriate value allowed me to run again engine-setup with success. Luca -- "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 4

oVirt 4.2: hostdev passthrough noop
by Daniel Helgenberger 17 Jan '18

17 Jan '18

Hello, yesterday I upgraded to 4.2 from 4.1.8. Now I notice I cannot assign host dev pass though any more; in the GUI the 'Pinnded to host' list is empty. The hostdev from before the upgrades are still present. I tried to remove them and got an NPE (see below). Has anyone an idea? ----------------------- > 2018-01-17 11:37:51,035+01 INFO [org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand] (default task-48) [57a8c14d-fc2c-4846-bc3d-cc4f3e8393f8] Running command: RemoveVmHostDevicesCommand internal: false. Entities affected : ID: 6132322b-e187-4a83-b8c1-0477bde10497 Type: VMAction group EDIT_ADMIN_VM_PROPERTIES with role type ADMIN > 2018-01-17 11:37:51,037+01 ERROR [org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand] (default task-48) [57a8c14d-fc2c-4846-bc3d-cc4f3e8393f8] Command 'org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand' failed: null > 2018-01-17 11:37:51,037+01 ERROR [org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand] (default task-48) [57a8c14d-fc2c-4846-bc3d-cc4f3e8393f8] Exception: java.lang.NullPointerException > at org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand.executeCommand(RemoveVmHostDevicesCommand.java:64) [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1205) [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1345) [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1987) [bll.jar:] > at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:202) [utils.jar:] > at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInRequired(TransactionSupport.java:137) [utils.jar:] > at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:105) [utils.jar:] > at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1405) [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:412) [bll.jar:] > at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] > at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:509) [bll.jar:] > at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:491) [bll.jar:] > at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:444) [bll.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_151] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_151] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] > at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:92) [wildfly-weld-ejb-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.weld.interceptor.proxy.WeldInvocationContext.interceptorChainCompleted(WeldInvocationContext.java:98) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] > at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:117) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] > at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] > at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) [:1.8.0_151] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] > at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] > at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] > at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] > at org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:108) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] > at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:82) [wildfly-weld-ejb-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.as.weld.interceptors.EjbComponentInterceptorSupport.delegateInterception(EjbComponentInterceptorSupport.java:60) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:76) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:88) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] > at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source) [:1.8.0_151] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] > at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] > at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:264) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:379) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:244) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) > at org.ovirt.engine.core.common.interfaces.BackendLocal$$$view4.runAction(Unknown Source) [common.jar:] > at org.ovirt.engine.ui.frontend.server.gwt.GenericApiGWTServiceImpl.runAction(GenericApiGWTServiceImpl.java:176) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_151] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_151] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] > at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] > at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:587) > at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:333) > at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:303) > at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:373) > at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.ovirt.engine.ui.frontend.server.gwt.GenericApiGWTServiceImpl.service(GenericApiGWTServiceImpl.java:78) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at org.ovirt.engine.core.utils.servlet.HeaderFilter.doFilter(HeaderFilter.java:94) [utils.jar:] > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at org.ovirt.engine.core.utils.servlet.CachingFilter.doFilter(CachingFilter.java:133) [utils.jar:] > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at org.ovirt.engine.core.branding.BrandingFilter.doFilter(BrandingFilter.java:73) [branding.jar:] > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at org.ovirt.engine.core.utils.servlet.LocaleFilter.doFilter(LocaleFilter.java:65) [utils.jar:] > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_151] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151] > at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151] > > 2018-01-17 11:37:51,049+01 ERROR [org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand] (default task-48) [57a8c14d-fc2c-4846-bc3d-cc4f3e8393f8] Transaction rolled-back for command 'org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand'. > 2018-01-17 11:37:51,059+01 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-48) [57a8c14d-fc2c-4846-bc3d-cc4f3e8393f8] EVENT_ID: VM_REMOVE_HOST_DEVICES(10,801), Host devices [usb_4_10] were detached from Vm license2.int.lugundtrug.net by User admin@internal-authz.

1 0

oVirt 2018 Survey
by Sandro Bonazzola 17 Jan '18

17 Jan '18

As we continue to develop oVirt 4.2 and future releases, the Development and Integration teams at Red Hat would value insights on how you are deploying the oVirt environment. Please help us to hit the mark by completing this short survey. Survey will close on February 1st. Here's the link to the survey: https://goo.gl/forms/cAKWAR8RD7rGrVhE2 Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

5 5

oVirt 4.2.1 rc1 and upload iso to data domain test
by Gianluca Cecchi 17 Jan '18

17 Jan '18

Hello, I see in release notes this BZ 1530730 [downstream clone - 4.2.1] [RFE] Allow uploading ISO images to data domains and using them in VMs It is now possible to upload an ISO file to a data domain and attach it to a VM as a CDROM device. In order to do so the user has to upload an ISO file via the UI (which will recognize the ISO by it's header and will upload it as ISO) or via the APIs in which case the request should define the disk container "content_type" property as "iso" before the upload. Once the ISO exists on an active storage domain in the data center it will be possible to attach it to a VM as a CDROM device either through the "Edit VM" dialog or through the APIs (see example in comment #27 So I'm trying it on an HCI Gluster environment of mine for testing. I get this in image-proxy.log (Thread-39 ) INFO 2018-01-14 18:35:38,066 web:95:web:(log_start) START [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701 (Thread-39 ) WARNING 2018-01-14 18:35:38,067 web:112:web:(log_error) ERROR [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701: [401] Not authorized (0.00s) (Thread-40 ) INFO 2018-01-14 18:35:38,106 web:95:web:(log_start) START [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701 (Thread-40 ) WARNING 2018-01-14 18:35:38,106 web:112:web:(log_error) ERROR [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701: [401] Not authorized (0.00s) Does this mean the functionality is not completely ready yet or what? Any one has already tried on iSCSI and/or FC? Thanks, Gianluca

2 6

Problems with some vms
by Endre Karlson 17 Jan '18

17 Jan '18

Hi, we are getting some errors with some of our vms in a 3 node server setup. 2018-01-14 15:01:44,015+0100 INFO (libvirt/events) [virt.vm] (vmId='2c34f52d-140b-4dbe-a4bd-d2cb467b0b7c') abnormal vm stop device virtio-disk0 error eother (vm:4880) We are running glusterfs for shared storage. I have tried setting global maintenance on the first server and then issuing a 'hosted-engine --vm-start' but that leads to nowhere.

3 7

oVirt 4.x - RestAPI - Backup - How to Image Inactive Disk
by Zip 16 Jan '18

16 Jan '18

> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3598954007_92574425 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi All, I have created a bash script that uses curl and the REST API based on the docs that I could find. I have the script working all the way up until the VM-ToBeBackedUp-Disk is attached to the VM-RunningTheBackupScript with the mention of the Snapshot. Example: <disk_attachment> <disk id=3D"33b533f8-13b1-4cc1-8091-31b07913b32a"> <snapshot id=3D"34709147-4b0c-4684-b3d9-f4892873f36f=B2/> </disk> <bootable>false</bootable> <interface>virtio</interface> </disk_attachment> Posted to :=20 https://-myFQDN-/ovirt-engine/api/vms/-UUID-OF-VM-RunningTheBackupScript/di= s kattachments/ The above results in an attached disk to my VM-RunningTheBackupScript. The question I have is how to I image that disk from the VM-RunningTheBackupScript? The VM-RunningTheBackupScript is running Debian8 and that VM cannot see the attached disk as it is Inactive. I have reviewed many of the older scripts out there and it looks trivial, however everything I have tried has no joy ;/ If anyone on the list knows of the required magic, please advise ;) * If I have to go to using python etc, I will, but trying to avoid it if possible. Either way, I need some examples of how to proceed. Some links I have reviewed: https://www.ovirt.org/develop/api/design/backup-api/ http://200.1.19.60/ovirt-engine/docs/manual/en-US/html/Administration_Guide= / sect-Backing_Up_and_Restoring_Virtual_Machines_Using_the_Backup_and_Restore= _ API.html https://markmc.fedorapeople.org/rhevm-api/en-US/html-single/index.html https://github.com/voidloop/ovirt-bash-backup/blob/master/backupvm.sh https://github.com/laravot/backuprestoreapi/blob/master/example.py Thanks Zip --B_3598954007_92574425 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s= pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:= 14px; font-family: Calibri, sans-serif;"><div>Hi All,</div><div><br></div><= div>I have created a bash script that uses curl and the REST API based on th= e docs that I could find. </div><div><br></div><div>I have the script w= orking all the way up until the VM-ToBeBackedUp-Disk is attached to the VM-R= unningTheBackupScript with the mention of the Snapshot.</div><div><br></div>= <div>Example:</div><div><br></div><div><div><disk_attachment></div><di= v>    <disk id=3D"33b533f8-13b1-4cc1-8091-31b07913b32a"></div>= <div>       <snapshot id=3D"34709147-4b0c-4684-b3d9-f48= 92873f36f”/></div><div>    </disk></div><div> =   <bootable>false</bootable></div><div>    <i= nterface>virtio</interface></div><div></disk_attachment></div= ></div><div><br></div><div>Posted to : <a href=3D"https://-myFQDN-/ovirt-= engine/api/vms/-UUID-OF-VM-RunningTheBackupScript/diskattachments">https://-= myFQDN-/ovirt-engine/api/vms/-UUID-OF-VM-RunningTheBackupScript/diskattachme= nts</a>/</div><div><br></div><div>The above results in an attached disk to m= y VM-RunningTheBackupScript.</div><div><br></div><div>The question I have is= how to I image that disk from the VM-RunningTheBackupScript?</div><div><br>= </div><div>The VM-RunningTheBackupScript is running Debian8 and that VM cann= ot see the attached disk as it is Inactive.</div><div><br></div><div>I have = reviewed many of the older scripts out there and it looks trivial, however e= verything I have tried has no joy ;/</div><div><br></div><div>If anyone on t= he list knows of the required magic, please advise ;)</div><div><br></div><d= iv>* If I have to go to using python etc, I will, but trying to avoid it if = possible. Either way, I need some examples of how to proceed.</div><div><br>= </div><div>Some links I have reviewed:</div><div><br></div><div><a href=3D"htt= ps://www.ovirt.org/develop/api/design/backup-api">https://www.ovirt.org/deve= lop/api/design/backup-api</a>/</div><div><a href=3D"http://200.1.19.60/ovirt-e= ngine/docs/manual/en-US/html/Administration_Guide/sect-Backing_Up_and_Restor= ing_Virtual_Machines_Using_the_Backup_and_Restore_API.html">http://200.1.19.= 60/ovirt-engine/docs/manual/en-US/html/Administration_Guide/sect-Backing_Up_= and_Restoring_Virtual_Machines_Using_the_Backup_and_Restore_API.html</a></di= v><div><a href=3D"https://markmc.fedorapeople.org/rhevm-api/en-US/html-single/= index.html">https://markmc.fedorapeople.org/rhevm-api/en-US/html-single/inde= x.html</a></div><div><a href=3D"https://github.com/voidloop/ovirt-bash-backup/= blob/master/backupvm.sh">https://github.com/voidloop/ovirt-bash-backup/blob/= master/backupvm.sh</a></div><div><a href=3D"https://github.com/laravot/backupr= estoreapi/blob/master/example.py">https://github.com/laravot/backuprestoreap= i/blob/master/example.py</a></div><div><br></div><div><br></div><div>Thanks<= /div><div><br></div><div>Zip</div></body></html> --B_3598954007_92574425--

1 0