[ovirt-users] Re: [rhev-tech] ovirt-imageio-proxy not working after updating SSL certificates with a wildcard cert issued by AlphaSSL (intermediate)

2020-07-24 Thread Greg Scott
Make sure you have the right imageio versions. We spent around two months
troubleshooting a similar problem and eventually found my customer had
imageio 1.0.0 when they should have had something like 1.4.4. Do an rpm -
qa | grep imageio on both your RHVM and RHV-H systems and see what it looks
like.

Also try that test button in RHVM and see how it behaves. Does it fail
right away or does it take a couple seconds?

- Greg

On Fri, Jul 24, 2020 at 9:24 PM Lynn Dixon  wrote:

> All,
> I recently bought a wildcard certificate for my lab domain (shadowman.dev)
> and I replaced all the certs on my RHV4.3 machine per our documentation.
> The WebUI presents the certs successfully and without any issues, and
> everything seemed to be fine, until I tried to upload a disk image (or an
> ISO) to my storage domain.  I get this error in the events tab:
>
> https://share.getcloudapp.com/p9uPvegx
> [image: image.png]
>
> I also see that the disk is showing up in my storage domain, but its
> showing "Paused by System" and I can't do anything with it.  I cant even
> delete it!
>
> I have tried following this document to fix the issue, but it didn't work:
> https://access.redhat.com/solutions/4148361
>
> I am seeing this error pop into my engine.log:
> https://pastebin.com/kDLSEq1A
>
> And I see this error in my image-proxy.log:
> WARNING 2020-07-24 15:26:34,802 web:137:web:(log_error) ERROR
> [172.17.0.30] PUT /tickets/ [403] Error verifying signed ticket: Invalid
> ovirt ticket (data='--my_ticket_data-', reason=Untrusted
> certificate) [request=0.002946/1]
>
> Now, when I bought my wildcard, I was given a root certificate for the CA,
> as well as a separate intermediate CA certificate from the provider.
> Likewise, they gave me a certificate and a private key of course. The root
> and intermediate CA's certificates have been added
> to /etc/pki/ca-trust/source/anchors/ and I did an update-ca-trust.
>
> I also started experiencing issues with the ovpn network provider at the
> same time I replaced the SSL certs, but I disregarded it at the time, but
> now I am thinking its related.  Any advice on what to look for to fix the
> ovirt-imageio-proxy?
>
> Thanks!
>
>
> *Lynn Dixon* | Red Hat Certified Architect #100-006-188
> *Solutions Architect* | NA Commercial
> Google Voice: 423-618-1414
> Cell/Text: 423-774-3188
> Click here to view my Certification Portfolio 
>
>
>

-- 
Greg Scott
Red Hat Senior Technical Account Manager
mobile 1-651-260-1051
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/2QLLTX7U4PNQNEFS4AWHLZANK6KCN5HC/


[ovirt-users] ovirt-imageio-proxy not working after updating SSL certificates with a wildcard cert issued by AlphaSSL (intermediate)

2020-07-24 Thread Lynn Dixon
All,
I recently bought a wildcard certificate for my lab domain (shadowman.dev)
and I replaced all the certs on my RHV4.3 machine per our documentation.
The WebUI presents the certs successfully and without any issues, and
everything seemed to be fine, until I tried to upload a disk image (or an
ISO) to my storage domain.  I get this error in the events tab:

https://share.getcloudapp.com/p9uPvegx
[image: image.png]

I also see that the disk is showing up in my storage domain, but its
showing "Paused by System" and I can't do anything with it.  I cant even
delete it!

I have tried following this document to fix the issue, but it didn't work:
https://access.redhat.com/solutions/4148361

I am seeing this error pop into my engine.log:
https://pastebin.com/kDLSEq1A

And I see this error in my image-proxy.log:
WARNING 2020-07-24 15:26:34,802 web:137:web:(log_error) ERROR [172.17.0.30]
PUT /tickets/ [403] Error verifying signed ticket: Invalid ovirt ticket
(data='--my_ticket_data-', reason=Untrusted certificate)
[request=0.002946/1]

Now, when I bought my wildcard, I was given a root certificate for the CA,
as well as a separate intermediate CA certificate from the provider.
Likewise, they gave me a certificate and a private key of course. The root
and intermediate CA's certificates have been added
to /etc/pki/ca-trust/source/anchors/ and I did an update-ca-trust.

I also started experiencing issues with the ovpn network provider at the
same time I replaced the SSL certs, but I disregarded it at the time, but
now I am thinking its related.  Any advice on what to look for to fix the
ovirt-imageio-proxy?

Thanks!


*Lynn Dixon* | Red Hat Certified Architect #100-006-188
*Solutions Architect* | NA Commercial
Google Voice: 423-618-1414
Cell/Text: 423-774-3188
Click here to view my Certification Portfolio 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5AO2J4APSW4YW5EW3PUIPXB4VAWVNBWP/


[ovirt-users] Re: 4.4.x - VLAN-based logical network can't attach to bonds?

2020-07-24 Thread Mark R

> Can you please create a bug
>  for oVirt with
> reproduction steps?
> 

Created https://bugzilla.redhat.com/show_bug.cgi?id=1860479 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KHM3KU6LG6MYVSLBH76FSBJ67ITUWMQP/


[ovirt-users] Re: RDP

2020-07-24 Thread eevans
Its strange but I finally figured outhow to add users to specific machines. 
When searching i use a wild card * and it shows all available users, but will 
not search by user name or email. BUT, I'm this far along if i can get RDP to 
work out of the vm portal.
I'll keep you posted.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/U55YPW2GU7AYAQUQLCCDLKVCRQ54AORO/


[ovirt-users] Re: 4.4.x - VLAN-based logical network can't attach to bonds?

2020-07-24 Thread Mark R
Hi Dominik,

> Can you please create a bug
>  for oVirt with
> reproduction steps?

Yes, I'll do so. Rebuilding the host fresh now so I have a clean slate as I go 
through the steps for the report.  I did try NM 1.26 from the COPR repo you 
linked, but the issue persisted.

> .. if the new NetworkManager 1.26 from ...
> would fix the problem already.

