- Users - oVirt List Archives

Error packages update after upgrade to ovirt 4.3
by Нон локалес 15 Feb '19

15 Feb '19

Hello. Anyone please help, cannot upgrade host, yum update going in error. https://pastebin.com/MWnsxVAa What i have done and didnt work: yum install dpdk yum clean all package-cleanup --cleandupes Its clean centos 7 with installed host role throught ovirt engine/

3 2

Vnic-Port mirroring
by ada per 15 Feb '19

15 Feb '19

Hello everyone, I am trying to allow port mirroring through the Vnic profile but no matter what i do it stays grayed out. How can i enable this option? When i am creating a new VNIC profile the options ,port mirroring and passthrough are disabled. the version i am using is 4.2.8. Thanks!:)

4 11

Re: Ovirt Cluster completely unstable
by Ryan Bullock 15 Feb '19

15 Feb '19

Just to add, after we updated to 4.3 our gluster just went south. Thankfully gluster is only secondary storage for us, and our primary storage is an ISCSI SAN. We migrated everything over to the SAN that we could, but a few VM's got corrupted by gluster (data was gone). Right now we just have gluster off and set to maintenance because the connectivity issues were causing our main cluster to continuously migrate VMs. Looking at the gluster hosts themselves I noticed that heal info would often report one brick down, even if ovirt didn't. Checking the status of glusterd would also show health checks failed. Feb 6 15:36:37 vmc3h1 glusterfs-virtstore[17036]: [2019-02-06 23:36:37.937041] M [MSGID: 113075] [posix-helpers.c:1957:posix_health_check_thread_proc] 0-VirstStore-posix: health-check failed, going down Feb 6 15:36:37 vmc3h1 glusterfs-virtstore[17036]: [2019-02-06 23:36:37.937561] M [MSGID: 113075] [posix-helpers.c:1975:posix_health_check_thread_proc] 0-VirstStore-posix: still alive! -> SIGTERM I think the health-check is failing (maybe erroneously) which is then killing the brick. When this happens it just causing a continuous cycle of brick up-down and healing, and in turn connectivity issues. This is our second time running into issues with gluster, so I think we are going to sideline it for awhile. -Ryan On Thu, Feb 14, 2019 at 12:47 PM Darryl Scott <dscott(a)umbctraining.com> wrote: > I do believe something went wrong after fully updating everything last > Friday. I updated all the ovirt compute nodes on Friday and gluster/engine > on Saturday. I have been experiencing these issues every since. I have > pour over engine.log and seems to be connection to storage issue. > > > ------------------------------ > *From:* Jayme <jaymef(a)gmail.com> > *Sent:* Thursday, February 14, 2019 1:52:59 AM > *To:* Darryl Scott > *Cc:* users > *Subject:* Re: [ovirt-users] Ovirt Cluster completely unstable > > I have a three node HCI gluster which was previously running 4.2 with zero > problems. I just upgraded it yesterday. I ran in to a few bugs right away > with the upgrade process, but aside from that I also discovered other users > with severe GlusterFS problems since the upgrade to new GlusterFS version. > It is less than 24 hours since I upgrade my cluster and I just got a notice > that one of my GlusterFS bricks is offline. There does appear to be a very > real and serious issue here with the latest updates. > > > On Wed, Feb 13, 2019 at 7:26 PM <dscott(a)umbctraining.com> wrote: > > I'm abandoning my production ovirt cluster due to instability. I have a > 7 host cluster running about 300 vms and have been for over a year. It has > become unstable over the past three days. I have random hosts both, > compute and storage disconnecting. AND many vms disconnecting and becoming > unusable. > > 7 host are 4 compute hosts running Ovirt 4.2.8 and three glusterfs hosts > running 3.12.5. I submitted a bugzilla bug and they immediately assigned > it to the storage people but have not responded with any meaningful > information. I have submitted several logs. > > I have found some discussion on problems with instability with gluster > 3.12.5. I would be willing to upgrade my gluster to a more stable version > if that's the culprit. I installed gluster using the ovirt gui and this is > the version the ovirt gui installed. > > Is there an ovirt health monitor available? Where should I be looking to > get a resolution the problems I'm facing. > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/BL4M3JQA3IEXC… > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/IMUKFFANNJXLK… >

1 0

Using the web-ui VM portal through a proxy failing
by Callum Smith 15 Feb '19

15 Feb '19

Dear oVirt Gurus, Using the oVirt user VM portal seems to not work through the squid proxy setup (configured as per the guide). The page loads and login works fine through the proxy, but the asynchronous requests just hang. I've attached a screenshot, but you can see the "api" endpoint just hanging in a web inspector: "https://proxyfqdn/ovirt-engine/api/" [cid:CA42E493-3AD9-45F8-B4C3-C914F059390C@well.ox.ac.uk] This works fine when not going through the proxy. Is there a way to force noVNC HTML as the console mode through the web-ui, or at least have it as an option if not default? The console seems not to work when logged in with a base 'user role'. Regards, Callum -- Callum Smith Research Computing Core Wellcome Trust Centre for Human Genetics University of Oxford e. callum(a)well.ox.ac.uk<mailto:callum@well.ox.ac.uk>

2 14

Create Snapshots on Windows 7 Pro x64 VM's causes Bootload errors
by robertodg＠prismatelecomtesting.com 15 Feb '19

15 Feb '19

