- Users - oVirt List Archives

New blog on ovirt.org - Build oVirt Reports Using Grafana
by Yaniv Kaul 21 Jan '18

21 Jan '18

Grafana <https://grafana.com/>, The open platform for beautiful analytics and monitoring, recently added support for PostgreSQL <http://docs.grafana.org/features/datasources/postgres/>. It in now possible to connect Grafana to oVirt DWH <https://www.ovirt.org/documentation/how-to/reports/dwh/>, in order to visualize and monitor the oVirt environment. Read more @ https://ovirt.org/blog/2018/01/ovirt-report-using-grafana/

1 0

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