I installed 1.26 and tried to add the network but it failed.

Thanks!
Mark
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AICQLMYKETZ63BUTTI25E53B76ZM32T3/


[ovirt-users] Re: CentOS 8.2, ovVirt 4.4.1.8, SHE -- kernel: device-mapper: core: ovirt-ha-broker: sending ioctl 5401 to DM device without required privilege

2020-07-24 Thread Dmitry Kharlamov
Yes! Happened! Thank you so much!
Didn't know about this possibility.

Oops, the solution is very peculiar ...)))
"The messages are benign and can be ignored."

It's very good that everything is in order, but how to get rid of this stream 
of messages ???
The log file grows very quickly and other messages are lost. Likewise, the 
console is constantly full of these "good" messages ..
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XSHUBZAFD7GKQZGC3664HVJTAGTKVVHD/


[ovirt-users] Re: problem with custom bond options

2020-07-24 Thread Strahil Nikolov via Users
Hi Jiri,

you are the second person who mentions it.  Can you open a bug at 
bugzilla.redhat.com  about that  ?

Best Regards,
Strahil Nikolov

На 24 юли 2020 г. 16:30:02 GMT+03:00, "Jiří Sléžka"  написа:
>On 7/24/20 11:36 AM, Jiří Sléžka wrote:
>> On 7/24/20 10:56 AM, Ales Musil wrote:
>>>
>>>
>>> On Fri, Jul 24, 2020 at 10:40 AM Jiří Sléžka >> > wrote:
>>>
>>> On 7/23/20 2:07 PM, Jiří Sléžka wrote:
>>> > On 7/23/20 12:35 PM, Ales Musil wrote:
>>> >>
>>> >>
>>> >> On Thu, Jul 23, 2020 at 11:50 AM Jiří Sléžka
>>> 
>>> >> >>
>wrote:
>>> >>
>>> >>     On 7/23/20 11:03 AM, Ales Musil wrote:
>>> >>     >
>>> >>     >
>>> >>     > On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka
>>> mailto:jiri.sle...@slu.cz>
>>> >>     >
>>> >>     > 
>>> >> >>     >
>>> >>     >     Hi,
>>> >>     >
>>> >>     >     On 7/23/20 8:38 AM, Ales Musil wrote:
>>> >>     >     >
>>> >>     >     >
>>> >>     >     > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka
>>> >>     mailto:jiri.sle...@slu.cz>
>>> >
>>> >>     >     
>>> >>
>>> >>     >     > >>  >> >
>>> >>     
>>> 
>wrote:
>>> >>     >     >
>>> >>     >     >     Hello,
>>> >>     >     >
>>> >>     >     >
>>> >>     >     > Hi,
>>> >>     >     >
>>> >>     >     >
>>> >>     >     >     CentOS8, oVirt 4.4.1.10-1.el8
>>> >>     >     >
>>> >>     >     >     I am trying to setup active-backup (mode=1)
>>> bonding mode
>>> >>     with
>>> >>     >     custom
>>> >>     >     >     properties. I have one 10GE switch, the
>second is
>>> just 1G.
>>> >>     >     10GE link is
>>> >>     >     >     the primary one.
>>> >>     >     >
>>> >>     >     >     cat
>/etc/sysconfig/network-scripts/ifcfg-bond0
>>> >>     >     >
>>> >>     >     >
>>> >>     >     > first of all in oVirt 4.4 the network-scripts are
>not
>>> relevant
>>> >>     >     anymore.
>>> >>     >     > More relevant is output from 'nmstatectl show'.
>>> >>     >
>>> >>     >     thanks, I believed that ifcfg files still describes
>saved
>>> >>     interface
>>> >>     >     configuration (even on nm managed interfaces)...
>>> >>     >
>>> >>     >
>>> >>     > It does but it might not be that detailed as we would
>have
>>> hoped for.
>>> >>     > Another reason why I said that it is not relevant is of
>>> course if
>>> >>     > someone tries
>>> >>     > reconfigure the interface through network-scripts.
>>> >>
>>> >>     well, honestly I did that (modified ifcfg and then use
>nmcli con
>>> >>     reload). So right way is using nmcli con modify command?
>>> >>
>>> >>
>>> >> Yes or nmstate. Just be aware that anything that you do to
>interface
>>> >> outside of oVirt can have harmful impacts on the host and
>overall
>>> oVirt
>>> >> state.
>>> >>  
>>> >>
>>> >>
>>> >>     >     from nmstatectl show I can see that bond0 has
>specified mac
>>> >>     address
>>> >>     >
>>> >>     >   
>>> >>   
>>>
>  
>https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
>>> >>     >
>>> >>     >     >     BONDING_OPTS="active_slave=ens5 downdelay=0
>>> miimon=100
>>> >>     >     >     mode=active-backup primary=ens5 updelay=0"
>>> >>     >     >     TYPE=Bond
>>> >>     >     >     BONDING_MASTER=yes
>>> >>     >     >     PROXY_METHOD=none
>>> >>     >     >     BROWSER_ONLY=no
>>> >>     >     >     IPV4_FAILURE_FATAL=no
>>> >>     >     >     IPV6_DISABLED=yes
>>> >>     >     >     IPV6INIT=no
>>> >>     >     >     NAME=bond0
>>> >>     >     >     UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
>>> >>     >     >     DEVICE=bond0
>>> >>     >     >     ONBOOT=yes
>>> >>     >     >     MTU=9000
>>> >>     >     >
>>> >>     >     >     When I try to add a custom parameter
>>> "fail_over_mac=active"
>>> >>     >     (which I
>>> >>     >     >     believe could solve my problems with stalled
>mac
>>> >>     addresses in
>>> >>     >     switch's
>>> >>     >     >     cam table in case of failover) I got...

[ovirt-users] Re: CentOS 8.2, ovVirt 4.4.1.8, SHE -- kernel: device-mapper: core: ovirt-ha-broker: sending ioctl 5401 to DM device without required privilege

2020-07-24 Thread Strahil Nikolov via Users
For the subscription you got a way around -> just subscripe at 
developers.redhat.com 

Best Regards,
Strahil Nikolov