Hello everyone, on Ovirt 4.2.6.4-1.el7, when we try to create a snapshot on Windows 7 Pro x64 (regardless of whether the VM is powered off or not) after several reboots it causes bootload errors (below you'll find a link with screenshoot error). https://ibb.co/tKx6SKw We haven't tried other Windows versions yet, do you have any idea about what the cause might be? Thanks in advance.

2 1

Ovirt self-hosted engine won't come up
by joshuaosko＠gmail.com 14 Feb '19

14 Feb '19

The self-hosted engine had an issue whereby it'd /var partition was full. A few days later the engine was rebooted; however, it did not come back up gracefully. I presently have three CentOS 7 hosts which can spin up a new hosted engine vm; however every attempt to do so results in: Engine status : {"reason": "failed liveliness check", "health": "bad", "vm": "up", "detail": "Up"} The VM is not "up" as it does not even respond to ping, let alone having any ability to ssh or console into it to see what's wrong. All of the VMs that have been built using this engine appear to be fully operational. Is there any guidance anyone can give me? At this point I'm wondering what the consequences are to deploying a new hosted engine within that same cluster. If anyone could shed light on this matter it would be tremendously appreciated! Thanks.

3 10

please help with console issues on vGPU enabled VMs.
by Edward Berger 14 Feb '19

14 Feb '19

We are attempting to get vGPU-enabled guests working with our oVirt 4.3.0 configuration, but have run into problems. We are running: NVidia License Server version 2018.09 NVidia License Client Manager 2018.10.0.25098346 and that license info is correctly retrieved by the clients. With a Centos 7.6 guest, we can ssh into the guest and see that the X server is running and a gdm process is also running, but when we open a remote console viewer, all we get is a black screen. The X server reports the correct vGPU profile. The only error we see in the Xorg.0.log file is: [ 5.176] (EE) NVIDIA(GPU-0): Failed to update the GLS device with FRL configuration but that is not fatal. With a Windows 10 guest, we do get a login screen to appear, but the mouse and keyboard do not seem to be functional. Host configuration: host is running oVirt-node 4.3.0 NVidia driver NVIDIA-vGPU-rhel-7.6-410.91.x86_64.rpm installed CentOS 7.6 guest configuration: NVidia driver NVIDIA-Linux-x86_64-410.92-grid.run installed added an explicit BusID in the guest's xorg.conf file disabled SELinux Windows 10 guest configuration: NVidia driver 412.16_grid_win10_server2016_64bit_international.exe installed Remote viewer: remote-viewer 5.0-11.el7 running on CentOS 7.3 Both host and guest NVidia drivers come from the NVIDIA-GRID-RHEL-7.6-410.92-410.91-412.16.zip package. We have tried with both V100 and P4 GPUs (with ECC disabled), and encounter similar problems. Any ideas on what to try, or how to better diagnose the cause of these problems? Thanks.

1 0

admin user locked out (OVN invalid_grant)
by Андрей Русаков 14 Feb '19

14 Feb '19

Hi, Recently i upgrade my oVirt installation 4.2.8 to 4.3. I was able to login right after upgrade (yum, setup, reboot). But according to logs, account locks in 2-3 minutes. 2019-02-12 15:44:57,228+03 ERROR [org.ovirt.engine.core.sso.utils.SsoUtils] (default task-1) [] OAuthException invalid_grant: The provided authorization grant for the auth code has expired. 2019-02-12 15:44:57,232+03 ERROR [org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter] (default task-2) [] Cannot authenticate using authentication Headers: invalid_grant: The provided authorization grant for the auth code has expired. 2019-02-12 15:44:57,307+03 INFO [org.ovirt.engine.extension.aaa.jdbc.core.Authentication] (default task-2) [] locking user: admin due to interval failures I was able to unlock admin using CLI, but every time i go to OVN config it locks immediately. Checking OVN service logs i can see code 401, message Unauthorized "POST /v2.0/tokens HTTP/1.1" 401 - And "Error during SSO authentication invalid_grant : The provided authorization grant for the auth code has expired." On OVN web page. Is it possible to renew authorization grant or ...?

2 7

Re: Ovirt Cluster completely unstable
by Sandro Bonazzola 14 Feb '19

14 Feb '19

Il giorno gio 14 feb 2019 alle ore 16:12 Darryl Scott < dscott(a)umbctraining.com> ha scritto: > Sandro > > > I don't have ovirt-log-collector on my ovirt engine. How can obtain? I > see a github repo to make file, I do not want to be making files on my > ovirt-engine, just not yet, I could possible on weekend. > > Where can I obtain the ovirt-log-collector? > > > Just "yum install ovirt-log-collector" should install it for you :-) > > ------------------------------ > *From:* Sandro Bonazzola <sbonazzo(a)redhat.com> > *Sent:* Thursday, February 14, 2019 9:16:05 AM > *To:* Jayme > *Cc:* Darryl Scott; users > *Subject:* Re: [ovirt-users] Re: Ovirt Cluster completely unstable > > > > Il giorno gio 14 feb 2019 alle ore 07:54 Jayme <jaymef(a)gmail.com> ha > scritto: > > I have a three node HCI gluster which was previously running 4.2 with zero > problems. I just upgraded it yesterday. I ran in to a few bugs right away > with the upgrade process, but aside from that I also discovered other users > with severe GlusterFS problems since the upgrade to new GlusterFS version. > It is less than 24 hours since I upgrade my cluster and I just got a notice > that one of my GlusterFS bricks is offline. There does appear to be a very > real and serious issue here with the latest updates. > > > tracking the issue on Gluster side on this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1677160 > If you can help Gluster community providing requested logs it would be > great. > > > > > > > On Wed, Feb 13, 2019 at 7:26 PM <dscott(a)umbctraining.com> wrote: > > I'm abandoning my production ovirt cluster due to instability. I have a > 7 host cluster running about 300 vms and have been for over a year. It has > become unstable over the past three days. I have random hosts both, > compute and storage disconnecting. AND many vms disconnecting and becoming > unusable. > > 7 host are 4 compute hosts running Ovirt 4.2.8 and three glusterfs hosts > running 3.12.5. I submitted a bugzilla bug and they immediately assigned > it to the storage people but have not responded with any meaningful > information. I have submitted several logs. > > I have found some discussion on problems with instability with gluster > 3.12.5. I would be willing to upgrade my gluster to a more stable version > if that's the culprit. I installed gluster using the ovirt gui and this is > the version the ovirt gui installed. > > Is there an ovirt health monitor available? Where should I be looking to > get a resolution the problems I'm facing. > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/BL4M3JQA3IEXC… > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/QULCBXHTKSCPK… > > > > -- > > SANDRO BONAZZOLA > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > > Red Hat EMEA <https://www.redhat.com/> > > sbonazzo(a)redhat.com > <https://red.ht/sig> > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

possibly corrupted disk during 4.3 upgrade
by Jason Brooks 14 Feb '19

14 Feb '19

I have a ovirt+gluster cluster that I've been running for a while now -- across several versions of oVirt. I was upgrading to 4.3 today, and am halfway through the upgrade. I've upgraded two of my four hosts to 4.3, as well as the engine, but the hosted-ha agents aren't running on my new hosts. Also, one of my two upgraded hosts won't connect to one of my domains -- I'm not sure whether that's the master data domain or the hosted engine domain. The *main* thing I'm concerned about, though, is that the disk for one of my large VMs appears to have been truncated -- it's virtual size is 300GB, I think the actual size was probably just under half of that, but it's actual size is now reported to be less than a gig, and it's taking up only 300MB of space. I'm afraid the answer is no, but I'm hoping that the data might be recoverable from somewhere on the bricks... Any thoughts? Jason

3 2

Re: Creating a static route
by Lev Veyde 14 Feb '19

14 Feb '19

Hi Doug, Sorry that it took a bit of time to get back to you. Managed to catch today somebody from the oVirt/RHV network team to discuss the issue. It seems that we don't currently support custom static routes on the hosts, so the workaround that I suggested is the way to do it. Thanks in advance, On Tue, Feb 12, 2019 at 11:12 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> wrote: > Will do. Thanks again for all your help!! Looking forward to a > confirmation of the fix or a different solution. Either way, I know I have > a working fix. > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 3:09 PM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > Just a small note - the commands in the rc.local should be placed *before* > the very last line (the touch ... command). > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 10:56 PM Lev Veyde <lveyde(a)redhat.com> wrote: > > Hi Doug, > > Thanks, you're welcome! > > It's generally possible to add persistent rules by either using the legacy > /etc/rc.d/rc.local boot script (chmod +x /etc/rc.d/rc.local and put the > relevant commands at the end of the file, that way you can actually run any > commands) or by using the /etc/sysconfig/network-scripts/rule-<interface > name> e.g. rule-ovirtmgmt or rule-eno3 (just put in the file "to > 172.22.20.31 priority 32764" - without quotes), however of course this > needs to be tested to verify that it works. > > I forwarded the issue to the network team and hopefully they will update > soon. > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 10:17 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > You have no idea how helpful you have been!!!!!! I’ve been having this > issue for over 2 months and starting to cause major problems. > > > > Please let me know if you find a better solution. I’m going to wait to > hear back from you before implementing. > > > > If we go with this workaround, is there a way to add the ip rule so it’s > persistent? I know how to make the ip route add persistent. > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 2:14 PM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > Yes, it looks like it did. > > I'll try to catch somebody from my local oVirt/RHV networking team to take > a look at this issue, maybe there is a better solution for that issue than > my workaround. > > > > But meanwhile you can use this workaround (ip route add + ip rule add), > just please be aware that these should be run after each host reboot, since > these commands are not persistent. > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 10:07 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > Here’s the results. It appears to fix the issue!! > > > > From non-working system: > > > > -bash-4.2# ip rule add to 172.22.20.31 priority 32764 > > > > -bash-4.2# traceroute 172.22.20.31 > > traceroute to 172.22.20.31 (172.22.20.31), 30 hops max, 60 byte packets > > 1 CenteraAmesAN1.emcins.com (172.21.12.61) 0.487 ms 1.082 ms 1.313 ms > > 2 192.168.90.9 (192.168.90.9) 1.507 ms 2.090 ms 2.294 ms > > 3 pdputopcomm01.emcins.com (172.22.20.31) 1.403 ms 1.401 ms 1.348 ms > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 2:01 PM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > OK, I think that I have a guess of what may have happened here... > > Can you please run the following command on the (non-working) host: > > ip rule add to 172.22.20.31 priority 32764 > > > > This needs to be run in addition to the ip route add ... command. > > > > And then please run the traceroute command and let me know if that fixed > the issue. > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 9:30 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > Here you go. > > > > From non-working system > > > > -bash-4.2# ip rule > > 0: from all lookup local > > 32764: from all to 172.21.0.0/16 iif ovirtmgmt lookup 2887058719 > > 32765: from 172.21.0.0/16 lookup 2887058719 > > 32766: from all lookup main > > 32767: from all lookup default > > > > > > From working system > > > > [root@paputopcomm04 ~]# ip rule > > 0: from all lookup local > > 32766: from all lookup main > > 32767: from all lookup default > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 12:35 PM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > That shouldn't really matter, since ovirtmgmt is just a bridged interface, > and unless I'm missing something it shouldn't really affect routing. > > Can you please also provide the output of "ip rule" from both working and > non-working hosts ? > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 8:01 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > Here’s the ip route from the server that worked and didn’t work > > > > IP Route from server that worked > > > > [root@paputopcomm04 ~]# ip route > > default via 172.21.0.250 dev eno3 > > 169.254.0.0/16 dev eno3 scope link metric 1002 > > 169.254.0.0/16 dev eno4 scope link metric 1005 > > 172.17.0.0/16 dev eno4 proto kernel scope link src 172.17.53.18 > > 172.21.0.0/16 dev eno3 proto kernel scope link src 172.21.5.34 > > *172.22.20.31 via 172.21.12.61 dev eno3* > > 172.26.0.0/16 dev eno1 proto kernel scope link src 172.26.5.34 > > > > > > > > IP Route from server that didn't work > > > > -bash-4.2# ip route > > default via 172.21.0.250 dev ovirtmgmt > > 169.254.0.0/16 dev eno4 scope link metric 1004 > > 169.254.0.0/16 dev ovirtmgmt scope link metric 1021 > > 172.17.0.0/16 dev eno4 proto kernel scope link src 172.17.53.15 > > 172.21.0.0/16 dev ovirtmgmt proto kernel scope link src 172.21.5.31 > > *172.22.20.31 via 172.21.12.61 dev ovirtmgmt* > > 172.26.0.0/16 dev eno1 proto kernel scope link src 172.26.5.31 > > > > We have had our network team look and they don’t know. As I said, the was > setup by Commvault. It’s almost like the ovirtmgmt interface will not > allow a route add due to the way it’s configured? They, Commvault, are > trying different things within their software to get this working, but it’s > causing us more problems. I figured I would take a shot and see if > someone, who works with the oVirt software, would have any ideas. > > > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 11:51 AM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > This is indeed quite weird... > > It looks like the OS for some reason disregards the static route that you > have added. > > BTW, have you verified that it's indeed was added by running "ip route" > following the "ip route add ..." command ? > > Maybe somebody from the network team has an idea of what may be the cause > of this issue... > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 7:36 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > I’m showing you the same outputs (ip a, ip route, traceroute, ip route > add, and traceroute) from another server in this group that doesn’t use the > ovirtmgmt for it’s default interface. > > > > [root@paputopcomm04 ~]# ip a > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > inet 127.0.0.1/8 scope host lo > > valid_lft forever preferred_lft forever > > inet6 ::1/128 scope host > > valid_lft forever preferred_lft forever > > 2: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen > 1000 > > link/ether 90:1b:0e:db:bc:c0 brd ff:ff:ff:ff:ff:ff > > inet 172.21.5.34/16 brd 172.21.255.255 scope global eno3 > > valid_lft forever preferred_lft forever > > inet6 fe80::921b:eff:fedb:bcc0/64 scope link > > valid_lft forever preferred_lft forever > > 3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen > 1000 > > link/ether 90:1b:0e:e8:da:03 brd ff:ff:ff:ff:ff:ff > > inet 172.26.5.34/16 brd 172.26.255.255 scope global eno1 > > valid_lft forever preferred_lft forever > > inet6 fe80::921b:eff:fee8:da03/64 scope link > > valid_lft forever preferred_lft forever > > 4: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN > qlen 1000 > > link/ether 90:1b:0e:e8:da:04 brd ff:ff:ff:ff:ff:ff > > 5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen > 1000 > > link/ether 90:1b:0e:db:bc:c1 brd ff:ff:ff:ff:ff:ff > > inet 172.17.53.18/16 brd 172.17.255.255 scope global eno4 > > valid_lft forever preferred_lft forever > > inet6 fe80::921b:eff:fedb:bcc1/64 scope link > > valid_lft forever preferred_lft forever > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# ip route > > default via 172.21.0.250 dev eno3 > > 169.254.0.0/16 dev eno3 scope link metric 1002 > > 169.254.0.0/16 dev eno4 scope link metric 1005 > > 172.17.0.0/16 dev eno4 proto kernel scope link src 172.17.53.18 > > 172.21.0.0/16 dev eno3 proto kernel scope link src 172.21.5.34 > > 172.26.0.0/16 dev eno1 proto kernel scope link src 172.26.5.34 > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# traceroute 172.22.20.31 > > traceroute to 172.22.20.31 (172.22.20.31), 30 hops max, 60 byte packets > > 1 ames-acc1-agg-1.emcins.com (172.21.0.246) 1.081 ms 1.816 ms 1.832 ms > > 2 192.168.200.30 (192.168.200.30) 0.639 ms 192.168.200.14 > (192.168.200.14) 1.063 ms 1.577 ms > > 3 192.168.200.101 (192.168.200.101) 3.110 ms ames-sw-wanrtr.emcins.com > (192.168.200.97) 3.191 ms 3.277 ms > > 4 192.168.100.26 (192.168.100.26) 4.146 ms 4.273 ms 4.394 ms > > 5 192.168.100.98 (192.168.100.98) 1.893 ms 2.364 ms 2.397 ms > > 6 192.168.100.50 (192.168.100.50) 5.707 ms 192.168.100.33 > (192.168.100.33) 5.134 ms 192.168.100.50 (192.168.100.50) 4.105 ms > > 7 pdputopcomm01.emcins.com (172.22.20.31) 1.359 ms 1.374 ms 1.351 ms > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# ip route add 172.22.20.31 via 172.21.12.61 > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# traceroute 172.22.20.31 > > traceroute to 172.22.20.31 (172.22.20.31), 30 hops max, 60 byte packets > > 1 CenteraAmesAN1.emcins.com (172.21.12.61) 6.184 ms 6.475 ms 6.686 ms > > 2 192.168.90.9 (192.168.90.9) 1.770 ms 1.979 ms 2.189 ms > > 3 pdputopcomm01.emcins.com (172.22.20.31) 1.405 ms * 1.354 ms > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 11:07 AM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > In most cases it should not be required, especially as my guess (again it > would be easier if you could post the output of the "ip a" and "ip route") > is that the eno1 is part of the ovirtmgmt bridge. > > What is the output of the "traceroute 172.22.20.31" that you get on the > host after you have added the static route? > > Thanks in advance, > > > > > > On Tue, Feb 12, 2019 at 6:58 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > One other question, since there are multiple enabled interfaces (ovirtmgmt > and eno1), do I need to specify an interface for the route add. > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 10:50 AM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > What do you mean by "static route is refused"? > > What is the error message(s) you see? > > > > Can you please try to add the route with the following command: > > ip route add 172.22.20.31 via 172.21.12.61 > > > > If that doesn't work, then please provide more details, i.e. what is the > exact error message(s) you see, the version of your OS and oVirt, output of > "ip a" and "ip route" on your host(s), so that it will be easier to help > you. > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 6:43 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > Thanks for your response. > > > > If I attempt to manually add the route using route add: > > > > route add -net 172.22.20.31 netmask 255.255.255.255 gw 172.21.12.61 dev > ovirtmgmt > > > > This static route is refused and all traffic is routed over the default > gateway. > > > > But if I use a server that doesn’t use the ovirtmgmt interface and set the > same static route, the required data is routed correctly over that static > route. > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 10:34 AM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > What is the exact problem you are having while attempting to add a static > route on the hosts? > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 5:23 PM <doug.l.maxfield(a)emcins.com> wrote: > > Good Morning, > New to oVirt. We are using this with a backup solution from Commvault. > The issue that we are having is that we need to setup a static route for > specific data between 2 remote sites. The ovirtmgmt is configured with the > correct IP and gateway for the server. We need to route data over a > different gateway so that we don't "max out" the default network connection > between the 2 sites. Example below > > Ovirtmgmt IP - 172.21.5.31 > Gateway IP - 172.21.0.250 > > We need any traffic with a destination of 172.22.20.31(Remote site) to > route over this gateway, 172.21.12.61 > > There are multiple servers in this configuration. Servers that are not > using the ovirtmgmt interface for their default, we are able to route the > data. The only problem is with attempting to setup a different static > route on the ovirtmgmt interfaces. > > Thanks in advance for any help!!! > > Doug > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/WGXSLHAP3X5OT… > > > > -- > > > > *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> > > > NOTICE: This message (including any attachments) is intended for a > specific individual and may contain information that is either confidential > or legally protected. If you believe that it has been sent to you in > error, please reply to the sender that you have received the message in > error, then delete it. If you are not the intended recipient, you are > hereby notified that any retention, dissemination, distribution, or copying > of this communication is strictly prohibited. Thank you. EMC071856 > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > -- 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>

2 1

Problem installing hyperconverged setup
by paul＠agile.uk.com 14 Feb '19

14 Feb '19

Hi, I am currently setting up an Ovirt cluster in a test environment and cannot get the hyperconverged setup to run properly. I have installed 3 nodes on version 4.2.8. I keep getting the following error - TASK [Create LVs with specified size for the VGs] ****************************** failed: [node01.ovirt.local] (item={u'lv': u'gluster_thinpool_sdb', u'size': u'1005GB', u'extent': u'100%FREE', u'vg': u'gluster_vg_sdb'}) => {"changed": false, "item": {"extent": "100%FREE", "lv": "gluster_thinpool_sdb", "size": "1005GB", "vg": "gluster_vg_sdb"}, "msg": " WARNING: Pool zeroing and 3.00 MiB large chunk size slows down thin provisioning.\n WARNING: Consider disabling zeroing (-Zn) or using smaller chunk size (<512.00 KiB).\n Volume group \"gluster_vg_sdb\" has insufficient free space (157261 extents): 343040 required.\n", "rc": 5} to retry, use: --limit @/tmp/tmpbXqHhw/lvcreate.retry All 3 nodes have an /sdb installed which are different sizes but all in excess of 450Gb. I have specified JBOD in the setup. I have tried reducing the size of the engine, data and vmstore bricks to 50Gb each instead of the default but the installation still fails. I think it has something to do with the thin provisioning but not sure what. Any help would be much appreciated. Thanks Paul.

3 2

Deleted Hosted Engine
by Manny SyS 14 Feb '19

14 Feb '19

I have to deal with this oVirt 4.2 cluster, 4 nodes. It seems someone smartly deleted hosted engine vm... how cool... so, all the VMs are still running, but no cluster management anymore :-). It's a testing environment, no hosted engine backup. I have no problems reinstalling the cluster... but I'd love to rescue the VMs... so I'm trying to understand what options I do have, so I ask you please if you have some hints, or maybe links to the right documentation. - ssh to any ovirt cluster node and export the vms with virsh? possible? - ssh to any ovirt cluster node and live migrate all the vms on one node? so that I can reinstall a new cluster on the freed nodes? Wondering which one is the correct path to do this... btw, virsh only works in readonly in ovirt cluster nodes - it's a testing environment, so I could shutdown everything, reinstall a new cluster, reconnect the old storage to the new cluster... question is, how to reimport all the vms in the new cluster. Please any suggestions?