На 24 юли 2020 г. 17:22:17 GMT+03:00, Dmitry Kharlamov  
написа:
>If it does not make it difficult, please tell me at least the general
>direction in which you need to look for a solution to my problem?
>
>Unfortunately, at the moment, I am not able to subscribe to get access
>to RedHat Customer Portal.
>
>Thank you in advance.
>Dmitry
>___
>Users mailing list -- users@ovirt.org
>To unsubscribe send an email to users-le...@ovirt.org
>Privacy Statement: https://www.ovirt.org/privacy-policy.html
>oVirt Code of Conduct:
>https://www.ovirt.org/community/about/community-guidelines/
>List Archives:
>https://lists.ovirt.org/archives/list/users@ovirt.org/message/GRFKSI6QYZCGDKM3GYMKW7TY4DZ4CKAI/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QDOHNYDALQASFWKLQ2VFMC7VYAXLUCJC/


[ovirt-users] Re: very very bad iscsi performance

2020-07-24 Thread Strahil Nikolov via Users
I think that the best test is to:
0. Set only 1  change in the infrastructure
1. Automatically create your VM
2. Install the necessary application on the VM from point 1
3. Restore from backup the state of the App
4. Run a typical workload on the app - for example a bunch of queries that are 
pushed against a typical DB
5. Measure performance during point 4 (for example time of execution)
6. Start over

Anything else  is a waste of time.

Best Regards,
Strahil Nikolov


На 24 юли 2020 г. 13:26:18 GMT+03:00, Stefan Hajnoczi  
написа:
>On Thu, Jul 23, 2020 at 07:25:14AM -0700, Philip Brown wrote:
>> Usually in that kind of situation, if you dont turn on sync-to-disk
>on every write, you get benchmarks that are artificially HIGH.
>> Forcing O_DIRECT slows throughput down.
>> Dont you think the results are bad enough already? :-}
>
>The results that were posted do not show iSCSI performance in isolation
>so it's hard to diagnose the problem.
>
>The page cache is used when the O_DIRECT flag is absent. I/O is not
>sent
>to the disk at all when it can be fulfilled from the page cache in
>memory. Therefore the benchmark is not an accurate indicator of disk
>I/O
>performance.
>
>In addition to this, page cache behavior depends on various factors
>such
>as available free memory, operating system implementation and version,
>etc. This makes it hard to compare results across VMs, different
>machines, etc.
>
>Stefan
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/WH4KFRSFGJCKRVM2VUJGKY26DEX5R2DH/


[ovirt-users] Re: CentOS 8.2, ovVirt 4.4.1.8, SHE -- kernel: device-mapper: core: ovirt-ha-broker: sending ioctl 5401 to DM device without required privilege

2020-07-24 Thread Dmitry Kharlamov
If it does not make it difficult, please tell me at least the general direction 
in which you need to look for a solution to my problem?

Unfortunately, at the moment, I am not able to subscribe to get access to 
RedHat Customer Portal.

Thank you in advance.
Dmitry
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GRFKSI6QYZCGDKM3GYMKW7TY4DZ4CKAI/


[ovirt-users] Re: problem with custom bond options

2020-07-24 Thread Jiří Sléžka
On 7/24/20 11:36 AM, Jiří Sléžka wrote:
> On 7/24/20 10:56 AM, Ales Musil wrote:
>>
>>
>> On Fri, Jul 24, 2020 at 10:40 AM Jiří Sléžka > > wrote:
>>
>> On 7/23/20 2:07 PM, Jiří Sléžka wrote:
>> > On 7/23/20 12:35 PM, Ales Musil wrote:
>> >>
>> >>
>> >> On Thu, Jul 23, 2020 at 11:50 AM Jiří Sléžka > 
>> >> >> wrote:
>> >>
>> >>     On 7/23/20 11:03 AM, Ales Musil wrote:
>> >>     >
>> >>     >
>> >>     > On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka
>> mailto:jiri.sle...@slu.cz>
>> >>     >
>> >>     > 
>> > >>     >
>> >>     >     Hi,
>> >>     >
>> >>     >     On 7/23/20 8:38 AM, Ales Musil wrote:
>> >>     >     >
>> >>     >     >
>> >>     >     > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka
>> >>     mailto:jiri.sle...@slu.cz>
>> >
>> >>     >     
>> >>
>> >>     >     > >  > >
>> >>     
>>  wrote:
>> >>     >     >
>> >>     >     >     Hello,
>> >>     >     >
>> >>     >     >
>> >>     >     > Hi,
>> >>     >     >
>> >>     >     >
>> >>     >     >     CentOS8, oVirt 4.4.1.10-1.el8
>> >>     >     >
>> >>     >     >     I am trying to setup active-backup (mode=1)
>> bonding mode
>> >>     with
>> >>     >     custom
>> >>     >     >     properties. I have one 10GE switch, the second is
>> just 1G.
>> >>     >     10GE link is
>> >>     >     >     the primary one.
>> >>     >     >
>> >>     >     >     cat /etc/sysconfig/network-scripts/ifcfg-bond0
>> >>     >     >
>> >>     >     >
>> >>     >     > first of all in oVirt 4.4 the network-scripts are not
>> relevant
>> >>     >     anymore.
>> >>     >     > More relevant is output from 'nmstatectl show'.
>> >>     >
>> >>     >     thanks, I believed that ifcfg files still describes saved
>> >>     interface
>> >>     >     configuration (even on nm managed interfaces)...
>> >>     >
>> >>     >
>> >>     > It does but it might not be that detailed as we would have
>> hoped for.
>> >>     > Another reason why I said that it is not relevant is of
>> course if
>> >>     > someone tries
>> >>     > reconfigure the interface through network-scripts.
>> >>
>> >>     well, honestly I did that (modified ifcfg and then use nmcli con
>> >>     reload). So right way is using nmcli con modify command?
>> >>
>> >>
>> >> Yes or nmstate. Just be aware that anything that you do to interface
>> >> outside of oVirt can have harmful impacts on the host and overall
>> oVirt
>> >> state.
>> >>  
>> >>
>> >>
>> >>     >     from nmstatectl show I can see that bond0 has specified mac
>> >>     address
>> >>     >
>> >>     >   
>> >>   
>>   
>> https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
>> >>     >
>> >>     >     >     BONDING_OPTS="active_slave=ens5 downdelay=0
>> miimon=100
>> >>     >     >     mode=active-backup primary=ens5 updelay=0"
>> >>     >     >     TYPE=Bond
>> >>     >     >     BONDING_MASTER=yes
>> >>     >     >     PROXY_METHOD=none
>> >>     >     >     BROWSER_ONLY=no
>> >>     >     >     IPV4_FAILURE_FATAL=no
>> >>     >     >     IPV6_DISABLED=yes
>> >>     >     >     IPV6INIT=no
>> >>     >     >     NAME=bond0
>> >>     >     >     UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
>> >>     >     >     DEVICE=bond0
>> >>     >     >     ONBOOT=yes
>> >>     >     >     MTU=9000
>> >>     >     >
>> >>     >     >     When I try to add a custom parameter
>> "fail_over_mac=active"
>> >>     >     (which I
>> >>     >     >     believe could solve my problems with stalled mac
>> >>     addresses in
>> >>     >     switch's
>> >>     >     >     cam table in case of failover) I got...
>> >>     >     >
>> >>     >     >     "Error while executing action HostSetupNetworks:
>> Unexpected
>> >>     >     exception"
>> >>     >     >
>> >>     >     >     ...in manager. In the engine.log it looks like
>> >>     >     >
>> >>     >     >     2020-07-22 21:20:35,774+02 WARN
>> >>     > 

[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-24 Thread Florian Schmid via Users
Hi Didi,

thank you very much for your help.

We will use the FQDN as hostname. This seems to work fine and it will report 
the full name again in oVirt.

BR Florian

- Ursprüngliche Mail -
Von: "Yedidyah Bar David" 
An: "Florian Schmid" 
CC: "Tomas Golembiovsky" , "Sandro Bonazzola" 
, "users" 
Gesendet: Donnerstag, 23. Juli 2020 12:01:14
Betreff: Re: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

On Thu, Jul 23, 2020 at 10:23 AM Florian Schmid  wrote:
>
> Hello Yedidyah,
>
> thank you for this great answer.
>
> I will answer in the text below.
>
> BR Florian
>
>
> - Ursprüngliche Mail -
> Von: "Yedidyah Bar David" 
> An: "Florian Schmid" 
> CC: "Tomas Golembiovsky" , "Sandro Bonazzola" 
> , "users" 
> Gesendet: Donnerstag, 23. Juli 2020 08:37:21
> Betreff: Re: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN
>
> On Wed, Jul 22, 2020 at 5:34 PM Florian Schmid via Users
>  wrote:
> >>
> >> Hi,
> >>
> >> after digging a bit deeper, it looks like it is the problem with the 
> >> qemu-guest-agent.
> >>
> >> It does only report the hostname and nothing more. It uses this function: 
> >> g_get_host_name ()
> >>
> >> This function always returns the value in /etc/hostname and this is 
> >> normally the short name of the VM without the domain part.
> >>
> >> It looks like, that the ovirt-guest-agent made this different,
> >
> >Indeed, and from checking the git log, it seems like it did this since
> >the very first commit - already then,
> >ovirt-guest-agent/GuestAgentLinux2.py had:
> >def getMachineName(self):
> >return socket.getfqdn()
>
> Correct, this is what I wanted back.
>
> >
> >> but this is not working anymore with python 3.
> >
> >If in "this" you refer to ovirt-guest-agent, then it's deprecated:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=1672732
>
> Yes, I know. Now using the QGA with oVirt 4.3 reports only the short hostname.
>
> >
> >>
> >> There was a recent patch for qga -> 
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1845127
> >
> >This bug seems to discuss something else, not directly related to your
> >own issue.
> >
> >> but this won't help me, because even when this patch would add the FQDN to 
> >> oVirt back, there won't be a package for this for Ubuntu 20.04 and 
> >> probably also not for RedHat/CentOS 8.
> >
> >Not sure what you mean here. The bug is on qga, and fixing it (or your
> >own issue) is unrelated to oga's deprecation.
>
> I wanted to say, that this change might also impact the reported hostname, 
> but I don't think so...
>
> >
> >Your issue seems to be, to me:
> >
> >1. oga used to report the FQDN, as returned by python's socket.getfqdn()
> >2. qga returns something else (and this something else might be
> >changed, following above bug, but likely not to what you want).
> >3. oVirt now uses qga instead of oga, thus changing its past behavior.
> >4. You want the old behavior back - basically, claiming this is a regression.
>
> Yes, exactly.
>
> >
> >If so, then:
> >
> >1. You are welcome to open a bug about this, on qga.
> >2. Your request *might* be rejected, on the ground of breaking
> >compatibility for existing/old users of qga (say, using virt-manager
> >or whatever other virt tool, without oga installed)
>
> I'm 100 % sure, that they will reject this.
>
> >
> >Alternatively, or if this bug is rejected, you can open two new bugs:
> >
> >1. one on qga, to provide the fqdn (using, hopefully, logic similar to
> >python's getfqdn, although qga is written in C)
>
> Possible, but this won't help me a lot, because even if they add a new 
> function to qga, oVirt would need to be changed too, to access this function 
> instead of the one it is using now.
>
> >2. other on the oVirt engine, to use this new functionality of qga
> >instead of the existing one.
>
> Yes.
>
> >
> >You also have another alternative - just adapt your machines to have
> >the fqdn as the hostname. I personally think this is the best way to
> >go. Have 'hostname' return the FQDN you want, and only use 'hostname
> >-s' where you really want it to be short. How do you set the hostnames
> >of your machines?
>
> This is what I don't know, if this has some drawbacks.
> I have checked this on internet, but haven't find a lot about it, what is 
> digging deeper.
>
> Maybe someone here has some experience with using FQDN for hostname?

I use this on all my machines (CentOS/RHEL ones, anyway) and all seems ok.
I do recommend, obviously, that you do your own research/testing.

>
> I can live with such a solution, when it doesn't have big drawbacks...

The only actual drawback I can think of is that the hostname is limited
to 64 chars, whereas the FQDN can be up to 255 chars. So if you want a
longer FQDN, you can't use it as the hostname.

Another obvious drawback is that applications that use the full hostname
for reporting, as opposed to explicitly using 'hostname -s', will now
have the FQDN in their reports, which you might find too long 

[ovirt-users] Re: New ovirt 4.4.0.3-1.el8 leaves disks in illegal state on all snapshot actions

2020-07-24 Thread Henri Aanstoot
thanks, started upgrading nodes

After running ovirt (manual install) for 5+ years without problem .. (did
yust a few upgrades)
I've bought myself 2 big hypervisors and started from image based installs.
4.4.0 installed but snapshots problems ...
upgrade was a hell due to dependency  failures, there where duplicates
rpm/repos

started with 4.4.1-2020071311 .. python2 known problem ... damn
4.4.1-2020070811 .. boot problems after install, install from running 4.4.0
hypervisor with upgraded engine .. install failed times after times .. repo
error/python error

my old manual install worked/installed without problem, why problems with
image based?

Well .. going to be reinstalling/upgrading to 4.4.1 .. and hoping to
recover my vm's

On Thu, 23 Jul 2020 at 09:57, Benny Zlotnik  wrote:

> it was fixed[1], you need to upgrade to libvirt 6+ and qemu 4.2+
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1785939
>
>
> On Thu, Jul 23, 2020 at 9:59 AM Henri Aanstoot  wrote:
>
>>
>>
>>
>>
>> Hi all,
>>
>> I've got 2 two node setup, image based installs.
>> When doing ova exports or generic snapshots, things seem in order.
>> Removing snapshots shows warning 'disk in illegal state'
>>
>> Mouse hover shows .. please do not shutdown before succesfully remove
>> snapshot
>>
>>
>> ovirt-engine log
>> 2020-07-22 16:40:37,549+02 ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (EE-ManagedExecutorService-commandCoordinator-Thread-2)
>> [264b0047-5aa6-4380-9d32-eb328fd6bed0] EVENT_ID:
>> VDS_BROKER_COMMAND_FAILURE(10,802), VDSM node2.lab command MergeVDS failed:
>> Merge failed
>> 2020-07-22 16:40:37,549+02 ERROR
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.MergeVDSCommand]
>> (EE-ManagedExecutorService-commandCoordinator-Thread-2)
>> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Command 'MergeVDSCommand(HostName =
>> node2.lab,
>> MergeVDSCommandParameters:{hostId='02df5213-1243-4671-a1c6-6489d7146319',
>> vmId='64c25543-bef7-4fdd-8204-6507046f5a34',
>> storagePoolId='5a4ea80c-b3b2-11ea-a890-00163e3cb866',
>> storageDomainId='9a12f1b2-5378-46cc-964d-3575695e823f',
>> imageGroupId='3f7ac8d8-f1ab-4c7a-91cc-f34d0b8a1cb8',
>> imageId='c757e740-9013-4ae0-901d-316932f4af0e',
>> baseImageId='ebe50730-dec3-4f29-8a38-9ae7c59f2aef',
>> topImageId='c757e740-9013-4ae0-901d-316932f4af0e', bandwidth='0'})'
>> execution failed: VDSGenericException: VDSErrorException: Failed to
>> MergeVDS, error = Merge failed, code = 52
>> 2020-07-22 16:40:37,549+02 ERROR [org.ovirt.engine.core.bll.MergeCommand]
>> (EE-ManagedExecutorService-commandCoordinator-Thread-2)
>> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Engine exception thrown while
>> sending merge command: org.ovirt.engine.core.common.errors.EngineException:
>> EngineException:
>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
>> VDSGenericException: VDSErrorException: Failed to MergeVDS, error = Merge
>> failed, code = 52 (Failed with error mergeErr and code 52)
>> Caused by: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
>> VDSGenericException: VDSErrorException: Failed to MergeVDS, error = Merge
>> failed, code = 52
>>   
>>   > io='threads'/>
>> 2020-07-22 16:40:39,659+02 ERROR
>> [org.ovirt.engine.core.bll.MergeStatusCommand]
>> (EE-ManagedExecutorService-commandCoordinator-Thread-3)
>> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Failed to live merge. Top volume
>> c757e740-9013-4ae0-901d-316932f4af0e is still in qemu chain
>> [ebe50730-dec3-4f29-8a38-9ae7c59f2aef, c757e740-9013-4ae0-901d-316932f4af0e]
>> 2020-07-22 16:40:41,524+02 ERROR
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-58)
>> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Command id:
>> 'e0b2bce7-afe0-4955-ae46-38bcb8719852 failed child command status for step
>> 'MERGE_STATUS'
>> 2020-07-22 16:40:42,597+02 ERROR
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-53)
>> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Merging of snapshot
>> 'ef8f7e06-e48c-4a8c-983c-64e3d4ebfcf9' images
>> 'ebe50730-dec3-4f29-8a38-9ae7c59f2aef'..'c757e740-9013-4ae0-901d-316932f4af0e'
>> failed. Images have been marked illegal and can no longer be previewed or
>> reverted to. Please retry Live Merge on the snapshot to complete the
>> operation.
>> 2020-07-22 16:40:42,603+02 ERROR
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-53)
>> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Ending command
>> 'org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand'
>> with failure.
>> 2020-07-22 16:40:43,679+02 ERROR
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand]
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-15)
>> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Ending 