3 2

ovirt-guest-agent is still needed?
by Vinícius Ferrão 14 Feb '19

14 Feb '19

Hello, I heard that ovirt-guest-agent is now deprecated and qemu-guest-agent should be used instead. As today I still install the ovirt-guest-agent from EPEL in my EL guests, but should I continue doing this or using the shipped qemu-guest-agent should be used instead? What about Windows guests? Any modification needed? Thanks,

3 3

Engine installation failed at - get local vm ip
by Tailor, Bharat 14 Feb '19

14 Feb '19

Hi, I am trying to test ovirt hyperconverged setup. I've a dell server & using vmware ESXi 6.7 as hypervisor. Prepared 3 VMs with cpu hw exposed. VM1 - Ovirt node 4.2 18GB RAM 2*2 vcpu nic 1 - for backend gluster nic 2 - for frontend vm network VM2 - Ovirt node 4.2 18GB RAM 2*2 vcpu nic 1 - for backend gluster nic 2 - for frontend vm network VM3- Ovirt node 4.2 18GB RAM 2*2 vcpu nic 1 - for backend gluster nic 2 - for frontend vm network I've configured gluster storage from cockpit and now trying to install engine from same cockpit but setup failed at "get local vm ip". I've gone through /var/log/ovirt-hosted-engine-setup file also but there are so many log files and I haven't find any related logs. Please help me to get out of it. Regrards Bharat Kumar G15- Vinayak Nagar complex,Opp.Maa Satiya, ayad Udaipur (Raj.) 313001 Mob: +91-9950-9960-25