[ovirt-users] Re: very very bad iscsi performance

2020-07-24 Thread Stefan Hajnoczi
On Thu, Jul 23, 2020 at 07:25:14AM -0700, Philip Brown wrote:
> Usually in that kind of situation, if you dont turn on sync-to-disk on every 
> write, you get benchmarks that are artificially HIGH.
> Forcing O_DIRECT slows throughput down.
> Dont you think the results are bad enough already? :-}

The results that were posted do not show iSCSI performance in isolation
so it's hard to diagnose the problem.

The page cache is used when the O_DIRECT flag is absent. I/O is not sent
to the disk at all when it can be fulfilled from the page cache in
memory. Therefore the benchmark is not an accurate indicator of disk I/O
performance.

In addition to this, page cache behavior depends on various factors such
as available free memory, operating system implementation and version,
etc. This makes it hard to compare results across VMs, different
machines, etc.

Stefan


signature.asc
Description: PGP signature
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QZCYB2SRTSMF6RL3S7HH5U4J6MXZDHV3/


[ovirt-users] Re: problem with custom bond options

2020-07-24 Thread Jiří Sléžka
On 7/24/20 10:56 AM, Ales Musil wrote:
> 
> 
> On Fri, Jul 24, 2020 at 10:40 AM Jiří Sléžka  > wrote:
> 
> On 7/23/20 2:07 PM, Jiří Sléžka wrote:
> > On 7/23/20 12:35 PM, Ales Musil wrote:
> >>
> >>
> >> On Thu, Jul 23, 2020 at 11:50 AM Jiří Sléžka  
> >> >> wrote:
> >>
> >>     On 7/23/20 11:03 AM, Ales Musil wrote:
> >>     >
> >>     >
> >>     > On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka
> mailto:jiri.sle...@slu.cz>
> >>     >
> >>     > 
>  >>     >
> >>     >     Hi,
> >>     >
> >>     >     On 7/23/20 8:38 AM, Ales Musil wrote:
> >>     >     >
> >>     >     >
> >>     >     > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka
> >>     mailto:jiri.sle...@slu.cz>
> >
> >>     >     
> >>
> >>     >     >    >
> >>     
>  wrote:
> >>     >     >
> >>     >     >     Hello,
> >>     >     >
> >>     >     >
> >>     >     > Hi,
> >>     >     >
> >>     >     >
> >>     >     >     CentOS8, oVirt 4.4.1.10-1.el8
> >>     >     >
> >>     >     >     I am trying to setup active-backup (mode=1)
> bonding mode
> >>     with
> >>     >     custom
> >>     >     >     properties. I have one 10GE switch, the second is
> just 1G.
> >>     >     10GE link is
> >>     >     >     the primary one.
> >>     >     >
> >>     >     >     cat /etc/sysconfig/network-scripts/ifcfg-bond0
> >>     >     >
> >>     >     >
> >>     >     > first of all in oVirt 4.4 the network-scripts are not
> relevant
> >>     >     anymore.
> >>     >     > More relevant is output from 'nmstatectl show'.
> >>     >
> >>     >     thanks, I believed that ifcfg files still describes saved
> >>     interface
> >>     >     configuration (even on nm managed interfaces)...
> >>     >
> >>     >
> >>     > It does but it might not be that detailed as we would have
> hoped for.
> >>     > Another reason why I said that it is not relevant is of
> course if
> >>     > someone tries
> >>     > reconfigure the interface through network-scripts.
> >>
> >>     well, honestly I did that (modified ifcfg and then use nmcli con
> >>     reload). So right way is using nmcli con modify command?
> >>
> >>
> >> Yes or nmstate. Just be aware that anything that you do to interface
> >> outside of oVirt can have harmful impacts on the host and overall
> oVirt
> >> state.
> >>  
> >>
> >>
> >>     >     from nmstatectl show I can see that bond0 has specified mac
> >>     address
> >>     >
> >>     >   
> >>   
>   
> https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
> >>     >
> >>     >     >     BONDING_OPTS="active_slave=ens5 downdelay=0
> miimon=100
> >>     >     >     mode=active-backup primary=ens5 updelay=0"
> >>     >     >     TYPE=Bond
> >>     >     >     BONDING_MASTER=yes
> >>     >     >     PROXY_METHOD=none
> >>     >     >     BROWSER_ONLY=no
> >>     >     >     IPV4_FAILURE_FATAL=no
> >>     >     >     IPV6_DISABLED=yes
> >>     >     >     IPV6INIT=no
> >>     >     >     NAME=bond0
> >>     >     >     UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
> >>     >     >     DEVICE=bond0
> >>     >     >     ONBOOT=yes
> >>     >     >     MTU=9000
> >>     >     >
> >>     >     >     When I try to add a custom parameter
> "fail_over_mac=active"
> >>     >     (which I
> >>     >     >     believe could solve my problems with stalled mac
> >>     addresses in
> >>     >     switch's
> >>     >     >     cam table in case of failover) I got...
> >>     >     >
> >>     >     >     "Error while executing action HostSetupNetworks:
> Unexpected
> >>     >     exception"
> >>     >     >
> >>     >     >     ...in manager. In the engine.log it looks like
> >>     >     >
> >>     >     >     2020-07-22 21:20:35,774+02 WARN
> >>     >     >   
> >>     >   
> >>   
>    [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >>     >     >     (default task-8)
>  

[ovirt-users] Re: problem with custom bond options

2020-07-24 Thread Ales Musil
On Fri, Jul 24, 2020 at 10:40 AM Jiří Sléžka  wrote:

> On 7/23/20 2:07 PM, Jiří Sléžka wrote:
> > On 7/23/20 12:35 PM, Ales Musil wrote:
> >>
> >>
> >> On Thu, Jul 23, 2020 at 11:50 AM Jiří Sléžka  >> > wrote:
> >>
> >> On 7/23/20 11:03 AM, Ales Musil wrote:
> >> >
> >> >
> >> > On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka  >> 
> >> > >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > On 7/23/20 8:38 AM, Ales Musil wrote:
> >> > >
> >> > >
> >> > > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka
> >> mailto:jiri.sle...@slu.cz>
> >> > >
> >> > > 
> >>  >> > >
> >> > > Hello,
> >> > >
> >> > >
> >> > > Hi,
> >> > >
> >> > >
> >> > > CentOS8, oVirt 4.4.1.10-1.el8
> >> > >
> >> > > I am trying to setup active-backup (mode=1) bonding mode
> >> with
> >> > custom
> >> > > properties. I have one 10GE switch, the second is just
> 1G.
> >> > 10GE link is
> >> > > the primary one.
> >> > >
> >> > > cat /etc/sysconfig/network-scripts/ifcfg-bond0
> >> > >
> >> > >
> >> > > first of all in oVirt 4.4 the network-scripts are not
> relevant
> >> > anymore.
> >> > > More relevant is output from 'nmstatectl show'.
> >> >
> >> > thanks, I believed that ifcfg files still describes saved
> >> interface
> >> > configuration (even on nm managed interfaces)...
> >> >
> >> >
> >> > It does but it might not be that detailed as we would have hoped
> for.
> >> > Another reason why I said that it is not relevant is of course if
> >> > someone tries
> >> > reconfigure the interface through network-scripts.
> >>
> >> well, honestly I did that (modified ifcfg and then use nmcli con
> >> reload). So right way is using nmcli con modify command?
> >>
> >>
> >> Yes or nmstate. Just be aware that anything that you do to interface
> >> outside of oVirt can have harmful impacts on the host and overall oVirt
> >> state.
> >>
> >>
> >>
> >> > from nmstatectl show I can see that bond0 has specified mac
> >> address
> >> >
> >> >
> >>
> https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
> >> >
> >> > > BONDING_OPTS="active_slave=ens5 downdelay=0 miimon=100
> >> > > mode=active-backup primary=ens5 updelay=0"
> >> > > TYPE=Bond
> >> > > BONDING_MASTER=yes
> >> > > PROXY_METHOD=none
> >> > > BROWSER_ONLY=no
> >> > > IPV4_FAILURE_FATAL=no
> >> > > IPV6_DISABLED=yes
> >> > > IPV6INIT=no
> >> > > NAME=bond0
> >> > > UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
> >> > > DEVICE=bond0
> >> > > ONBOOT=yes
> >> > > MTU=9000
> >> > >
> >> > > When I try to add a custom parameter
> "fail_over_mac=active"
> >> > (which I
> >> > > believe could solve my problems with stalled mac
> >> addresses in
> >> > switch's
> >> > > cam table in case of failover) I got...
> >> > >
> >> > > "Error while executing action HostSetupNetworks:
> Unexpected
> >> > exception"
> >> > >
> >> > > ...in manager. In the engine.log it looks like
> >> > >
> >> > > 2020-07-22 21:20:35,774+02 WARN
> >> > >
> >> >
> >>
>[org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >> > > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> >> Unexpected
> >> > > return value: Status [code=-32603, message=Internal
> JSON-RPC
> >> > error:
> >> > > {'reason': 'MAC address cannot be specified in bond
> >> interface
> >> > along with
> >> > > specified bond options'}]
> >> > > 2020-07-22 21:20:35,774+02 ERROR
> >> > >
> >> >
> >>
>[org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >> > > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> >> Failed in
> >> > > 'HostSetupNetworksVDS' method
> >> > > 2020-07-22 21:20:35,774+02 WARN
> >> > >
> >> >
> >>
>[org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >> > > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> >> Unexpected
> >> > > return value: Status [code=-32603, message=Internal
> JSON-RPC
> >> > error:
> >>

[ovirt-users] Re: problem with custom bond options

2020-07-24 Thread Jiří Sléžka
On 7/23/20 2:07 PM, Jiří Sléžka wrote:
> On 7/23/20 12:35 PM, Ales Musil wrote:
>>
>>
>> On Thu, Jul 23, 2020 at 11:50 AM Jiří Sléžka > > wrote:
>>
>> On 7/23/20 11:03 AM, Ales Musil wrote:
>> >
>> >
>> > On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka > 
>> > >> wrote:
>> >
>> >     Hi,
>> >
>> >     On 7/23/20 8:38 AM, Ales Musil wrote:
>> >     >
>> >     >
>> >     > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka
>> mailto:jiri.sle...@slu.cz>
>> >     >
>> >     > 
>> > >     >
>> >     >     Hello,
>> >     >
>> >     >
>> >     > Hi,
>> >     >
>> >     >
>> >     >     CentOS8, oVirt 4.4.1.10-1.el8
>> >     >
>> >     >     I am trying to setup active-backup (mode=1) bonding mode
>> with
>> >     custom
>> >     >     properties. I have one 10GE switch, the second is just 1G.
>> >     10GE link is
>> >     >     the primary one.
>> >     >
>> >     >     cat /etc/sysconfig/network-scripts/ifcfg-bond0
>> >     >
>> >     >
>> >     > first of all in oVirt 4.4 the network-scripts are not relevant
>> >     anymore.
>> >     > More relevant is output from 'nmstatectl show'.
>> >
>> >     thanks, I believed that ifcfg files still describes saved
>> interface
>> >     configuration (even on nm managed interfaces)...
>> >
>> >
>> > It does but it might not be that detailed as we would have hoped for.
>> > Another reason why I said that it is not relevant is of course if
>> > someone tries
>> > reconfigure the interface through network-scripts.
>>
>> well, honestly I did that (modified ifcfg and then use nmcli con
>> reload). So right way is using nmcli con modify command?
>>
>>
>> Yes or nmstate. Just be aware that anything that you do to interface
>> outside of oVirt can have harmful impacts on the host and overall oVirt
>> state.
>>  
>>
>>
>> >     from nmstatectl show I can see that bond0 has specified mac
>> address
>> >
>> >   
>>  
>> https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
>> >
>> >     >     BONDING_OPTS="active_slave=ens5 downdelay=0 miimon=100
>> >     >     mode=active-backup primary=ens5 updelay=0"
>> >     >     TYPE=Bond
>> >     >     BONDING_MASTER=yes
>> >     >     PROXY_METHOD=none
>> >     >     BROWSER_ONLY=no
>> >     >     IPV4_FAILURE_FATAL=no
>> >     >     IPV6_DISABLED=yes
>> >     >     IPV6INIT=no
>> >     >     NAME=bond0
>> >     >     UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
>> >     >     DEVICE=bond0
>> >     >     ONBOOT=yes
>> >     >     MTU=9000
>> >     >
>> >     >     When I try to add a custom parameter "fail_over_mac=active"
>> >     (which I
>> >     >     believe could solve my problems with stalled mac
>> addresses in
>> >     switch's
>> >     >     cam table in case of failover) I got...
>> >     >
>> >     >     "Error while executing action HostSetupNetworks: Unexpected
>> >     exception"
>> >     >
>> >     >     ...in manager. In the engine.log it looks like
>> >     >
>> >     >     2020-07-22 21:20:35,774+02 WARN
>> >     >   
>> >   
>>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
>> >     >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
>> Unexpected
>> >     >     return value: Status [code=-32603, message=Internal JSON-RPC
>> >     error:
>> >     >     {'reason': 'MAC address cannot be specified in bond
>> interface
>> >     along with
>> >     >     specified bond options'}]
>> >     >     2020-07-22 21:20:35,774+02 ERROR
>> >     >   
>> >   
>>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
>> >     >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
>> Failed in
>> >     >     'HostSetupNetworksVDS' method
>> >     >     2020-07-22 21:20:35,774+02 WARN
>> >     >   
>> >   
>>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
>> >     >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
>> Unexpected
>> >     >     return value: Status [code=-32603, message=Internal JSON-RPC
>> >     error:
>> >     >     {'reason': 'MAC address cannot be specified in bond
>> interface
>> >     along with
>> >     >     specified bond options'}]
>> >     >     2020-07-22 21:20:35,811+02 ERROR
>> >     >   
>> >   
>>   

[ovirt-users] Re: 4.4.x - VLAN-based logical network can't attach to bonds?

2020-07-24 Thread Dominik Holler
Hello Mark,
we are highly interested in this issue.
Can you please create a bug
 for oVirt with
reproduction steps?

If you have the opportunity, it would be interesting to know if the new
NetworkManager 1.26 from
https://copr.fedorainfracloud.org/coprs/networkmanager/NetworkManager-1.26/
would fix the problem already.

Thanks
Dominik


On Thu, Jul 23, 2020 at 3:56 PM Mark R  wrote:

> Hello Ales,
>
> > can you please share supervdsm.log from the relevant host?
>
> Absolutely! Here is the log from the point of opening the "Setup Host
> Networks" UI, as I just drag the "LegacyDMZ" network over onto the same
> bond that's running ovirtmgmt and click "OK".
>
>
> #-8<--8<-8<
>
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,627::supervdsm_server::93::SuperVdsm.ServerCallback::(wrapper)
> call get_lldp_info with ({'devices': []},) {}
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,631::routes::115::root::(get_gateway) The gateway 172.17.96.1 is
> duplicated for the device ovirtmgmt
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,634::routes::115::root::(get_gateway) The gateway 172.17.96.1 is
> duplicated for the device ovirtmgmt
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,635::cmdutils::130::root::(exec_cmd) /sbin/tc qdisc show (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,643::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,644::cmdutils::130::root::(exec_cmd) /sbin/tc class show dev
> eno34np1 classid 0:1388 (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,649::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,649::cmdutils::130::root::(exec_cmd) /sbin/tc class show dev
> ens2f1np1 classid 0:1388 (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,655::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,699::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-lldp
> -i eno33np0 adminStatus (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,706::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,706::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-tlv -n
> -i eno33np0 (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,712::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,713::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-lldp
> -i eno34np1 adminStatus (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,718::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,719::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-tlv -n
> -i eno34np1 (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,724::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,725::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-lldp
> -i ens2f0np0 adminStatus (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,729::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,730::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-tlv -n
> -i ens2f0np0 (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,735::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,736::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-lldp
> -i ens2f1np1 adminStatus (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,740::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,741::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-tlv -n
> -i ens2f1np1 (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,745::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
> MainProcess|jsonrpc/4::DEBUG::2020-07-23
> 13:37:35,746::supervdsm_server::100::SuperVdsm.ServerCallback::(wrapper)
> return get_lldp_info with {'eno33np0': {'enabled': True, 'tlvs': [{'type':
> 1, 'name': 'Chassis ID', 'properties': {'chassis ID subtype': 'MAC',
> 'chassis ID': '8c:04:ba:e9:21:40'}}, {'type': 2, 'name': 'Port ID',
> 'properties': {'port ID subtype': 'Ifname', 'port ID': 'ethernet1/1/16'}},
> {'type': 3, 'name': 'Time to Live', 'properties': {'time to live': '120'}},
> {'type': 4, 'name': 'Port Description', 'properties': {'port description':
> 'Part of VLT LACP trunk to rack4slot15 - em3'}}, {'type': 5, 'name':
> 'System Name', 'properties': {'system name': 'TOR-4-A'}}, {'type': 6,
> 'name': 'System Description', 'properties': {'system description': 'Dell
> EMC Networking OS10 

[ovirt-users] Re: CentOS 8.2, ovVirt 4.4.1.8, SHE -- kernel: device-mapper: core: ovirt-ha-broker: sending ioctl 5401 to DM device without required privilege

2020-07-24 Thread Dmitry Kharlamov
Thanks for the answer, but access to this information requires a Red Hut 
subscription, which I, unfortunately, do not have ... ((

Dmitry
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VT4K4J5H57KCR4JOJBML6GIGJ5J4OO7L/


[ovirt-users] Re: CentOS 8.2, ovVirt 4.4.1.8, SHE -- kernel: device-mapper: core: ovirt-ha-broker: sending ioctl 5401 to DM device without required privilege

2020-07-24 Thread Nir Soffer
On Thu, Jul 23, 2020 at 1:16 PM Dmitry Kharlamov  wrote:
>
> Good day!
> CentOS 8.2.2004 (Core), ovVirt 4.4.1.8-1.el8, storage type FC with 
> multipathing.
>
> Please tell me what could be the problem.
>
> Messages are constantly poured into the console and / var / log / messages:
> kernel: device-mapper: core: ovirt-ha-broker: sending ioctl 5401 to DM device 
> without required privilege
>
> Messages appeared during the installation process (SHE via CLI), during the 
> LUN partitioning phase, and after that they do not stop.
> At the same time, the installation was successful and now everything is 
> working fine.
>
> A similar problem is described here, but no solution has been proposed:
> https://bugzilla.redhat.com/show_bug.cgi?id=1838453

See https://access.redhat.com/solutions/2189851:

Resolution
The messages are benign and can be ignored.


Nir
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CXHKRXJPDKB54AGKWRL2J3JLGFVYZ6IO/