2 9

engine-iso-uploader taking a REALLY long time
by zachary.winter＠vcwise.com 14 Feb '19

14 Feb '19

I am noticing that the engine-iso-uploader tool on oVirt 4.2.7 (running on CentOS 7.6.1810) takes a very long time to load individual ISO's, usually on the order of hours for a single ISO. Is this normal?

5 10

Windows 2016 guest auto shutdown
by aminur.rahman＠iongroup.com 14 Feb '19

14 Feb '19

I am using ovirt hosted engine 4.2 to manage 5 nodes cluster and Dell Compellent storage domain using ISCSI. The guest is running Windows 2016 OS with ovirt 4.2.4 guest tools installed. The guest presented 1.4 TB thin provision disks and very often, the VM goes offline while doing big file transfer. I didn't find any event errors on OS level. I am wondering if anyone has experienced this issue. Thanks -Aminur

3 2

Cluster Compatibility Version Upgrading Order
by Roman Last 13 Feb '19

13 Feb '19

Hello! What sequence of upgrading cluster to 4.3 version? When i click upgrade on host w or w\o host reboot it just says "Upgrade has started for" and nothing after timeout reached. When i force restart host, version 4.3 not added. Is that normal? https://prnt.sc/mki3v8

3 3

Agentless Backup update: Trilio Vault, pay $7500
by femi adegoke 13 Feb '19

13 Feb '19

Back in June of 2018, I posted regarding Agentless backup solutions. Greg Sheremeta replied & mentioned Trilio. The rest of the story...well just read on... These guys at Trilio have turned out to be a complete waste of time. (I could use some more colorful language) After my post & reply from Greg Sheremeta, I followed up with Trilio. A lot of promises/dates were made (by Trilio) as to when a beta would be made available for testing. Needless to say, they never came through. Finally in Dec 2018, they said we are ready for the demo, we will show you a working product. The day came, Trilio said, sorry it's too close to Xmas, we will postpone the demo's till 2019. In 2019, I continued to follow up & finally they set a date for another demo - Jan 29. On Jan. 29, we get on the Webex, they said, sorry the demo just broke 10 mins prior to our call, so no demo. They show me some screenshots & their OpenStack version & again promise to get me beta software in a few days. I continue to follow up (via email) Yesterday (Feb 6), I get an email from Thomas Lahive GM; Sales and Alliance Partners....(copied & pasted below): "We started RHV betas and decided to prioritize current Trilio customers (those that purchased Triliovault for Openstack). If you would like to be part of the beta now then We can sign you up as a certified Trilio reseller which has a $7,500 Starter Fee. The $7,500 will be credited against your first customer order that is at least $7,500 so it will eventually cost you nothing. Many of our partners can apply the fee against revenue so it's a great tax incentive, but you can confirm with your finance department. Please Lmk how you would like to proceed." Please remember, I have never seen a working demo of this product, never. Is this typical behavior of RH partners?

5 7

Problems with procedure in blog post...
by Jason P. Thomas 13 Feb '19

13 Feb '19

rgolan asked me to post this here for him. I'm trying the procedure from this blog post: https://ovirt.org/blog/2019/01/ovirt-openshift-part-1.html Ultimate goal is to install ovirt metrics store. I've tried vars.yaml with and without the ovirt metrics stuff commented out. The errors seem to revolve around downloading the centos qcow2c image. With image_path: "{{ lookup('env', 'HOME') }}/Downloads/{{ template_name }}.qcow2" defined, I get the following error: fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'isdir'\n\nThe error appears to have been in '/usr/share/ansible/roles/ovirt.image-template/tasks/qcow2_image.yml': line 12, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Download the qcow image\n ^ here\n"} If I comment out the above image_path line and uncomment the one at the bottom of vars.yaml that specifies /var/tmp, I get this error: fatal: [localhost]: FAILED! => {"changed": false, "cmd": "/usr/bin/file /var/tmp/CentOS-7-x86_64-GenericCloud.qcow2c", "msg": "[Errno 2] No such file or directory", "rc": 2} --Jason

3 4

IPTablesConfig replacement in 4.3
by Roman Last 13 Feb '19

13 Feb '19

Hello! So, i just update up in 4.3, whith auto configration iptables by vsdm. How can i make some custom rules in iptables becouse IPTablesConfigSiteCustom is now deprecated. Thanks.

3 2

Error starting hosted engine
by Endre Karlson 12 Feb '19

12 Feb '19

https://paste.ubuntu.com/p/BrmPYRKmzT/ https://paste.fedoraproject.org/paste/MjfioF9-Pzk02541abKyOw Seems like it's a error with vdsmd and glusterfs ? // Endre

4 6

change cache behavior per VM?
by Hetz Ben Hamo 12 Feb '19

12 Feb '19

Hi, With KVM (and using tools like virt-manager) you can set the cache behavior like write-back, write-through etc. etc.. Can this be done by oVirt? looks like oVirt "kills" ZFS servers as it insists to wait until every bit has been written to disk, and I don't need it (my oVirt is not for production, and there are snapshots in ZFS for that). Thanks

1 0

Re: Creating a static route
by Lev Veyde 12 Feb '19

12 Feb '19

Hi Doug, Thanks, you're welcome! It's generally possible to add persistent rules by either using the legacy /etc/rc.d/rc.local boot script (chmod +x /etc/rc.d/rc.local and put the relevant commands at the end of the file, that way you can actually run any commands) or by using the /etc/sysconfig/network-scripts/rule-<interface name> e.g. rule-ovirtmgmt or rule-eno3 (just put in the file "to 172.22.20.31 priority 32764" - without quotes), however of course this needs to be tested to verify that it works. I forwarded the issue to the network team and hopefully they will update soon. Thanks in advance, On Tue, Feb 12, 2019 at 10:17 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> wrote: > Lev, > > You have no idea how helpful you have been!!!!!! I’ve been having this > issue for over 2 months and starting to cause major problems. > > > > Please let me know if you find a better solution. I’m going to wait to > hear back from you before implementing. > > > > If we go with this workaround, is there a way to add the ip rule so it’s > persistent? I know how to make the ip route add persistent. > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 2:14 PM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > Yes, it looks like it did. > > I'll try to catch somebody from my local oVirt/RHV networking team to take > a look at this issue, maybe there is a better solution for that issue than > my workaround. > > > > But meanwhile you can use this workaround (ip route add + ip rule add), > just please be aware that these should be run after each host reboot, since > these commands are not persistent. > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 10:07 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > Here’s the results. It appears to fix the issue!! > > > > From non-working system: > > > > -bash-4.2# ip rule add to 172.22.20.31 priority 32764 > > > > -bash-4.2# traceroute 172.22.20.31 > > traceroute to 172.22.20.31 (172.22.20.31), 30 hops max, 60 byte packets > > 1 CenteraAmesAN1.emcins.com (172.21.12.61) 0.487 ms 1.082 ms 1.313 ms > > 2 192.168.90.9 (192.168.90.9) 1.507 ms 2.090 ms 2.294 ms > > 3 pdputopcomm01.emcins.com (172.22.20.31) 1.403 ms 1.401 ms 1.348 ms > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 2:01 PM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > OK, I think that I have a guess of what may have happened here... > > Can you please run the following command on the (non-working) host: > > ip rule add to 172.22.20.31 priority 32764 > > > > This needs to be run in addition to the ip route add ... command. > > > > And then please run the traceroute command and let me know if that fixed > the issue. > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 9:30 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > Here you go. > > > > From non-working system > > > > -bash-4.2# ip rule > > 0: from all lookup local > > 32764: from all to 172.21.0.0/16 iif ovirtmgmt lookup 2887058719 > > 32765: from 172.21.0.0/16 lookup 2887058719 > > 32766: from all lookup main > > 32767: from all lookup default > > > > > > From working system > > > > [root@paputopcomm04 ~]# ip rule > > 0: from all lookup local > > 32766: from all lookup main > > 32767: from all lookup default > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 12:35 PM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > That shouldn't really matter, since ovirtmgmt is just a bridged interface, > and unless I'm missing something it shouldn't really affect routing. > > Can you please also provide the output of "ip rule" from both working and > non-working hosts ? > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 8:01 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > Here’s the ip route from the server that worked and didn’t work > > > > IP Route from server that worked > > > > [root@paputopcomm04 ~]# ip route > > default via 172.21.0.250 dev eno3 > > 169.254.0.0/16 dev eno3 scope link metric 1002 > > 169.254.0.0/16 dev eno4 scope link metric 1005 > > 172.17.0.0/16 dev eno4 proto kernel scope link src 172.17.53.18 > > 172.21.0.0/16 dev eno3 proto kernel scope link src 172.21.5.34 > > *172.22.20.31 via 172.21.12.61 dev eno3* > > 172.26.0.0/16 dev eno1 proto kernel scope link src 172.26.5.34 > > > > > > > > IP Route from server that didn't work > > > > -bash-4.2# ip route > > default via 172.21.0.250 dev ovirtmgmt > > 169.254.0.0/16 dev eno4 scope link metric 1004 > > 169.254.0.0/16 dev ovirtmgmt scope link metric 1021 > > 172.17.0.0/16 dev eno4 proto kernel scope link src 172.17.53.15 > > 172.21.0.0/16 dev ovirtmgmt proto kernel scope link src 172.21.5.31 > > *172.22.20.31 via 172.21.12.61 dev ovirtmgmt* > > 172.26.0.0/16 dev eno1 proto kernel scope link src 172.26.5.31 > > > > We have had our network team look and they don’t know. As I said, the was > setup by Commvault. It’s almost like the ovirtmgmt interface will not > allow a route add due to the way it’s configured? They, Commvault, are > trying different things within their software to get this working, but it’s > causing us more problems. I figured I would take a shot and see if > someone, who works with the oVirt software, would have any ideas. > > > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 11:51 AM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > This is indeed quite weird... > > It looks like the OS for some reason disregards the static route that you > have added. > > BTW, have you verified that it's indeed was added by running "ip route" > following the "ip route add ..." command ? > > Maybe somebody from the network team has an idea of what may be the cause > of this issue... > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 7:36 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > I’m showing you the same outputs (ip a, ip route, traceroute, ip route > add, and traceroute) from another server in this group that doesn’t use the > ovirtmgmt for it’s default interface. > > > > [root@paputopcomm04 ~]# ip a > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > inet 127.0.0.1/8 scope host lo > > valid_lft forever preferred_lft forever > > inet6 ::1/128 scope host > > valid_lft forever preferred_lft forever > > 2: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen > 1000 > > link/ether 90:1b:0e:db:bc:c0 brd ff:ff:ff:ff:ff:ff > > inet 172.21.5.34/16 brd 172.21.255.255 scope global eno3 > > valid_lft forever preferred_lft forever > > inet6 fe80::921b:eff:fedb:bcc0/64 scope link > > valid_lft forever preferred_lft forever > > 3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen > 1000 > > link/ether 90:1b:0e:e8:da:03 brd ff:ff:ff:ff:ff:ff > > inet 172.26.5.34/16 brd 172.26.255.255 scope global eno1 > > valid_lft forever preferred_lft forever > > inet6 fe80::921b:eff:fee8:da03/64 scope link > > valid_lft forever preferred_lft forever > > 4: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN > qlen 1000 > > link/ether 90:1b:0e:e8:da:04 brd ff:ff:ff:ff:ff:ff > > 5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen > 1000 > > link/ether 90:1b:0e:db:bc:c1 brd ff:ff:ff:ff:ff:ff > > inet 172.17.53.18/16 brd 172.17.255.255 scope global eno4 > > valid_lft forever preferred_lft forever > > inet6 fe80::921b:eff:fedb:bcc1/64 scope link > > valid_lft forever preferred_lft forever > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# ip route > > default via 172.21.0.250 dev eno3 > > 169.254.0.0/16 dev eno3 scope link metric 1002 > > 169.254.0.0/16 dev eno4 scope link metric 1005 > > 172.17.0.0/16 dev eno4 proto kernel scope link src 172.17.53.18 > > 172.21.0.0/16 dev eno3 proto kernel scope link src 172.21.5.34 > > 172.26.0.0/16 dev eno1 proto kernel scope link src 172.26.5.34 > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# traceroute 172.22.20.31 > > traceroute to 172.22.20.31 (172.22.20.31), 30 hops max, 60 byte packets > > 1 ames-acc1-agg-1.emcins.com (172.21.0.246) 1.081 ms 1.816 ms 1.832 ms > > 2 192.168.200.30 (192.168.200.30) 0.639 ms 192.168.200.14 > (192.168.200.14) 1.063 ms 1.577 ms > > 3 192.168.200.101 (192.168.200.101) 3.110 ms ames-sw-wanrtr.emcins.com > (192.168.200.97) 3.191 ms 3.277 ms > > 4 192.168.100.26 (192.168.100.26) 4.146 ms 4.273 ms 4.394 ms > > 5 192.168.100.98 (192.168.100.98) 1.893 ms 2.364 ms 2.397 ms > > 6 192.168.100.50 (192.168.100.50) 5.707 ms 192.168.100.33 > (192.168.100.33) 5.134 ms 192.168.100.50 (192.168.100.50) 4.105 ms > > 7 pdputopcomm01.emcins.com (172.22.20.31) 1.359 ms 1.374 ms 1.351 ms > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# ip route add 172.22.20.31 via 172.21.12.61 > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# > > [root@paputopcomm04 ~]# traceroute 172.22.20.31 > > traceroute to 172.22.20.31 (172.22.20.31), 30 hops max, 60 byte packets > > 1 CenteraAmesAN1.emcins.com (172.21.12.61) 6.184 ms 6.475 ms 6.686 ms > > 2 192.168.90.9 (192.168.90.9) 1.770 ms 1.979 ms 2.189 ms > > 3 pdputopcomm01.emcins.com (172.22.20.31) 1.405 ms * 1.354 ms > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 11:07 AM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > In most cases it should not be required, especially as my guess (again it > would be easier if you could post the output of the "ip a" and "ip route") > is that the eno1 is part of the ovirtmgmt bridge. > > What is the output of the "traceroute 172.22.20.31" that you get on the > host after you have added the static route? > > Thanks in advance, > > > > > > On Tue, Feb 12, 2019 at 6:58 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > One other question, since there are multiple enabled interfaces (ovirtmgmt > and eno1), do I need to specify an interface for the route add. > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 10:50 AM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > What do you mean by "static route is refused"? > > What is the error message(s) you see? > > > > Can you please try to add the route with the following command: > > ip route add 172.22.20.31 via 172.21.12.61 > > > > If that doesn't work, then please provide more details, i.e. what is the > exact error message(s) you see, the version of your OS and oVirt, output of > "ip a" and "ip route" on your host(s), so that it will be easier to help > you. > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 6:43 PM Doug Maxfield <Doug.L.Maxfield(a)emcins.com> > wrote: > > Lev, > > Thanks for your response. > > > > If I attempt to manually add the route using route add: > > > > route add -net 172.22.20.31 netmask 255.255.255.255 gw 172.21.12.61 dev > ovirtmgmt > > > > This static route is refused and all traffic is routed over the default > gateway. > > > > But if I use a server that doesn’t use the ovirtmgmt interface and set the > same static route, the required data is routed correctly over that static > route. > > > > [image: Count On EMC] <http://www.emcins.com/> > > *Doug Maxfield *| Senior Operating Systems Analyst > > *EMC Insurance Companies *717 Mulberry St | Des Moines, IA 50265 > Tel: 515.345.4507 | Fax: 866.331.1522 > Doug.L.Maxfield(a)EMCIns.com | www.emcins.com > > > > > > *From:* Lev Veyde <lveyde(a)redhat.com> > *Sent:* Tuesday, February 12, 2019 10:34 AM > *To:* Doug Maxfield <Doug.L.Maxfield(a)EMCIns.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Creating a static route > > > > Hi Doug, > > What is the exact problem you are having while attempting to add a static > route on the hosts? > > > > Thanks in advance, > > > > On Tue, Feb 12, 2019 at 5:23 PM <doug.l.maxfield(a)emcins.com> wrote: > > Good Morning, > New to oVirt. We are using this with a backup solution from Commvault. > The issue that we are having is that we need to setup a static route for > specific data between 2 remote sites. The ovirtmgmt is configured with the > correct IP and gateway for the server. We need to route data over a > different gateway so that we don't "max out" the default network connection > between the 2 sites. Example below > > Ovirtmgmt IP - 172.21.5.31 > Gateway IP - 172.21.0.250 > > We need any traffic with a destination of 172.22.20.31(Remote site) to > route over this gateway, 172.21.12.61 > > There are multiple servers in this configuration. Servers that are not > using the ovirtmgmt interface for their default, we are able to route the > data. The only problem is with attempting to setup a different static > route on the ovirtmgmt interfaces. > > Thanks in advance for any help!!! > > Doug > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/WGXSLHAP3X5OT… > > > > -- > > > > *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> > > > NOTICE: This message (including any attachments) is intended for a > specific individual and may contain information that is either confidential > or legally protected. If you believe that it has been sent to you in > error, please reply to the sender that you have received the message in > error, then delete it. If you are not the intended recipient, you are > hereby notified that any retention, dissemination, distribution, or copying > of this communication is strictly prohibited. Thank you. EMC071856 > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > > > > -- > > > > *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> > -- 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>

2 2

vGPU remote console problems
by Edward Berger 12 Feb '19

12 Feb '19

A coworker and I are trying to bring up some nvidia vGPU VMs on ovirt 4.3, but are experiencing issues with the remote consoles for both Windows and Linux. A windows10 VM for example works OK with a windows remote desktop client after enabling the service inside the VM, but using the oVirt VM portal spice/vnc seems to cause the mouse pointer to disappear and clicks seem to go nowhere. We're more likely to want linux VMs though. CentOS not booting all the way to gnome desktop after installing the nvidia driver. What works well for you? Are there known tweaks I should try to make? Any helpful hints? Thanks!

1 0