[ovirt-users] Re: Can NFV (Network Functions Virtualization) work on oVirt?

2021-01-07 Thread Dominik Holler
On Tue, Jan 5, 2021 at 9:34 AM fukumoto.shi...@fujitsu.com <
fukumoto.shi...@fujitsu.com> wrote:

> Hello Gianluca,
>
>
>
> Thank you for the links.
>
> I read the documents and understood SR-IOV is supported.
>
>
>
> This is a question apart from NFV, I need RDMA (InfiniBand) and RDMA
> (Ethernet) using Mellanox ConnextX-6 cards.
>
> Do you (or does anyone) know if RDMA (InfiniBand) and RDMA (Ethernet) work
> on oVirt environment?
>
>
>

Should RDMA be used inside the VM, or on the oVirt host directly?
On host level only IPoIB should work on CentOS 7 and on CentOS >= 8.4, RDMA
is not supported.
But it would be interesting to know if RDMA would work on a SR-IOV VF
inside a VM.


> I found following MLNX_OFED documentation and it seems that RDMA will work
> with SR-IOV.
>
> https://docs.mellanox.com/pages/viewpage.action?pageId=39264752
>
>
>
> Regards,
>
> Fukumoto
>
>
>
> *From:* Gianluca Cecchi 
> *Sent:* Monday, January 4, 2021 6:26 PM
> *To:* Fukumoto, Shinya/福本 真也 
> *Cc:* users@ovirt.org
> *Subject:* Re: [ovirt-users] Can NFV (Network Functions Virtualization)
> work on oVirt?
>
>
>
> On Mon, Jan 4, 2021 at 10:04 AM fukumoto.shi...@fujitsu.com <
> fukumoto.shi...@fujitsu.com> wrote:
>
> Hello everyone,
>
> I've checked the documentation of oVirt, but cannot find if following
> function can work on oVirt or not.
> - NFV (Network Functions Virtualization)
>
> Does someone know NFV can work on oVirt?
>
> For your reference, Red Hat OpenStack Platform seems to support NFV as
> follows
>
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/12/html-single/network_functions_virtualization_product_guide/index
>
> Regards,
> Fukumoto
>
>
>
> I think you can find useful information here for RHV 4.4, that should be
> applicable to oVirt 4.4 too:
>
>
>
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/sect-virtual_network_interface_cards#Enabling_Passthrough_on_a_vNIC_Profile
>
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/sect-hosts_and_networking#setting-up-and-configuring-sr-iov
>
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/hardware_considerations_for_implementing_sr-iov/
>
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/virtual_machine_management_guide/sect-migrating_virtual_machines_between_hosts#Live_migration_prerequisites
>
>
>
> I don't know if it is supported to also use NFV with OVN external provider
> in oVirt/RHV
>
>
>
> HIH,
>
> Gianluca
> ___
> 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/GIOGKOQRLCMUSPPPIZ7IQSHDY2NK22FJ/
>
___
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/DRAW46VMBXEWXJ4OUBUA6N4VBUXLHNP7/


[ovirt-users] Re: Upgrade from 4.4.3 to 4.4.4 (oVirt Node) - vdsmd.service/start failed with result 'dependency'

2021-01-04 Thread Dominik Holler
Hello Marco,
can you please check the owner and groups of
/etc/openvswitch/ and
/var/run/openvswitch
and the files in these directories ?

Are there any hints if this issue might be related to
*Bug 1909782*  -
/etc/openvswitch
permissions broken after upgrade
?

Dominik

On Mon, Jan 4, 2021 at 7:29 AM Ales Musil  wrote:

>
>
> On Thu, Dec 24, 2020 at 5:14 PM Marco Fais  wrote:
>
>> Hi,
>>
>> just a quick correction on the below --
>> the dependency chain is vdsmd --> vdsm-network --> openvswitch -->
>> ovsdb-server (failed)
>>
>> The conf.db file and /var/run/openvswitch dir are in 4.4.3 but not in
>> 4.4.4
>> In 4.4.3 looks like the vdsm-network service does not depend from
>> openvswitch:
>>
>> *4.4.3* --
>> [Unit]
>> Description=Virtual Desktop Server Manager network restoration
>> Wants=network.target
>> Requires=libvirtd.service
>> After=libvirtd.service
>>
>> *4.4.4* --
>> [Unit]
>> Description=Virtual Desktop Server Manager network restoration
>> Wants=network.target
>> Requires=libvirtd.service openvswitch.service NetworkManager.service
>> After=libvirtd.service openvswitch.service NetworkManager.service
>>
>> Regards,
>> Marco
>>
>>
>> On Thu, 24 Dec 2020 at 12:29, Marco Fais  wrote:
>>
>>> Hi all,
>>>
>>> I have just upgraded one of my oVirt nodes from 4.4.3 to 4.4.4.
>>>
>>> After the reboot, the 4.4.4 image is correctly loaded but vdsmd is not
>>> starting due to this error:
>>>
>>> vdsmd.service: Job vdsmd.service/start failed with result 'dependency'.
>>>
>>> Looks like it has a dependency on mom-vdsm, and this as well has a
>>> dependency issue:
>>>
>>> mom-vdsm.service: Job mom-vdsm.service/start failed with result
>>> 'dependency'.
>>>
>>> After some investigation looks like mom-vdsm has a dependency
>>> on ovsdb-server, and this is the unit creating the problem:
>>>
>>> ovs-delete-transient-ports.service: Starting requested but asserts
>>> failed.
>>> Assertion failed for Open vSwitch Delete Transient Ports
>>> Failed to start Open vSwitch Database Unit.
>>>
>>> Details below:
>>> -- Unit ovsdb-server.service has begun starting up.
>>> Dec 24 12:21:57 LAB-CNVirt-H04.ngv.eircom.net chown[13658]:
>>> /usr/bin/chown: cannot access '/var/run/openvswitch': No such file or
>>> directory
>>> Dec 24 12:21:57 LAB-CNVirt-H04.ngv.eircom.net ovs-ctl[13667]:
>>> /etc/openvswitch/conf.db does not exist ... (warning).
>>> Dec 24 12:21:57 LAB-CNVirt-H04.ngv.eircom.net ovsdb-tool[13714]:
>>> ovs|1|lockfile|WARN|/etc/openvswitch/.conf.db.~lock~: failed to open
>>> lock file: Permission denied
>>> Dec 24 12:21:57 LAB-CNVirt-H04.ngv.eircom.net ovs-ctl[13667]: Creating
>>> empty database /etc/openvswitch/conf.db ovsdb-tool: I/O error:
>>> /etc/openvswitch/conf.db: failed to lock lockfile (Resource temporarily
>>> unavailable)
>>> Dec 24 12:21:57 LAB-CNVirt-H04.ngv.eircom.net ovsdb-tool[13714]:
>>> ovs|2|lockfile|WARN|/etc/openvswitch/.conf.db.~lock~: failed to lock
>>> file: Resource temporarily unavailable
>>> Dec 24 12:21:57 LAB-CNVirt-H04.ngv.eircom.net ovs-ctl[13667]: [FAILED]
>>> Dec 24 12:21:57 LAB-CNVirt-H04.ngv.eircom.net systemd[1]:
>>> ovsdb-server.service: Control process exited, code=exited status=1
>>> Dec 24 12:21:57 LAB-CNVirt-H04.ngv.eircom.net systemd[1]:
>>> ovsdb-server.service: Failed with result 'exit-code'.
>>> -- Subject: Unit failed
>>>
>>> Any suggestions?
>>>
>>> Thanks,
>>> Marco
>>>
>>> ___
>> 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/Z7XM6QW2GP3FQKEVLLYIQDHBZD7PGXC2/
>>
>
>
> Hi,
>
> the dependency on openvswitch comes from 4.4.4 this is correct. However I
> am not entirely sure why openvswitch would refuse to start.
> Do you have some special OvS configuration in place on the affected host?
>
> Thank you.
> Regards,
> Ales
>
> --
>
> Ales Musil
>
> Software Engineer - RHV Network
>
> Red Hat EMEA 
>
> amu...@redhat.comIM: amusil
> 
> ___
> 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/KHG6ISFOUARQ2KR7TERXEIHAQKVEAJTM/
>
___
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: 

[ovirt-users] Re: Network Teamd support

2020-12-16 Thread Dominik Holler
On Fri, Dec 11, 2020 at 1:19 AM Carlos C  wrote:

> Hi folks,
>
> Does Ovirt 4.4.4 support or will support Network Teamd? Or only bonding?
>
>

Currently, oVirt does not support teaming,
but you are welcome to share which the feature you are missing in the
current oVirt bonding implementation in
https://bugzilla.redhat.com/show_bug.cgi?id=1351510

Thanks
Dominik



> regards
> Carlos
> ___
> 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/ABGHHQYZBLO34YXBP4BKX6UGLIOL7IVU/
>
___
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/UWYK4MADCU2ZPDQETOETSSDX546HDR6Q/


[ovirt-users] Re: Ovirt 4 2 NIC's

2020-11-24 Thread Dominik Holler
https://www.ovirt.org/documentation/administration_guide/#Designate_a_Specific_Traffic_Type
documents how to use a display network.

A possible flow could be like this:
1. Create a new logical network, use a VLAN if you do not have a free NIC
on every host
2. Attach the new logical network and attach it in
Compute > Hosts > hostname > Network Interfaces > Setup Host Networks
to a free NIC (or an already used one if the network has a VLAN) for every
host.
This new network attachment should have an IP address.
3. Ensure that your network infrastructure allows the communication of your
users into the display network.
4. Assign the role "Display Network" in
Compute > Clusters > ClusterName > Logical Networks > Manage Networks
to the new network.




> El vie, 20 de nov. de 2020 a la(s) 06:01, Dominik Holler (
> dhol...@redhat.com) escribió:
>
>>
>>
>> On Wed, Nov 18, 2020 at 7:30 PM Facundo Badaracco 
>> wrote:
>>
>>> Hi everyone!
>>>
>>> Hope someone can help me with this..
>>>
>>> I have 3 servers with centos 8 and ovirt 4 installed. Each server has 2
>>> nic.
>>> Server A = HE (HA)
>>> Nic1= 192.169.2.24 Nic2=no ip
>>> Server B = HE (HA)
>>> Nic1= 192.169.2.25 Nic2=no ip
>>> Server C = simply host.
>>> Nic1= 192.169.2.26 Nic2=no ip
>>>
>>> How can i configure the second NIC in each server in order to use it for
>>> clients connect to the vms?. I want one nic for management, the other for
>>> connections.
>>>
>>
>>
>> If the clients want to access network services provided by the VMs,
>> you could create an additional logical network in oVirt, and attach it in
>> Compute > Hosts > hostname > Network Interfaces > Setup Host Networks
>> to Nic2  for every host. This new network attachment should have no IP
>> address.
>> After that, you could reference this new logical network in your VMs
>> virtual NICs.
>> If possible, I would recommend using a VLAN to provide isolation to the
>> management network.
>>
>> If the clients connect via SPICE or VNC, you would require a
>> dedicated display network.
>>
>>
>>
>>> ___
>>> 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/PL7WFXC4UZBUZ45HMZQ7QSRFSMQXRA4A/
>>>
>>
___
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/QYT45I33KFX4NTNPPYHK7Z57MG5SQ6LQ/


[ovirt-users] Re: Replacing ovirt certificates issue

2020-11-24 Thread Dominik Holler
On Tue, Nov 24, 2020 at 8:45 AM Alex K  wrote:

>
>
> On Mon, Nov 23, 2020 at 4:54 PM Alex K  wrote:
>
>>
>>
>> On Mon, Nov 23, 2020 at 9:42 AM Alex K  wrote:
>>
>>>
>>>
>>> On Mon, Nov 23, 2020 at 9:35 AM Dominik Holler 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Nov 20, 2020 at 12:38 PM Alex K 
>>>> wrote:
>>>>
>>>>> Following the above, I was seeing that OVN provider connectivity test
>>>>> was failing due to some certificate issue and had to do the following to
>>>>> fix it:
>>>>>
>>>>> names="ovirt-provider-ovn"
>>>>>
>>>>> subject="$(\
>>>>> openssl x509 \
>>>>> -in /etc/pki/ovirt-engine/certs/apache.cer \
>>>>> -noout \
>>>>> -subject | \
>>>>> sed \
>>>>> 's;subject= \(.*\);\1;'
>>>>>   )"
>>>>>
>>>>> . /usr/share/ovirt-engine/bin/engine-prolog.sh
>>>>>
>>>>> for name in $names; do
>>>>> /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
>>>>> --name="${name}" \
>>>>> --password=mypass \
>>>>> --subject="${subject}" \
>>>>> --keep-key \
>>>>> --san=DNS:"${ENGINE_FQDN}"
>>>>> done
>>>>>
>>>>> Having fixed the above, when trying to connect two VMs on some OVN
>>>>> logical switches it seems they are not able to reach each other.
>>>>> I had previously added such logical switched at engine by running:
>>>>>
>>>>> ovn-nbctl ls-add ovn-net0
>>>>> ovn-nbctl ls-add ovn-net1
>>>>> etc
>>>>>
>>>>>
>>>> Not related: Please use ovirt-provider-ovn to create and manage ovn
>>>> entities.
>>>>
>>>>
>>>>> Checking the logs at the host /var/log/openvswitch/ovsdb-server.log I
>>>>> see:
>>>>> reconnect|WARN|unix#45: connection dropped (Connection reset by peer)
>>>>>
>>>>>
>>>> /var/log/openvswitch/ovn-controller.log might contain the reason.
>>>>
>>>>
>>>>> Also systemctl status ovirt-provider-ovn.service at engine shows:
>>>>> /usr/lib/python2.7/site-packages/urllib3/connection.py:344:
>>>>> SubjectAltNameWarning:...
>>>>>
>>>>>
>>>> Looks not good, do tou know which connection this warning referes to?
>>>>
>>>>
>>>>> I have restarted at engine both engine and ovn services:
>>>>> systemctl restart ovirt-engine
>>>>> systemctl status ovirt-provider-ovn.service
>>>>>
>>>>> I have also restarted the relevant service at each host:
>>>>> systemctl restart ovn-controller.service
>>>>>
>>>>> When running at host the following it stucks and does not give any
>>>>> output:
>>>>> ovn-sbctl show
>>>>>
>>>>>
>>>> This is expected, the ovn southbound and northbound db exists only on
>>>> the ovn-central, which is places on the same machine as oVirt Engine.
>>>> Only the ovn-controller, which controls openvswitch, and openvswitch,
>>>> which is implementing the data plane, is placed on the ovn-chassis / oVirt
>>>> host.
>>>>
>>>>
>>>>> I see that the certificate is imported at key-store as it has the same
>>>>> fingerprint with the previous root CA:
>>>>>
>>>>> keytool -list -alias ovirt-provider-ovn -keystore
>>>>> /var/lib/ovirt-engine/external_truststore
>>>>>
>>>>>
>>>> This is only relevant for the connection from oVirt Engine to
>>>> ovirt-provider-ovn.
>>>>
>>>>
>>>>> At this same cluster, I had previously changed the domain name of each
>>>>> host and engine using the rename tool.
>>>>> And now replaced the certificates as per previous described so as to
>>>>> fix the imageio cert issue and ovn issue.
>>>>>
>>>>> It seems that OVN is not happy with the status of certificates.
>>>>> When testing connection at engine GUI i get a prompt to trust the
>>>&g

[ovirt-users] Re: Replacing ovirt certificates issue

2020-11-22 Thread Dominik Holler
On Fri, Nov 20, 2020 at 12:38 PM Alex K  wrote:

> Following the above, I was seeing that OVN provider connectivity test was
> failing due to some certificate issue and had to do the following to fix
> it:
>
> names="ovirt-provider-ovn"
>
> subject="$(\
> openssl x509 \
> -in /etc/pki/ovirt-engine/certs/apache.cer \
> -noout \
> -subject | \
> sed \
> 's;subject= \(.*\);\1;'
>   )"
>
> . /usr/share/ovirt-engine/bin/engine-prolog.sh
>
> for name in $names; do
> /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
> --name="${name}" \
> --password=mypass \
> --subject="${subject}" \
> --keep-key \
> --san=DNS:"${ENGINE_FQDN}"
> done
>
> Having fixed the above, when trying to connect two VMs on some OVN logical
> switches it seems they are not able to reach each other.
> I had previously added such logical switched at engine by running:
>
> ovn-nbctl ls-add ovn-net0
> ovn-nbctl ls-add ovn-net1
> etc
>
>
Not related: Please use ovirt-provider-ovn to create and manage ovn
entities.


> Checking the logs at the host /var/log/openvswitch/ovsdb-server.log I see:
> reconnect|WARN|unix#45: connection dropped (Connection reset by peer)
>
>
/var/log/openvswitch/ovn-controller.log might contain the reason.


> Also systemctl status ovirt-provider-ovn.service at engine shows:
> /usr/lib/python2.7/site-packages/urllib3/connection.py:344:
> SubjectAltNameWarning:...
>
>
Looks not good, do tou know which connection this warning referes to?


> I have restarted at engine both engine and ovn services:
> systemctl restart ovirt-engine
> systemctl status ovirt-provider-ovn.service
>
> I have also restarted the relevant service at each host:
> systemctl restart ovn-controller.service
>
> When running at host the following it stucks and does not give any output:
> ovn-sbctl show
>
>
This is expected, the ovn southbound and northbound db exists only on the
ovn-central, which is places on the same machine as oVirt Engine.
Only the ovn-controller, which controls openvswitch, and openvswitch, which
is implementing the data plane, is placed on the ovn-chassis / oVirt host.


> I see that the certificate is imported at key-store as it has the same
> fingerprint with the previous root CA:
>
> keytool -list -alias ovirt-provider-ovn -keystore
> /var/lib/ovirt-engine/external_truststore
>
>
This is only relevant for the connection from oVirt Engine to
ovirt-provider-ovn.


> At this same cluster, I had previously changed the domain name of each
> host and engine using the rename tool.
> And now replaced the certificates as per previous described so as to fix
> the imageio cert issue and ovn issue.
>
> It seems that OVN is not happy with the status of certificates.
> When testing connection at engine GUI i get a prompt to trust the cert,
> and when pressing ok i get a green confirmation of successful connection.
>
>
This is only relevant for the connection from oVirt Engine to
ovirt-provider-ovn. The prompt to trust the certificate might be redundant.
If you get the green confirmation, oVirt Engine is happy and the
certificate of the REST API of ovirt-provider-ovn is fine.


> Is there anything else that can be done to fix OVN functionality?
>

Please try to understand what is wrong in the connection between
ovn-controller and ovn south bound db.
/var/log/openvswitch/ovn-controller.log should be helpful and might contain
the reason.



> Thanx
> Alex
>
>
>
>
>
> On Thu, Nov 19, 2020 at 9:00 AM Alex K  wrote:
>
>> Seems that all services (imageio, ovn, web socket) are fine after
>> following the above and importing the new self signed CA certificate.
>> DId run also engine-setup as I was trying to fix the imageio cert issue,
>> though seems that that was only fixed after importing the CA cert at
>> browser and engine-setup might not be needed.
>>
>> On Wed, Nov 18, 2020 at 3:07 PM Alex K  wrote:
>>
>>> Seems I had a typo at
>>> /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf.
>>> I will repeat the test to verify that all services are functional
>>> following this process.
>>>
>>> On Wed, Nov 18, 2020 at 10:24 AM Alex K  wrote:
>>>
 Hi all,

 I am trying to replace the ovirt certificate at ovirt 4.3 following
 this:


 https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl

 I am doing the following:
 I have engine FQDN: manager.lab.local

 1. Create root CA private key:
 openssl genrsa -des3 -out root.key 2048

 2. Generate root certificate: (enter passphrase of root key)
 openssl req -x509 -new -nodes -key root.key -sha256 -days 3650 -out
 root.pem
 cp root.pem /tmp

 3. Create key and CSR for engine:
 openssl genrsa -out manager.lab.local.key 2048
 openssl req -new -out manager.lab.local.csr -key manager.lab.local.key

 4. Generate a certificate for engine and sign 

[ovirt-users] Re: Ovirt 4 2 NIC's

2020-11-20 Thread Dominik Holler
On Wed, Nov 18, 2020 at 7:30 PM Facundo Badaracco 
wrote:

> Hi everyone!
>
> Hope someone can help me with this..
>
> I have 3 servers with centos 8 and ovirt 4 installed. Each server has 2
> nic.
> Server A = HE (HA)
> Nic1= 192.169.2.24 Nic2=no ip
> Server B = HE (HA)
> Nic1= 192.169.2.25 Nic2=no ip
> Server C = simply host.
> Nic1= 192.169.2.26 Nic2=no ip
>
> How can i configure the second NIC in each server in order to use it for
> clients connect to the vms?. I want one nic for management, the other for
> connections.
>


If the clients want to access network services provided by the VMs,
you could create an additional logical network in oVirt, and attach it in
Compute > Hosts > hostname > Network Interfaces > Setup Host Networks
to Nic2  for every host. This new network attachment should have no IP
address.
After that, you could reference this new logical network in your VMs
virtual NICs.
If possible, I would recommend using a VLAN to provide isolation to the
management network.

If the clients connect via SPICE or VNC, you would require a
dedicated display network.



> ___
> 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/PL7WFXC4UZBUZ45HMZQ7QSRFSMQXRA4A/
>
___
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/46BRJE2MFIV7GKNDYJWKE6GBZHHS4JMW/


[ovirt-users] Re: How do you manage OVN?

2020-11-20 Thread Dominik Holler
On Thu, Nov 19, 2020 at 6:17 PM Alex McWhirter  wrote:

> I'm not sure if I' missing something, but it seems there is no way built
> in to oVirt to manage OVN outside of network / subnet creation. In
> particular routing both between networks and to external networks.
>
> Of course you have the OVN utilities, but it seems that the provider API
> is the preffered method of interaction?
>
> As far as i can tell, the only utility that can use this API as intended
> is ManageIQ, which is a bit a behemoth if you only need the OVN portion of
> things.
>
> So is that it then? Interface with the API directly or use ManageIQ? Just
> curious what others are doing in regards to OVN.
>

I am also very interested to know how users are doing this.
There is a small hint in the documentation [1].
In our automated test, we are using ansible [2] [3] and the openstacksdk
[4] [5] directly.

[1]

https://github.com/oVirt/ovirt-provider-ovn/blob/master/docs/provider_api_description.adoc#4-accessing-ovirt-provider-ovn

[2]

https://github.com/oVirt/ovirt-provider-ovn/blob/master/provider/integration-tests/ansible/create_sec_group_api.yml

[3]

https://github.com/oVirt/ovirt-system-tests/blob/master/network-suite-master/ansible/roles/create-ovn-entities/tasks/main.yml


[4]
  https://docs.openstack.org/openstacksdk/

[5]

https://github.com/oVirt/ovirt-system-tests/blob/617b58bcfc74fe25b5bb6bc391330fd8b6b848ff/network-suite-master/test-scenarios/ovn-provider/test_ovn_provider_integration_with_ovirt.py#L113





> ___
> 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/Q2VW36DS4QVSPCGUVBAUPJQOZZ5GO73Q/
>
___
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/MGN5AGUVNAYRYR46F5WPQC2QPOATEILO/


[ovirt-users] Re: Network profile filtering

2020-11-13 Thread Dominik Holler
On Fri, Nov 13, 2020 at 4:19 PM Pascal DeMilly 
wrote:

> Thank you
>
> That is exactly what I was looking for.  Any chance it could be back
> ported to 4.3. Maybe list the rules and I could use rest API to add it to
> my court install
>

On ovirt-4.3 there is only
*Bug 1009608* <https://bugzilla.redhat.com/show_bug.cgi?id=1009608> - [RFE]
Limit east-west traffic of VMs with network filter
The isolated ports cannot be backported to oVirt 4.3, because the isolated
ports require a new feature from CentOS 8 kernel and CentOS 8.3 libvirt.


>
> I'm not eager to move yet to 4.4 since I'm reading on this list lot of
> people have issue migrating  and I have 20 hosts running currently
>
>

Are you aware that you could upgrade oVirt Engine and go on with the oVirt
4.3 hosts?
This way you could have some new CentOS 8 based oVirt-4.4 hosts which use
the new features, and leave the other hosts on CentOS 7 based oVirt 4.3 .



>
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> --
> *From:* Dominik Holler 
> *Sent:* Friday, November 13, 2020 6:21:56 AM
> *To:* Pascal DeMilly 
> *Cc:* users 
> *Subject:* Re: [ovirt-users] Network profile filtering
>
>
>
> On Fri, Nov 13, 2020 at 5:13 AM  wrote:
>
> I am using ovirt 4.3. I am in need to isolate all my VM from each other
> (without using VLAN) except to a virtual gateway which is also the DHCP
> server.
>
> Basically only allowing traffic from 1 MAC address to another MAC address.
> Everything else should be filter out by ovirt filtering subsystem
>
> How will I go about that? I can see in network profile the ability to set
> different filter but can't find a way to create new filter.
>
>
> Does the Doc Text of
> *Bug 1009608* <https://bugzilla.redhat.com/show_bug.cgi?id=1009608> - [RFE]
> Limit east-west traffic of VMs with network filter
> https://bugzilla.redhat.com/show_bug.cgi?id=1009608
> explain the configuration of the filter?
>
> Please note that there will be isolated ports
>
> https://www.ovirt.org/develop/release-management/features/network/isolated-ports.html
> available in ovirt-4.4.3 on CentOS 8.3 , which might address your scenario
> even better.
>
>
>
> Thanks for your help
>
> Pascal
> ___
> 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/QIYX2SA7TBEFGAACQBLPHOZCKI7WOQHM/
>
>
___
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/HNYBXYKZZM4RXTIAVRBC7QWJWUIBH65M/


[ovirt-users] Re: Network profile filtering

2020-11-13 Thread Dominik Holler
On Fri, Nov 13, 2020 at 5:13 AM  wrote:

> I am using ovirt 4.3. I am in need to isolate all my VM from each other
> (without using VLAN) except to a virtual gateway which is also the DHCP
> server.
>
> Basically only allowing traffic from 1 MAC address to another MAC address.
> Everything else should be filter out by ovirt filtering subsystem
>
> How will I go about that? I can see in network profile the ability to set
> different filter but can't find a way to create new filter.
>
>
Does the Doc Text of
*Bug 1009608*  - [RFE]
Limit east-west traffic of VMs with network filter
https://bugzilla.redhat.com/show_bug.cgi?id=1009608
explain the configuration of the filter?

Please note that there will be isolated ports
https://www.ovirt.org/develop/release-management/features/network/isolated-ports.html
available in ovirt-4.4.3 on CentOS 8.3 , which might address your scenario
even better.



> Thanks for your help
>
> Pascal
> ___
> 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/QIYX2SA7TBEFGAACQBLPHOZCKI7WOQHM/
>
___
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/V4WUYEBTI6XJ6XD3Z7I66K6WVG7377T2/


[ovirt-users] Re: Unable to attach VLAN-based logical networks to a bond oVirt 4.4

2020-11-13 Thread Dominik Holler
On Thu, Nov 12, 2020 at 12:43 PM  wrote:

> When attempting to add a VLAN to a bonded interface (Broadcom NICs) in
> oVirt Management portal the process fails as per:
> https://bugzilla.redhat.com/show_bug.cgi?id=1860479
>
> This issue has rendered mu upgrade to 4.4 useless. Does anyone have a
> patched kernel to resolve this please?
>
>
According to the bug, the fix should be included in Red Hat's Linux
kernel-4.18.0-240.6.el8.
This matches the current kernel in CentOS Stream.
Does the current kernel from CentOS stream fix the problem in your
environment?





> Regards
>
> Shimme
> ___
> 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/DUT5ETZBVMKH2T4KZ4WR2FW6FQLYTM5C/
>
___
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/W5IEHS7W3RTDBUQRO4IUUMCESATYXOPU/


[ovirt-users] Re: Removal of dpdk

2020-11-04 Thread Dominik Holler
Hi Florian,
thanks for your thoughts!

On Tue, Nov 3, 2020 at 3:21 PM Florian Schmid via Users 
wrote:

> Hi Ales,
>
> what do you mean with "not maintained for a long time"?
>

The oVirt integration of dpdk was not maintained.


> DPDK is heavily developed and make the linux network extremely fast.
>
> I don't think, that SR-IOV can replace it,
>

The removal of dpdk is about removing the dpdk support from oVirt hosts
only.
We wonder if there is someone using dpdk to attach oVirt VMs to physical
NICs.
We are aware that many users use SR-IOV, especially for scenarios of
enabling a high count of Ethernet frames for VMs or requiring a low latency,
but we are not aware of users using dpdk to connect the oVirt VMs to the
physical NICs of the host.



> because packets must be still processed by the kernel, which is really
> slow and CPU demanding.
>


In SR-IOV the packets might be processed by the guest kernel, not but the
host kernel.
oVirt is focused on the host kernel, while the guest OS is managed by the
user of oVirt.

Did this explanation address your concerns?

BR Florian
>
> --
> *Von: *"Ales Musil" 
> *An: *"Nir Soffer" 
> *CC: *"users" , "devel" 
> *Gesendet: *Dienstag, 3. November 2020 13:56:12
> *Betreff: *[ovirt-users] Re: Removal of dpdk
>
>
>
> On Tue, Nov 3, 2020 at 1:52 PM Nir Soffer  wrote:
>
>> On Tue, Nov 3, 2020 at 1:07 PM Ales Musil  wrote:
>>
>>> Hello,
>>> we have decided to remove dpdk in the upcoming version of oVirt namely
>>> 4.4.4. Let us know if there are any concerns about this.
>>>
>>
>> Can you give more info why we want to remove this feature, and what is
>> the replacement for existing users?
>>
>> Nir
>>
>
> Sure,
> the feature was only experimental and not maintained for a long time. The
> replacement is to use SR-IOV
> which is supported by oVirt.
>
> Thanks,
> Ales
>
>
> --
>
> Ales Musil
>
> Software Engineer - RHV Network
>
> Red Hat EMEA 
>
> amu...@redhat.comIM: amusil
> 
>
> ___
> 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/3FHIRQKEEKLGWLMSPHEJ3LOV3LPQZXPA/
> ___
> 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/ZCAYTHVZPOZF3MCJB3NMCIU467M33NMR/
>
>
___
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/DFPVTL77WC5BNCYB2QLLWCBSNOTPML2Q/


[ovirt-users] Re: Question about OVN MTU

2020-11-01 Thread Dominik Holler
On Fri, Oct 30, 2020 at 8:14 PM Strahil Nikolov 
wrote:

> If you mean "Administration" -> "Providers" -> "Ovirt-provider-ovn" -> it
> is enabled.
>
>
Yes, this one.
If it is enabled, Engine should reflect the MTU which is provided by
ovirt-provider-ovn via OpenStack API.
The related configuration value dhcp-mtu of ovirt-provider-ovn is explained
in https://github.com/oVirt/ovirt-provider-ovn/blob/master/README.adoc.



> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В петък, 30 октомври 2020 г., 21:10:02 Гринуич+2, Strahil Nikolov <
> hunter86...@yahoo.com> написа:
>
>
>
>
>
> Any hint for the location of "Automatic Synchronization" in UI ?
>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В петък, 30 октомври 2020 г., 20:16:13 Гринуич+2, Dominik Holler <
> dhol...@redhat.com> написа:
>
>
>
>
>
>
>
> On Fri, Oct 30, 2020 at 7:03 PM Strahil Nikolov 
> wrote:
> > in 4.3.10's UI it shows 1500 :)
> >
>
> This might be just a misleading representation of the default value or an
> unknown value.
> If "Automatic Synchronization" is enabled for the ovirt-provider-ovn in
> oVirt Engine,
> the value should be updated in Engine to the correct after the next
> synchronization in the background.
>
> >
> >
> >
> >
> >
> > В петък, 30 октомври 2020 г., 13:25:05 Гринуич+2, Dominik Holler <
> dhol...@redhat.com> написа:
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Oct 29, 2020 at 9:36 PM Alex K  wrote:
> >>
> >>
> >> On Tue, Oct 27, 2020, 02:49 Strahil Nikolov via Users 
> wrote:
> >>> Hello All,
> >>>
> >>> I would like to learn more about OVN and especially the maximum MTU
> that I can use in my environment.
> >>>
> >>> Current Setup 4.3.10
> >>> Network was created via UI -> MTU Custom -> 8976 -> Create on External
> Provider -> Connect to Physical Network
> >>>
> >>> So my physical connection is MTU 9000 and I have read that Geneve uses
> 24 bits (maybe that's wrong ?) , thus I have reduced the MTU to 8976.
> >> From the internet draft it seems that the tunnel header + reserved bits
> comprise 64 bits. A common practice for Geneve implementations  is to use
> 8900 mtu for VMs when having 9000 mtu physical network.
> >>
> >
> > Ack, this is a safe choice.
> > In oVirt's default configuration, an overhead of 58 bytes
> > ( = 20 IPv4 header + 8 UDP header + 16 GENEVE Ethernet header (including
> 8 bytes options) + 14 bytes inner Ethernet header)
> > is added.
> > This is why the default MTU for OVN networks in oVirt is 1442 bytes,
> which assumes 1500 bytes MTU in the physical network.
> >
> >
> >
> >>
> >> The draft:
> >> https://tools.ietf.org/html/draft-ietf-nvo3-geneve-08
> >>>
> >>> I did some testing on the VMs and ping with payload of '8914' was the
> maximum I could pass without fragmenting and thus the MTU on the VMs was
> set to 8942.
> >>>
> >>> Did I correctly configure the test network's MTU and am I
> understanding it correctly that we need extra 34 bits inside the network
> for encapsulation ?
> >>>
> >
> > You could check with packet analyzers like tcpdump and wireshark.
> >
> >>>  I have checked
> https://www.ovirt.org/develop/release-management/features/network/managed_mtu_for_vm_networks.html
> but I don't see any refference how to calculate the max MTU.
> >>>
> >>>
> >>> Best Regards,
> >>> Strahil Nikolov
> >>> ___
> >>> 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/CKNS5T5KE2W5EIXBTGQDU3URKHQDVAM4/
> >>>
> >>>
> >>  ___
> >> 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/VIDP3MLYHWG2WXQ6JB6EHK66J5WBOMVT/
> >>
> >>
> > ___
> > 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/7UN5DXXKXN3KBLTLGXIPTGWVF4ODKKUB/
> >
> >
>
>
___
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/LFWBSX5ANBIGVZW5X7ONPUREFYMU4YR7/


[ovirt-users] Re: Question about OVN MTU

2020-10-30 Thread Dominik Holler
On Fri, Oct 30, 2020 at 7:03 PM Strahil Nikolov 
wrote:

> in 4.3.10's UI it shows 1500 :)
>
>
This might be just a misleading representation of the default value or an
unknown value.
If "Automatic Synchronization" is enabled for the ovirt-provider-ovn in
oVirt Engine,
the value should be updated in Engine to the correct after the next
synchronization in the background.


>
>
>
>
>
> В петък, 30 октомври 2020 г., 13:25:05 Гринуич+2, Dominik Holler <
> dhol...@redhat.com> написа:
>
>
>
>
>
>
>
> On Thu, Oct 29, 2020 at 9:36 PM Alex K  wrote:
> >
> >
> > On Tue, Oct 27, 2020, 02:49 Strahil Nikolov via Users 
> wrote:
> >> Hello All,
> >>
> >> I would like to learn more about OVN and especially the maximum MTU
> that I can use in my environment.
> >>
> >> Current Setup 4.3.10
> >> Network was created via UI -> MTU Custom -> 8976 -> Create on External
> Provider -> Connect to Physical Network
> >>
> >> So my physical connection is MTU 9000 and I have read that Geneve uses
> 24 bits (maybe that's wrong ?) , thus I have reduced the MTU to 8976.
> > From the internet draft it seems that the tunnel header + reserved bits
> comprise 64 bits. A common practice for Geneve implementations  is to use
> 8900 mtu for VMs when having 9000 mtu physical network.
> >
>
> Ack, this is a safe choice.
> In oVirt's default configuration, an overhead of 58 bytes
> ( = 20 IPv4 header + 8 UDP header + 16 GENEVE Ethernet header (including 8
> bytes options) + 14 bytes inner Ethernet header)
> is added.
> This is why the default MTU for OVN networks in oVirt is 1442 bytes, which
> assumes 1500 bytes MTU in the physical network.
>
>
>
> >
> > The draft:
> > https://tools.ietf.org/html/draft-ietf-nvo3-geneve-08
> >>
> >> I did some testing on the VMs and ping with payload of '8914' was the
> maximum I could pass without fragmenting and thus the MTU on the VMs was
> set to 8942.
> >>
> >> Did I correctly configure the test network's MTU and am I understanding
> it correctly that we need extra 34 bits inside the network for
> encapsulation ?
> >>
>
> You could check with packet analyzers like tcpdump and wireshark.
>
> >>  I have checked
> https://www.ovirt.org/develop/release-management/features/network/managed_mtu_for_vm_networks.html
> but I don't see any refference how to calculate the max MTU.
> >>
> >>
> >> Best Regards,
> >> Strahil Nikolov
> >> ___
> >> 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/CKNS5T5KE2W5EIXBTGQDU3URKHQDVAM4/
> >>
> >>
> >  ___
> > 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/VIDP3MLYHWG2WXQ6JB6EHK66J5WBOMVT/
> >
> >
> ___
> 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/7UN5DXXKXN3KBLTLGXIPTGWVF4ODKKUB/
>
>
___
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/7N4Z4SYIRJ44BASOTVKCABV4QG53U3C6/


[ovirt-users] Re: Question about OVN MTU

2020-10-30 Thread Dominik Holler
On Thu, Oct 29, 2020 at 9:36 PM Alex K  wrote:

>
>
> On Tue, Oct 27, 2020, 02:49 Strahil Nikolov via Users 
> wrote:
>
>> Hello All,
>>
>> I would like to learn more about OVN and especially the maximum MTU that
>> I can use in my environment.
>>
>> Current Setup 4.3.10
>> Network was created via UI -> MTU Custom -> 8976 -> Create on External
>> Provider -> Connect to Physical Network
>>
>> So my physical connection is MTU 9000 and I have read that Geneve uses 24
>> bits (maybe that's wrong ?) , thus I have reduced the MTU to 8976.
>>
> From the internet draft it seems that the tunnel header + reserved bits
> comprise 64 bits. A common practice for Geneve implementations  is to use
> 8900 mtu for VMs when having 9000 mtu physical network.
>
>
Ack, this is a safe choice.
In oVirt's default configuration, an overhead of 58 bytes
( = 20 IPv4 header + 8 UDP header + 16 GENEVE Ethernet header (including 8
bytes options) + 14 bytes inner Ethernet header)
is added.
This is why the default MTU for OVN networks in oVirt is 1442 bytes, which
assumes 1500 bytes MTU in the physical network.




> The draft:
> https://tools.ietf.org/html/draft-ietf-nvo3-geneve-08
>
>>
>> I did some testing on the VMs and ping with payload of '8914' was the
>> maximum I could pass without fragmenting and thus the MTU on the VMs was
>> set to 8942.
>>
>> Did I correctly configure the test network's MTU and am I understanding
>> it correctly that we need extra 34 bits inside the network for
>> encapsulation ?
>>
>>
You could check with packet analyzers like tcpdump and wireshark.


> I have checked
>> https://www.ovirt.org/develop/release-management/features/network/managed_mtu_for_vm_networks.html
>> but I don't see any refference how to calculate the max MTU.
>>
>>
>> Best Regards,
>> Strahil Nikolov
>> ___
>> 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/CKNS5T5KE2W5EIXBTGQDU3URKHQDVAM4/
>>
> ___
> 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/VIDP3MLYHWG2WXQ6JB6EHK66J5WBOMVT/
>
___
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/7UN5DXXKXN3KBLTLGXIPTGWVF4ODKKUB/


[ovirt-users] Re: OVN Geneve tunnels not been established

2020-10-06 Thread Dominik Holler
On Tue, Oct 6, 2020 at 12:25 PM Konstantinos Betsis 
wrote:

> Hi Dominic
>
> That fixed it.
>

Thanks for letting us know and your patience.


> VMs have full connectivity and I don't see any errors on the nodes ovn
> controller.
>
> Thanks for the help and quick responses, I really appreciate it.
>
> In summary for future reference:
>

Thanks for this nice summary, I am sure this will help others in the
community.


> If certificate errors are met need to review:
>
> ovs-vsctl --no-wait get open . external-ids:ovn-remote
> ovs-vsctl --no-wait get open . external-ids:ovn-encap-type
> ovs-vsctl --no-wait get open . external-ids:ovn-encap-ip
>
> The ovn-remote will state if the OVN connection is using TCP or TLS.
>
> We then do:
>
> ovn-nbctl get-ssl
> ovn-nbctl get-connection
> ovn-sbctl get-ssl
> ovn-sbctl get-connection
> ls -l /etc/pki/ovirt-engine/keys/ovn-*
>
>
> As to check the ovn northbound and southbound configuration and listening
> ports and if TCP or TLS is used.
>
> If tls is used we must update the nodes with:
>
> ovn-nbctl set-ssl "ovn northbound interface certificate key" "ovn
> northbound interface certificate file"
> ovn-nbctl set-connection pssl:6641
> ovn-sbctl set-ssl "ovn southbound interface certificate key" "ovn
> southbound interface certificate file"
> ovn-sbctl set-connection pssl:6642
>
>
> The certificates must reside within nodes through the VDSM client.
>
> Finally, we check that all tunnels are established and working ok.
>
> If we get to a stuck chassis we simply stop the ovn service on the node
> and delete the chassis from the northbound interface through:
>
> ovn-sbctl  chassis-del "chassis_ID"
>
> Thank you
> Best Regards
> Konstantinos Betsis
>
>
> On Tue, Oct 6, 2020 at 11:37 AM Dominik Holler  wrote:
>
>>
>>
>> On Tue, Oct 6, 2020 at 10:31 AM Konstantinos Betsis 
>> wrote:
>>
>>> Hi guys
>>>
>>> Sorry to disturb you but i am pretty much stuck at this point with the
>>> ovn southbound interface.
>>>
>>> Is there a way i can flush it and have it reconfigured from ovirt?
>>>
>>>
>> Can you please delete the chassis via
>>
>> ovn-sbctl  chassis-del 32cd0eb4-d763-4036-bbc9-a4d3a4013ee6
>>
>> while  32cd0eb4-d763-4036-bbc9-a4d3a4013ee6 should be replaced with the
>> id of the suspicious chassis show by
>> ovn-sbctl  show
>>
>> The ovn-controller will add the chassis again in a few seconds, but I
>> hope that this would remove the inconsistency in the db.
>>
>>
>>
>>> Thank you
>>> Best Regards
>>> Konstantinos Betsis
>>>
>>> On Thu, Oct 1, 2020 at 6:52 PM Konstantinos Betsis 
>>> wrote:
>>>
>>>> Regarding the ovn-controller logs
>>>>
>>>> 2020-10-01T15:51:03.156Z|14143|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.220Z|14144|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.284Z|14145|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.347Z|14146|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.411Z|14147|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.474Z|14148|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.538Z|14149|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.601Z|14150|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.664Z|14151|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:03.727Z|14152|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:08.792Z|14153|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:08.855Z|14154|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:08.919Z|14155|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:08.982Z|14156|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:09.046Z|14157|main|INFO|OVNSB commit failed, force
>>>> recompute next time.
>>>> 2020-10-01T15:51:09.109Z|

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-10-06 Thread Dominik Holler
On Tue, Oct 6, 2020 at 10:31 AM Konstantinos Betsis 
wrote:

> Hi guys
>
> Sorry to disturb you but i am pretty much stuck at this point with the ovn
> southbound interface.
>
> Is there a way i can flush it and have it reconfigured from ovirt?
>
>
Can you please delete the chassis via

ovn-sbctl  chassis-del 32cd0eb4-d763-4036-bbc9-a4d3a4013ee6

while  32cd0eb4-d763-4036-bbc9-a4d3a4013ee6 should be replaced with the id
of the suspicious chassis show by
ovn-sbctl  show

The ovn-controller will add the chassis again in a few seconds, but I hope
that this would remove the inconsistency in the db.



> Thank you
> Best Regards
> Konstantinos Betsis
>
> On Thu, Oct 1, 2020 at 6:52 PM Konstantinos Betsis 
> wrote:
>
>> Regarding the ovn-controller logs
>>
>> 2020-10-01T15:51:03.156Z|14143|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.220Z|14144|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.284Z|14145|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.347Z|14146|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.411Z|14147|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.474Z|14148|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.538Z|14149|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.601Z|14150|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.664Z|14151|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.727Z|14152|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:08.792Z|14153|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:08.855Z|14154|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:08.919Z|14155|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:08.982Z|14156|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.046Z|14157|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.109Z|14158|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.173Z|14159|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.236Z|14160|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.299Z|14161|main|INFO|OVNSB commit failed, force
>> recompute next time.
>>
>>
>> I don't think we can see anything more from these.
>>
>>
>>
>> On Thu, Oct 1, 2020 at 6:12 PM Konstantinos Betsis 
>> wrote:
>>
>>> Hi Dimitru
>>>
>>> I've seen that as well.
>>> I've deleted the dc01-node2 (ams03-hypersec02) from ovirt.
>>> I've also issued ovs-vsctl emer-reset.
>>>
>>> But ovn-sbctl list chassis still depicts the node twice.
>>> The ovs-sbctl show still depicts 3 geneve tunnels from dc01-node2
>>>
>>> How, can we fix this?
>>>
>>> On Thu, Oct 1, 2020 at 9:59 AM Dumitru Ceara  wrote:
>>>
>>>> On 9/30/20 3:41 PM, Konstantinos Betsis wrote:
>>>> > From the configuration I can see only three nodes.
>>>> > "Encap":{
>>>> > #dc01-node02
>>>> >
>>>> "da8fb1dc-f832-4d62-a01d-2e5aef018c8d":{"ip":"10.137.156.56","chassis_name":"be3abcc9-7358-4040-a37b-8d8a782f239c","options":["map",[["csum","true"]]],"type":"geneve"},
>>>> > #dc01-node01
>>>> >
>>>> "4808bd8f-7e46-4f29-9a96-046bb580f0c5":{"ip":"10.137.156.55","chassis_name":"95ccb04a-3a08-4a62-8bc0-b8a7a42956f8","options":["map",[["csum","true"]]],"type":"geneve"},
>>>> > #dc02-node01
>>>> >
>>>> "f20b33ae-5a6b-456c-b9cb-2e4d8b54d8be":{"ip":"192.168.121.164","chassis_name":"c4b23834-aec7-4bf8-8be7-aa94a50a6144","options":["map",[["csum","true"]]],"type":"geneve"}}
>>>> >
>>>> > So I don't understand why the dc01-node02 tries to establish a tunnel
>>>> > with itself.
>>>> >
>>>> > Is

[ovirt-users] Re: Newbie question on network - Resolved

2020-09-28 Thread Dominik Holler
On Fri, Sep 25, 2020 at 3:41 PM Valerio Luccio 
wrote:

> It turns out that for security reasons the university sets a default cap
> of two MAC addresses per port, so host and engine maxed it out. I requested
> that they increase the cap on this port and now things work as expected.
>

Thank you very much for sharing this!


> --
> As a result of Coronavirus-related precautions, NYU and the Center for
> Brain Imaging operations will be managed remotely until further notice.
> All telephone calls and e-mail correspondence are being monitored remotely
> during our normal business hours of 9am-5pm, Monday through Friday.
>
> For MRI scanner-related emergency, please contact: Keith Sanzenbach at
> keith.sanzenb...@nyu.edu and/or Pablo Velasco at pablo.vela...@nyu.edu
> For computer/hardware/software emergency, please contact: Valerio Luccio
> at valerio.luc...@nyu.edu
> For TMS/EEG-related emergency, please contact: Chrysa Papadaniil at
> chr...@nyu.edu
> For CBI-related administrative emergency, please contact: Jennifer Mangan
> at jennifer.man...@nyu.edu
>
> Valerio Luccio (212) 998-8736
> Center for Brain Imaging 4 Washington Place, Room 158
> New York University New York, NY 10003
>
> "In an open world, who needs windows or gates ?"
>
> ___
> 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/A6DQYT7DGUNB2TOI5LTNBDMFAAEQN5BE/
>
___
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/Z6XDS6G6RNBWN5P637HN2QFJ5D7ZUYUA/


[ovirt-users] Re: routing policy problem in ovirt 4.4

2020-09-18 Thread Dominik Holler
Can you please share more details about the desired configuration and how
you configured the network attachments on an example host?

On Fri, Sep 18, 2020 at 11:43 AM  wrote:

> Hello I created a cluster of ovirt 4.4 with 5 servers, I have a diferent
> gateway, ovirtmgmt and display network. In 4.4 routing is managed from
> network manager. Network manager seems to "forget" and recreate the route
> each time. So I cannot connect to the virtual machines console unless I run
> a ping for about a minute on the display network ip of the hypervisor, so
> network manager "wakes up" and "recreates" the route. I use this work
> around but it is not something that a user can do.
> What is the proper way to do this ?
> Thank you
> ___
> 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/N55AVLCBPD5NFAVWFY7B6WN6P5QTCKMJ/
>
___
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/EOLUYK6IDHBLSWKDC5UGM3GEFGQ2DFUV/


[ovirt-users] Re: Low Performance (KVM Vs VMware Hypervisor) When running multi-process application

2020-09-16 Thread Dominik Holler
On Tue, Sep 15, 2020 at 5:02 PM Ravin Ya  wrote:

> Hello Everyone,
>
> Please advice. Any help will be highly appreciated. Thank you in advance.
>
> Test Setup:
> oVirt Centos 7.8 Virtulization Host
> Guest VM Centos 7.8 (Mutiqueue enabled 6 vCPUs with 6 Rx Tx Queues)
> The vCPUs are configured for host pass through (Pinned CPU).
>
> The Guest VM runs the application in userspace. The Application consists
> of the parent process that reads packets in raw socket mode from the
> interface


Is this interface a virtual NIC? If so, please ensure to disable network
filtering on the used vNIC profile before starting the VM.
If there is a way to use SR-IOV/ passthrough vNIC profile, this would
provide nearly bare metal performance of the virtual NIC.


> and forwards then to child processes (~vCPUs) via IPC (shared memory –
> pipes). The performance (throughput / CPU utilization) that I get with KVM
> is half of what I get with VMware.
>
> Any thoughts on the below observations? Any suggestions?
> KVM Guest VMs degraded performance when running multi-process applications.
> High FUTEX time (Seen on the Guest VM when passing traffic).
> High SY: System CPU time spent in kernel space (Seen on both Hypervisor
> and the Guest VMs only when running my application.)
>
> -Rav Ya
> ___
> 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/QGR367Q6QGSURVY6552JMYESGE2K3H2Y/
>
___
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/ZQ7E76MOUKDCSI752DTOSESMIES5IZEW/


[ovirt-users] Re: OVN Geneve tunnels not been established

2020-09-16 Thread Dominik Holler
On Tue, Sep 15, 2020 at 6:53 PM Konstantinos Betsis 
wrote:

> So a new test-net was created under DC01 and was depicted in the networks
> tab under both DC01 and DC02.
> I believe for some reason networks are duplicated in DCs, maybe for future
> use??? Don't know.
> If one tries to delete the network from the other DC it gets an error,
> while if deleted from the once initially created it gets deleted from both.
>
>
In oVirt a logical network is an entity in a data center. If the automatic
synchronization is enabled on the ovirt-provider-ovn entity in oVirt
Engine, the OVN networks are reflected to all data centers. If you do not
like this, you can disable the automatic synchronization of the
ovirt-provider-ovn in Admin Portal.


> From the DC01-node02 i get the following errors:
>
> 2020-09-15T16:48:49.904Z|22748|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-09-15T16:48:49.905Z|22749|binding|INFO|Claiming lport
> 9a6cc189-0934-4468-97ae-09f90fa4598d for this chassis.
> 2020-09-15T16:48:49.905Z|22750|binding|INFO|9a6cc189-0934-4468-97ae-09f90fa4598d:
> Claiming 56:6f:77:61:00:06
> 2020-09-15T16:48:49.905Z|22751|binding|INFO|Claiming lport
> 16162721-c815-4cd8-ab57-f22e6e482c7f for this chassis.
> 2020-09-15T16:48:49.905Z|22752|binding|INFO|16162721-c815-4cd8-ab57-f22e6e482c7f:
> Claiming 56:6f:77:61:00:03
> 2020-09-15T16:48:49.905Z|22753|binding|INFO|Claiming lport
> b88de6e4-6d77-4e42-b734-4cc676728910 for this chassis.
> 2020-09-15T16:48:49.905Z|22754|binding|INFO|b88de6e4-6d77-4e42-b734-4cc676728910:
> Claiming 56:6f:77:61:00:15
> 2020-09-15T16:48:49.905Z|22755|binding|INFO|Claiming lport
> b7ff5f2b-4bb4-4250-8ad8-8a7e19d2b4c7 for this chassis.
> 2020-09-15T16:48:49.905Z|22756|binding|INFO|b7ff5f2b-4bb4-4250-8ad8-8a7e19d2b4c7:
> Claiming 56:6f:77:61:00:0d
> 2020-09-15T16:48:49.905Z|22757|binding|INFO|Claiming lport
> 5d03a7a5-82a1-40f9-b50c-353a26167fa3 for this chassis.
> 2020-09-15T16:48:49.905Z|22758|binding|INFO|5d03a7a5-82a1-40f9-b50c-353a26167fa3:
> Claiming 56:6f:77:61:00:02
> 2020-09-15T16:48:49.905Z|22759|binding|INFO|Claiming lport
> 12d829c3-64eb-44bc-a0bd-d7219991f35f for this chassis.
> 2020-09-15T16:48:49.905Z|22760|binding|INFO|12d829c3-64eb-44bc-a0bd-d7219991f35f:
> Claiming 56:6f:77:61:00:1c
> 2020-09-15T16:48:49.959Z|22761|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-09-15T16:48:49.960Z|22762|binding|INFO|Claiming lport
> 9a6cc189-0934-4468-97ae-09f90fa4598d for this chassis.
> 2020-09-15T16:48:49.960Z|22763|binding|INFO|9a6cc189-0934-4468-97ae-09f90fa4598d:
> Claiming 56:6f:77:61:00:06
> 2020-09-15T16:48:49.960Z|22764|binding|INFO|Claiming lport
> 16162721-c815-4cd8-ab57-f22e6e482c7f for this chassis.
> 2020-09-15T16:48:49.960Z|22765|binding|INFO|16162721-c815-4cd8-ab57-f22e6e482c7f:
> Claiming 56:6f:77:61:00:03
> 2020-09-15T16:48:49.960Z|22766|binding|INFO|Claiming lport
> b88de6e4-6d77-4e42-b734-4cc676728910 for this chassis.
> 2020-09-15T16:48:49.960Z|22767|binding|INFO|b88de6e4-6d77-4e42-b734-4cc676728910:
> Claiming 56:6f:77:61:00:15
> 2020-09-15T16:48:49.960Z|22768|binding|INFO|Claiming lport
> b7ff5f2b-4bb4-4250-8ad8-8a7e19d2b4c7 for this chassis.
> 2020-09-15T16:48:49.960Z|22769|binding|INFO|b7ff5f2b-4bb4-4250-8ad8-8a7e19d2b4c7:
> Claiming 56:6f:77:61:00:0d
> 2020-09-15T16:48:49.960Z|22770|binding|INFO|Claiming lport
> 5d03a7a5-82a1-40f9-b50c-353a26167fa3 for this chassis.
> 2020-09-15T16:48:49.960Z|22771|binding|INFO|5d03a7a5-82a1-40f9-b50c-353a26167fa3:
> Claiming 56:6f:77:61:00:02
> 2020-09-15T16:48:49.960Z|22772|binding|INFO|Claiming lport
> 12d829c3-64eb-44bc-a0bd-d7219991f35f for this chassis.
> 2020-09-15T16:48:49.960Z|22773|binding|INFO|12d829c3-64eb-44bc-a0bd-d7219991f35f:
> Claiming 56:6f:77:61:00:1c
>
>
> And this repeats forever.
>
>
Looks like the southbound db is confused.

Can you try to delete all chassis listed by
sudo ovn-sbctl show
via
sudo /usr/share/ovirt-provider-ovn/scripts/remove_chassis.sh  dev-host0
?
if the script remove_chassis.sh is not installed, you can use
https://github.com/oVirt/ovirt-provider-ovn/blob/master/provider/scripts/remove_chassis.py
instead.

Can you please also share the output of
ovs-vsctl list Interface
on the host which produced the logfile above?




> The connections to ovn-sbctl is ok and the geneve tunnels are depicted
> under ovs-vsctl ok.
> VMs still not able to ping each other.
>
> On Tue, Sep 15, 2020 at 7:22 PM Dominik Holler  wrote:
>
>>
>>
>> On Tue, Sep 15, 2020 at 6:18 PM Konstantinos Betsis 
>> wrote:
>>
>>> Hi Dominik
>>>
>>> Fixed the issue.
>>>
>>
>> Thanks.
>>
>>
>>> I believe the 
>>> /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provide

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-09-15 Thread Dominik Holler
On Tue, Sep 15, 2020 at 6:18 PM Konstantinos Betsis 
wrote:

> Hi Dominik
>
> Fixed the issue.
>

Thanks.


> I believe the /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
> needed update also.
> The package is upgraded to the latest version.
>
> Once the provider was updated with the following it functioned perfectly:
>
> Name: ovirt-provider-ovn
> Description: oVirt network provider for OVN
> Type: External Network Provider
> Network Plugin: oVirt Network Provider for OVN
> Automatic Synchronization: Checked
> Unmanaged: Unchecked
> Provider URL: https:dc02-ovirt01.testdomain.com:9696
> Requires Authentication: Checked
> Username: admin@internal
> Password: "The admin password"
> Protocol: HTTPS
> Host Name: dc02-ovirt01.testdomain.com
> API Port: 35357
> API Version: v2.0
> Tenant Name: "Empty"
>
> For some reason the TLS certificate was in conflict with the ovn provider
> details, i would bet the "host" entry.
>
> So now geneve tunnels are established.
> OVN provider is working.
>
> But VMs still do not communicated on the same VM network spanning
> different hosts.
>
> So if we have a VM network test-net on both dc01-host01 and dc01-host02
> and each host has a VM with IP addresses on the same network, VMs on the
> same VM network should communicate directly.
> But traffic does not reach each other.
>
>
Can you create a new external network, with port security disabled, and an
IPv4 subnet?
If the VMs get an IP address via DHCP, ovn is working, and should be able
to ping each other, too.
If not, there should be a helpful entry in the ovn-controller.log of the
host the VM is running.


> On Tue, Sep 15, 2020 at 7:07 PM Dominik Holler  wrote:
>
>> Can you try again with:
>>
>> [OVN REMOTE]
>> ovn-remote=ssl:127.0.0.1:6641
>> [SSL]
>> https-enabled=false
>> ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
>> ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
>> ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
>> [OVIRT]
>> ovirt-sso-client-secret=*random_test*
>> ovirt-host=https://dc02-ovirt01.testdomain.com:443
>> <https://dc02-ovirt01.testdomain.com/>
>> ovirt-sso-client-id=ovirt-provider-ovn
>> ovirt-ca-file=/etc/pki/ovirt-engine/apache-ca.pem
>> [NETWORK]
>> port-security-enabled-default=True
>> [PROVIDER]
>>
>> provider-host=dc02-ovirt01.testdomain.com
>>
>>
>>
>> Please note that the should match the HTTP or HTTPS in the of the
>> ovirt-prover-ovn configuration in oVirt Engine.
>> So if the ovirt-provider-ovn entity in Engine is on HTTP, the config file
>> should use
>> https-enabled=false
>>
>>
>> On Tue, Sep 15, 2020 at 5:56 PM Konstantinos Betsis 
>> wrote:
>>
>>> This is the updated one:
>>>
>>> # This file is automatically generated by engine-setup. Please do not
>>> edit manually
>>> [OVN REMOTE]
>>> ovn-remote=ssl:127.0.0.1:6641
>>> [SSL]
>>> https-enabled=true
>>> ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
>>> ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
>>> ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
>>> [OVIRT]
>>> ovirt-sso-client-secret=*random_text*
>>> ovirt-host=https://dc02-ovirt01.testdomain.com:443
>>> ovirt-sso-client-id=ovirt-provider-ovn
>>> ovirt-ca-file=/etc/pki/ovirt-engine/apache-ca.pem
>>> [NETWORK]
>>> port-security-enabled-default=True
>>> [PROVIDER]
>>> provider-host=dc02-ovirt01.testdomain.com
>>> [AUTH]
>>> auth-plugin=auth.plugins.static_token:NoAuthPlugin
>>>
>>>
>>> However, it still does not connect.
>>> It prompts for the certificate but then fails and prompts to see the log
>>> but the ovirt-provider-ovn.log does not list anything.
>>>
>>> Yes we've got ovirt for about a year now from about version 4.1
>>>
>>>
>> This might explain the trouble. Upgrade of ovirt-provider-ovn should work
>> flawlessly starting from oVirt 4.2.
>>
>>
>>> On Tue, Sep 15, 2020 at 6:44 PM Dominik Holler 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 15, 2020 at 5:34 PM Konstantinos Betsis 
>>>> wrote:
>>>>
>>>>> There is a file with the below entries
>>>>>
>>>>
>>>> Impressive, do you know when this config file was created and if it was
>>>> manually modified?
>>>

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-09-15 Thread Dominik Holler
Can you try again with:

[OVN REMOTE]
ovn-remote=ssl:127.0.0.1:6641
[SSL]
https-enabled=false
ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
[OVIRT]
ovirt-sso-client-secret=*random_test*
ovirt-host=https://dc02-ovirt01.testdomain.com:443
<https://dc02-ovirt01.testdomain.com/>
ovirt-sso-client-id=ovirt-provider-ovn
ovirt-ca-file=/etc/pki/ovirt-engine/apache-ca.pem
[NETWORK]
port-security-enabled-default=True
[PROVIDER]

provider-host=dc02-ovirt01.testdomain.com



Please note that the should match the HTTP or HTTPS in the of the
ovirt-prover-ovn configuration in oVirt Engine.
So if the ovirt-provider-ovn entity in Engine is on HTTP, the config file
should use
https-enabled=false


On Tue, Sep 15, 2020 at 5:56 PM Konstantinos Betsis 
wrote:

> This is the updated one:
>
> # This file is automatically generated by engine-setup. Please do not edit
> manually
> [OVN REMOTE]
> ovn-remote=ssl:127.0.0.1:6641
> [SSL]
> https-enabled=true
> ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
> ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
> ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
> [OVIRT]
> ovirt-sso-client-secret=*random_text*
> ovirt-host=https://dc02-ovirt01.testdomain.com:443
> ovirt-sso-client-id=ovirt-provider-ovn
> ovirt-ca-file=/etc/pki/ovirt-engine/apache-ca.pem
> [NETWORK]
> port-security-enabled-default=True
> [PROVIDER]
> provider-host=dc02-ovirt01.testdomain.com
> [AUTH]
> auth-plugin=auth.plugins.static_token:NoAuthPlugin
>
>
> However, it still does not connect.
> It prompts for the certificate but then fails and prompts to see the log
> but the ovirt-provider-ovn.log does not list anything.
>
> Yes we've got ovirt for about a year now from about version 4.1
>
>
This might explain the trouble. Upgrade of ovirt-provider-ovn should work
flawlessly starting from oVirt 4.2.


> On Tue, Sep 15, 2020 at 6:44 PM Dominik Holler  wrote:
>
>>
>>
>> On Tue, Sep 15, 2020 at 5:34 PM Konstantinos Betsis 
>> wrote:
>>
>>> There is a file with the below entries
>>>
>>
>> Impressive, do you know when this config file was created and if it was
>> manually modified?
>> Is this an upgrade from oVirt 4.1?
>>
>>
>>> [root@dc02-ovirt01 log]# cat
>>> /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
>>> # This file is automatically generated by engine-setup. Please do not
>>> edit manually
>>> [OVN REMOTE]
>>> ovn-remote=tcp:127.0.0.1:6641
>>> [SSL]
>>> https-enabled=false
>>> ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
>>> ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
>>> ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
>>> [OVIRT]
>>> ovirt-sso-client-secret=*random_test*
>>> ovirt-host=https://dc02-ovirt01.testdomain.com:443
>>> ovirt-sso-client-id=ovirt-provider-ovn
>>> ovirt-ca-file=/etc/pki/ovirt-engine/apache-ca.pem
>>> [NETWORK]
>>> port-security-enabled-default=True
>>> [PROVIDER]
>>>
>>> provider-host=dc02-ovirt01.testdomain.com
>>>
>>> The only entry missing is the [AUTH] and under [SSL] the https-enabled
>>> is false. Should I edit this in this file or is this going to break
>>> everything?
>>>
>>>
>> Changing the file should improve, but better create a backup into another
>> diretory before modification.
>> The only required change is
>> from
>> ovn-remote=tcp:127.0.0.1:6641
>> to
>> ovn-remote=ssl:127.0.0.1:6641
>>
>>
>>
>>
>>> On Tue, Sep 15, 2020 at 6:27 PM Dominik Holler 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 15, 2020 at 5:11 PM Konstantinos Betsis 
>>>> wrote:
>>>>
>>>>> Hi Dominik
>>>>>
>>>>> That immediately fixed the geneve tunnels between all hosts.
>>>>>
>>>>>
>>>> thanks for the feedback.
>>>>
>>>>
>>>>> However, the ovn provider is not broken.
>>>>> After fixing the networks we tried to move a VM to the DC01-host01 so
>>>>> we powered it down and simply configured it to run on dc01-node01.
>>>>>
>>>>> While checking the logs on the ovirt engine i noticed the below:
>>>>> Failed to synchronize networks of Provider ovirt-provider-ovn.
>>>>>
>>>>> The ovn-provider co

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-09-15 Thread Dominik Holler
On Tue, Sep 15, 2020 at 5:34 PM Konstantinos Betsis 
wrote:

> There is a file with the below entries
>

Impressive, do you know when this config file was created and if it was
manually modified?
Is this an upgrade from oVirt 4.1?


> [root@dc02-ovirt01 log]# cat
> /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
> # This file is automatically generated by engine-setup. Please do not edit
> manually
> [OVN REMOTE]
> ovn-remote=tcp:127.0.0.1:6641
> [SSL]
> https-enabled=false
> ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
> ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
> ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
> [OVIRT]
> ovirt-sso-client-secret=*random_test*
> ovirt-host=https://dc02-ovirt01.testdomain.com:443
> ovirt-sso-client-id=ovirt-provider-ovn
> ovirt-ca-file=/etc/pki/ovirt-engine/apache-ca.pem
> [NETWORK]
> port-security-enabled-default=True
> [PROVIDER]
>
> provider-host=dc02-ovirt01.testdomain.com
>
> The only entry missing is the [AUTH] and under [SSL] the https-enabled is
> false. Should I edit this in this file or is this going to break
> everything?
>
>
Changing the file should improve, but better create a backup into another
diretory before modification.
The only required change is
from
ovn-remote=tcp:127.0.0.1:6641
to
ovn-remote=ssl:127.0.0.1:6641




> On Tue, Sep 15, 2020 at 6:27 PM Dominik Holler  wrote:
>
>>
>>
>> On Tue, Sep 15, 2020 at 5:11 PM Konstantinos Betsis 
>> wrote:
>>
>>> Hi Dominik
>>>
>>> That immediately fixed the geneve tunnels between all hosts.
>>>
>>>
>> thanks for the feedback.
>>
>>
>>> However, the ovn provider is not broken.
>>> After fixing the networks we tried to move a VM to the DC01-host01 so we
>>> powered it down and simply configured it to run on dc01-node01.
>>>
>>> While checking the logs on the ovirt engine i noticed the below:
>>> Failed to synchronize networks of Provider ovirt-provider-ovn.
>>>
>>> The ovn-provider configure on the engine is the below:
>>> Name: ovirt-provider-ovn
>>> Description: oVirt network provider for OVN
>>> Type: External Network Provider
>>> Network Plugin: oVirt Network Provider for OVN
>>> Automatic Synchronization: Checked
>>> Unmanaged: Unchecked
>>> Provider URL: http:localhost:9696
>>> Requires Authentication: Checked
>>> Username: admin@internal
>>> Password: "The admin password"
>>> Protocol: hTTP
>>> Host Name: dc02-ovirt01
>>> API Port: 35357
>>> API Version: v2.0
>>> Tenant Name: "Empty"
>>>
>>> In the past this was deleted by an engineer and recreated as per the
>>> documentation, and it worked. Do we need to update something due to the SSL
>>> on the ovn?
>>>
>>>
>> Is there a file in /etc/ovirt-provider-ovn/conf.d/ ?
>> engine-setup should have created one.
>> If the file is missing, for testing purposes, you can create a
>> file /etc/ovirt-provider-ovn/conf.d/00-setup-ovirt-provider-ovn-test.conf :
>> [PROVIDER]
>> provider-host=REPLACE_WITH_FQDN
>> [SSL]
>> ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
>> ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
>> ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
>> https-enabled=true
>> [OVN REMOTE]
>> ovn-remote=ssl:127.0.0.1:6641
>> [AUTH]
>> auth-plugin=auth.plugins.static_token:NoAuthPlugin
>> [NETWORK]
>> port-security-enabled-default=True
>>
>> and restart the ovirt-provider-ovn service.
>>
>>
>>
>>
>>> From the ovn-provider logs the below is generated after a service
>>> restart and when the start VM is triggered
>>>
>>> 2020-09-15 15:07:33,579 root Starting server
>>> 2020-09-15 15:07:33,579 root Version: 1.2.29-1
>>> 2020-09-15 15:07:33,579 root Build date: 20191217125241
>>> 2020-09-15 15:07:33,579 root Githash: cb5a80d
>>> 2020-09-15 15:08:26,582 root From: :::127.0.0.1:59980 Request: GET
>>> /v2.0/ports
>>> 2020-09-15 15:08:26,582 root Could not retrieve schema from tcp:
>>> 127.0.0.1:6641: Unknown error -1
>>> Traceback (most recent call last):
>>>   File "/usr/share/ovirt-provider-ovn/handlers/base_handler.py", line
>>> 138, in _handle_request
>>> method, path_parts, content
>>>   File "/usr/share/ovirt-provider-ovn/handlers/selecting_handler.py",
>>> line 175, in handle_reques

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-09-15 Thread Dominik Holler
On Tue, Sep 15, 2020 at 5:11 PM Konstantinos Betsis 
wrote:

> Hi Dominik
>
> That immediately fixed the geneve tunnels between all hosts.
>
>
thanks for the feedback.


> However, the ovn provider is not broken.
> After fixing the networks we tried to move a VM to the DC01-host01 so we
> powered it down and simply configured it to run on dc01-node01.
>
> While checking the logs on the ovirt engine i noticed the below:
> Failed to synchronize networks of Provider ovirt-provider-ovn.
>
> The ovn-provider configure on the engine is the below:
> Name: ovirt-provider-ovn
> Description: oVirt network provider for OVN
> Type: External Network Provider
> Network Plugin: oVirt Network Provider for OVN
> Automatic Synchronization: Checked
> Unmanaged: Unchecked
> Provider URL: http:localhost:9696
> Requires Authentication: Checked
> Username: admin@internal
> Password: "The admin password"
> Protocol: hTTP
> Host Name: dc02-ovirt01
> API Port: 35357
> API Version: v2.0
> Tenant Name: "Empty"
>
> In the past this was deleted by an engineer and recreated as per the
> documentation, and it worked. Do we need to update something due to the SSL
> on the ovn?
>
>
Is there a file in /etc/ovirt-provider-ovn/conf.d/ ?
engine-setup should have created one.
If the file is missing, for testing purposes, you can create a
file /etc/ovirt-provider-ovn/conf.d/00-setup-ovirt-provider-ovn-test.conf :
[PROVIDER]
provider-host=REPLACE_WITH_FQDN
[SSL]
ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
https-enabled=true
[OVN REMOTE]
ovn-remote=ssl:127.0.0.1:6641
[AUTH]
auth-plugin=auth.plugins.static_token:NoAuthPlugin
[NETWORK]
port-security-enabled-default=True

and restart the ovirt-provider-ovn service.




> From the ovn-provider logs the below is generated after a service restart
> and when the start VM is triggered
>
> 2020-09-15 15:07:33,579 root Starting server
> 2020-09-15 15:07:33,579 root Version: 1.2.29-1
> 2020-09-15 15:07:33,579 root Build date: 20191217125241
> 2020-09-15 15:07:33,579 root Githash: cb5a80d
> 2020-09-15 15:08:26,582 root From: :::127.0.0.1:59980 Request: GET
> /v2.0/ports
> 2020-09-15 15:08:26,582 root Could not retrieve schema from tcp:
> 127.0.0.1:6641: Unknown error -1
> Traceback (most recent call last):
>   File "/usr/share/ovirt-provider-ovn/handlers/base_handler.py", line 138,
> in _handle_request
> method, path_parts, content
>   File "/usr/share/ovirt-provider-ovn/handlers/selecting_handler.py", line
> 175, in handle_request
> return self.call_response_handler(handler, content, parameters)
>   File "/usr/share/ovirt-provider-ovn/handlers/neutron.py", line 35, in
> call_response_handler
> with NeutronApi() as ovn_north:
>   File "/usr/share/ovirt-provider-ovn/neutron/neutron_api.py", line 95, in
> __init__
> self.ovsidl, self.idl = ovn_connection.connect()
>   File "/usr/share/ovirt-provider-ovn/ovn_connection.py", line 46, in
> connect
> ovnconst.OVN_NORTHBOUND
>   File
> "/usr/lib/python2.7/site-packages/ovsdbapp/backend/ovs_idl/connection.py",
> line 127, in from_server
> helper = idlutils.get_schema_helper(connection_string, schema_name)
>   File
> "/usr/lib/python2.7/site-packages/ovsdbapp/backend/ovs_idl/idlutils.py",
> line 128, in get_schema_helper
> 'err': os.strerror(err)})
> Exception: Could not retrieve schema from tcp:127.0.0.1:6641: Unknown
> error -1
>
>
> When i update the ovn provider from the GUI to have
> https://localhost:9696/ and HTTPS as the protocol the test fails.
>
> On Tue, Sep 15, 2020 at 5:35 PM Dominik Holler  wrote:
>
>>
>>
>> On Mon, Sep 14, 2020 at 9:25 AM Konstantinos Betsis 
>> wrote:
>>
>>> Hi Dominik
>>>
>>> When these commands are used on the ovirt-engine host the output is the
>>> one depicted in your email.
>>> For your reference see also below:
>>>
>>> [root@ath01-ovirt01 certs]# ovn-nbctl get-ssl
>>> Private key: /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass
>>> Certificate: /etc/pki/ovirt-engine/certs/ovn-ndb.cer
>>> CA Certificate: /etc/pki/ovirt-engine/ca.pem
>>> Bootstrap: false
>>> [root@ath01-ovirt01 certs]# ovn-nbctl get-connection
>>> ptcp:6641
>>>
>>> [root@ath01-ovirt01 certs]# ovn-sbctl get-ssl
>>> Private key: /etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass
>>> Certificate: /etc/pki/ovirt-engine/certs/ovn-sdb.cer
>>> CA Certificate: /etc/pki/ovirt-engine/ca.pem
>>>

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-09-15 Thread Dominik Holler
gt; received SSL data on JSON-RPC channel
> 2020-09-14T07:18:59.263Z|219652|reconnect|WARN|tcp:DC01-host02:37048:
> connection dropped (Protocol error)
> 2020-09-14T07:19:02.220Z|219653|reconnect|WARN|tcp:DC02-host01:33152:
> connection dropped (Protocol error)
> 2020-09-14T07:19:06.316Z|219654|reconnect|WARN|tcp:DC01-host01:51194:
> connection dropped (Protocol error)
> 2020-09-14T07:19:07.386Z|219655|reconnect|WARN|tcp:DC01-host02:37050:
> connection dropped (Protocol error)
> 2020-09-14T07:19:10.232Z|219656|reconnect|WARN|tcp:DC02-host01:33154:
> connection dropped (Protocol error)
> 2020-09-14T07:19:14.439Z|219657|jsonrpc|WARN|Dropped 4 log messages in
> last 12 seconds (most recently, 4 seconds ago) due to excessive rate
> 2020-09-14T07:19:14.439Z|219658|jsonrpc|WARN|tcp:DC01-host01:51196: error
> parsing stream: line 0, column 0, byte 0: invalid character U+0016
> 2020-09-14T07:19:14.439Z|219659|jsonrpc|WARN|Dropped 4 log messages in
> last 12 seconds (most recently, 4 seconds ago) due to excessive rate
> 2020-09-14T07:19:14.439Z|219660|jsonrpc|WARN|tcp:DC01-host01:51196:
> received SSL data on JSON-RPC channel
> 2020-09-14T07:19:14.440Z|219661|reconnect|WARN|tcp:DC01-host01:51196:
> connection dropped (Protocol error)
> 2020-09-14T07:19:15.505Z|219662|reconnect|WARN|tcp:DC01-host02:37052:
> connection dropped (Protocol error)
>
>
> How can we fix these SSL errors?
>

I addressed this above.


> I thought vdsm did the certificate provisioning on the host nodes as to
> communicate to the engine host node.
>
>
Yes, this seems to work in your scenario, just the SSL configuration on the
ovn-central was lost.


> On Fri, Sep 11, 2020 at 6:39 PM Dominik Holler  wrote:
>
>> Looks still like the ovn-controller on the host has problems
>> communicating with ovn-southbound.
>>
>> Are there any hints in /var/log/openvswitch/*.log,
>> especially in /var/log/openvswitch/ovsdb-server-sb.log ?
>>
>> Can you please check the output of
>>
>> ovn-nbctl get-ssl
>> ovn-nbctl get-connection
>> ovn-sbctl get-ssl
>> ovn-sbctl get-connection
>> ls -l /etc/pki/ovirt-engine/keys/ovn-*
>>
>> it should be similar to
>>
>> [root@ovirt-43 ~]# ovn-nbctl get-ssl
>> Private key: /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass
>> Certificate: /etc/pki/ovirt-engine/certs/ovn-ndb.cer
>> CA Certificate: /etc/pki/ovirt-engine/ca.pem
>> Bootstrap: false
>> [root@ovirt-43 ~]# ovn-nbctl get-connection
>> pssl:6641:[::]
>> [root@ovirt-43 ~]# ovn-sbctl get-ssl
>> Private key: /etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass
>> Certificate: /etc/pki/ovirt-engine/certs/ovn-sdb.cer
>> CA Certificate: /etc/pki/ovirt-engine/ca.pem
>> Bootstrap: false
>> [root@ovirt-43 ~]# ovn-sbctl get-connection
>> read-write role="" pssl:6642:[::]
>> [root@ovirt-43 ~]# ls -l /etc/pki/ovirt-engine/keys/ovn-*
>> -rw-r-. 1 root hugetlbfs 1828 Oct 14  2019
>> /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass
>> -rw---. 1 root root  2709 Oct 14  2019
>> /etc/pki/ovirt-engine/keys/ovn-ndb.p12
>> -rw-r-. 1 root hugetlbfs 1828 Oct 14  2019
>> /etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass
>> -rw---. 1 root root  2709 Oct 14  2019
>> /etc/pki/ovirt-engine/keys/ovn-sdb.p12
>>
>>
>>
>>
>> On Fri, Sep 11, 2020 at 1:10 PM Konstantinos Betsis 
>> wrote:
>>
>>> I did a restart of the ovn-controller, this is the output of the
>>> ovn-controller.log
>>>
>>> 2020-09-11T10:54:07.566Z|1|vlog|INFO|opened log file
>>> /var/log/openvswitch/ovn-controller.log
>>> 2020-09-11T10:54:07.568Z|2|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>>> connecting...
>>> 2020-09-11T10:54:07.568Z|3|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>>> connected
>>> 2020-09-11T10:54:07.570Z|4|main|INFO|OVS IDL reconnected, force
>>> recompute.
>>> 2020-09-11T10:54:07.571Z|5|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
>>> connecting...
>>> 2020-09-11T10:54:07.571Z|6|main|INFO|OVNSB IDL reconnected, force
>>> recompute.
>>> 2020-09-11T10:54:07.685Z|7|stream_ssl|WARN|SSL_connect: unexpected
>>> SSL connection close
>>> 2020-09-11T10:54:07.685Z|8|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
>>> connection attempt failed (Protocol error)
>>> 2020-09-11T10:54:08.685Z|9|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
>>> connecting...
>>> 2020-09-11T10:54:08.800Z|00010|stream_ssl|WARN|SSL_connect: unexpected
>>> SSL connection close
>>> 2020-09-11T10:54:08.800Z|00011|reconnect|INFO|ssl:OV

[ovirt-users] Re: Probably dns problem: Internal JSON-RPC error

2020-09-14 Thread Dominik Holler
On Sun, Sep 13, 2020 at 11:35 AM Yedidyah Bar David  wrote:

> On Sun, Sep 13, 2020 at 11:27 AM  wrote:
> >
> > I have a clean installed CentOS 8.2 2004 on my server. The self hosted
> engine deploy (ovirt-4.4) aborts with the following message:
> >
> > [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The
> host has been set in non_operational status, deployment errors: code 505:
> Host red.colors.ovirt.local installation failed. Failed to configure
> management network on the host., code 1120: Failed to configure management
> network on host red.colors.ovirt.local due to setup networks failure., code
> 9000: Failed to verify Power Management configuration for Host
> red.colors.ovirt.local., code 10802: VDSM red.colors.ovirt.local command
> HostSetupNetworksVDS failed: Internal JSON-RPC error:
> > {'reason': '
> > desired
> > ===
> > ---
> > dns-resolver:
> >  search: []
> >  server:
> >  - 192.168.2.150
> >  - fe80::1%eno1
> >
> >  current
> >  ===
> >  ---
> >  dns-resolver:
> >  search: []
> >  server:
> >  - 192.168.2.150
> >
> >  difference
> >  ==
> >  --- desired
> >  +++ current
> >  @@ -3,4 +3,3 @@
> >  search: []
> >  server:
> >  - 192.168.2.150
> >  - - fe80::1%eno1
> >
> >  '}, fix accordingly and re-deploy."}
> >
> > ~# cat /etc/resolv.conf
> >  # Generated by NetworkManager
> >  search colors.ovirt.local
> >  nameserver 192.168.2.150
> >  nameserver fe80::1%eno1
> >
> > I am confused, because the probalby missing line is present. Is there
> maybe another config file, where this last line could be missing?
> > Maybe I can force somehow the installer, to reload the resolv conf, so
> it can fetch ne new line?
>
> Can you please check/share other relevant logs (and perhaps other
> parts of this one)? Perhaps upload somewhere and share a link, or open
> a bug in bugzilla and attach there.
>
> Adding Dominik.
>
> Perhaps we fail to parse the line 'nameserver fe80::1%eno1'?
>
>
Yes, IPv6 link local nameserver might not work for static IP addresses, but
might work for dynamic.
Also mixing IPv4 and IPv6 nameservers might confuse lower layers.

Can you share at least the line containing
"call setupNetworks with "
and
"desired state"
of supervdsm.log?




> Thanks and best regards,
> --
> Didi
>
>
___
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:


[ovirt-users] Re: OVN Geneve tunnels not been established

2020-09-11 Thread Dominik Holler
Looks still like the ovn-controller on the host has problems communicating
with ovn-southbound.

Are there any hints in /var/log/openvswitch/*.log,
especially in /var/log/openvswitch/ovsdb-server-sb.log ?

Can you please check the output of

ovn-nbctl get-ssl
ovn-nbctl get-connection
ovn-sbctl get-ssl
ovn-sbctl get-connection
ls -l /etc/pki/ovirt-engine/keys/ovn-*

it should be similar to

[root@ovirt-43 ~]# ovn-nbctl get-ssl
Private key: /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass
Certificate: /etc/pki/ovirt-engine/certs/ovn-ndb.cer
CA Certificate: /etc/pki/ovirt-engine/ca.pem
Bootstrap: false
[root@ovirt-43 ~]# ovn-nbctl get-connection
pssl:6641:[::]
[root@ovirt-43 ~]# ovn-sbctl get-ssl
Private key: /etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass
Certificate: /etc/pki/ovirt-engine/certs/ovn-sdb.cer
CA Certificate: /etc/pki/ovirt-engine/ca.pem
Bootstrap: false
[root@ovirt-43 ~]# ovn-sbctl get-connection
read-write role="" pssl:6642:[::]
[root@ovirt-43 ~]# ls -l /etc/pki/ovirt-engine/keys/ovn-*
-rw-r-. 1 root hugetlbfs 1828 Oct 14  2019
/etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass
-rw---. 1 root root  2709 Oct 14  2019
/etc/pki/ovirt-engine/keys/ovn-ndb.p12
-rw-r-. 1 root hugetlbfs 1828 Oct 14  2019
/etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass
-rw---. 1 root root  2709 Oct 14  2019
/etc/pki/ovirt-engine/keys/ovn-sdb.p12




On Fri, Sep 11, 2020 at 1:10 PM Konstantinos Betsis 
wrote:

> I did a restart of the ovn-controller, this is the output of the
> ovn-controller.log
>
> 2020-09-11T10:54:07.566Z|1|vlog|INFO|opened log file
> /var/log/openvswitch/ovn-controller.log
> 2020-09-11T10:54:07.568Z|2|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
> connecting...
> 2020-09-11T10:54:07.568Z|3|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
> connected
> 2020-09-11T10:54:07.570Z|4|main|INFO|OVS IDL reconnected, force
> recompute.
> 2020-09-11T10:54:07.571Z|5|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> connecting...
> 2020-09-11T10:54:07.571Z|6|main|INFO|OVNSB IDL reconnected, force
> recompute.
> 2020-09-11T10:54:07.685Z|7|stream_ssl|WARN|SSL_connect: unexpected SSL
> connection close
> 2020-09-11T10:54:07.685Z|8|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> connection attempt failed (Protocol error)
> 2020-09-11T10:54:08.685Z|9|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> connecting...
> 2020-09-11T10:54:08.800Z|00010|stream_ssl|WARN|SSL_connect: unexpected SSL
> connection close
> 2020-09-11T10:54:08.800Z|00011|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> connection attempt failed (Protocol error)
> 2020-09-11T10:54:08.800Z|00012|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> waiting 2 seconds before reconnect
> 2020-09-11T10:54:10.802Z|00013|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> connecting...
> 2020-09-11T10:54:10.917Z|00014|stream_ssl|WARN|SSL_connect: unexpected SSL
> connection close
> 2020-09-11T10:54:10.917Z|00015|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> connection attempt failed (Protocol error)
> 2020-09-11T10:54:10.917Z|00016|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> waiting 4 seconds before reconnect
> 2020-09-11T10:54:14.921Z|00017|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> connecting...
> 2020-09-11T10:54:15.036Z|00018|stream_ssl|WARN|SSL_connect: unexpected SSL
> connection close
> 2020-09-11T10:54:15.036Z|00019|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> connection attempt failed (Protocol error)
> 2020-09-11T10:54:15.036Z|00020|reconnect|INFO|ssl:OVIRT_ENGINE_IP:6642:
> continuing to reconnect in the background but suppressing further logging
>
>
> I have also done the vdsm-tool ovn-config OVIRT_ENGINE_IP
> OVIRTMGMT_NETWORK_DC
> This is how the OVIRT_ENGINE_IP is provided in the ovn controller, i can
> redo it if you wan.
>
> After the restart of the ovn-controller the OVIRT ENGINE still shows only
> two geneve connections one with DC01-host02 and DC02-host01.
> Chassis "c4b23834-aec7-4bf8-8be7-aa94a50a6144"
> hostname: "dc02-host01"
> Encap geneve
> ip: "DC02-host01_IP"
> options: {csum="true"}
> Chassis "be3abcc9-7358-4040-a37b-8d8a782f239c"
> hostname: "DC01-host02"
> Encap geneve
> ip: "DC01-host02"
> options: {csum="true"}
>
> I've re-done the vdsm-tool command and nothing changed againwith
> the same errors as the systemctl restart ovn-controller
>
> On Fri, Sep 11, 2020 at 1:49 PM Dominik Holler  wrote:
>
>> Please include ovirt-users list in your reply, to share the knowledge and
>> experience with the community!
>>
>> On Fri, Sep 11, 2020 at 12:12 PM Konstantinos Betsis 
>> wrote:
>>
>>> Ok below the output per nod

[ovirt-users] Re: Newbie question on network

2020-09-11 Thread Dominik Holler
On Fri, Sep 11, 2020 at 12:04 AM Valerio Luccio 
wrote:

> Understood, but how ? I'm using the oVirt Visualization Manager 4.4. I see
> a "Network" tab where I can create a new network and a new vNIC profile,
> but a) I don't see how I associate the new network with the bridge I
> created
>

After adding the host to oVirt Engine, please avoid touching the network
configuration of the host manually, oVirt will take care of the host's
network configuration.
Please remove the manually created bridge and open the oVirt Administration
Portal in a browser and browse to
Compute > Hosts > HOSTNAME > Network Interfaces, open the "Setup Host
Networks" dialog and assign the logical network to the NIC.
Did this work for you?



> and b) if I try to add this new network to my VM I get a message that says
> that the network does not exist on the host (which makes sense since the
> network I created is not connected to anything).
>
> I must say that all the examples I found online use a GUI that looks quite
> different from the one I have. Is there a separate GUI I should be running ?
>
> On 9/10/20 1:25 PM, Edward Berger wrote:
>
> The usual process to add another network bridge is to configure a new
> cluster logical network in the engine,
> then configure specific network interfaces on all hypervisors through the
> engine's "configure host networks".
>
>
>
>
>
>
>
> On Thu, Sep 10, 2020 at 11:43 AM Valerio Luccio 
> wrote:
>
>> That was my first thought, so I tried to set up manually the default
>> route and netmask on the VM to match the engine's, but it didn't solve the
>> problem.
>>
>> Another network question: I have a second network card on the host that
>> is connected to an internal switch, how do I add a bridge for that card to
>> be used by the VMs ? I created a secondary bridge on the host and then I
>> tried to play with the network options on the oVirt portal, but I couldn't
>> figure out to associate the new bridge with an new network. Before anyone
>> thinks that the two issues are related, I did this after failing to solve
>> the first issue.
>>
>> On 9/10/20 8:00 AM, Edward Berger wrote:
>>
>> It sounds like you don't have a proper default route on the VM or the
>> netmask is set incorrectly,
>> which can cause a bad route.
>>
>> Look at differences between the engine's network config (presuming it can
>> reach outside the hypervisor host)
>> and the VM's config.   The VM should have the same subnet, netmask and
>> default gateway as the engine VM,
>> if its connected to ovirtmgmt.
>>
>> "ip a" "ip r" "traceroute" and "ping" are the usual commands to check
>> network connections.
>>
>>
>>
>>
>> On Thu, Sep 10, 2020 at 6:29 AM  wrote:
>>
>>> I apologize for asking what is probably a very basic question.
>>>
>>> I installed and created a self-hosted engine using cockpit on a server.
>>> I can reach the self-hosted engine from anywhere within my network.
>>>
>>> I then created a new VM selecting the default ovirtmgmt for the network.
>>> The VM does not seem to connect to the network via the bridge. I the used
>>> the console to manually configured the network card and I have connectivity
>>> between the VM, the engine and the server, but not beyond. What am I doing
>>> wrong ? Can someone point to a good documentation page on the subject ?
>>>
>>> Thanks in advance,
>>> Valerio
>>> ___
>>> 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/IFXOOU4DVR66DWEUCR66CJ2LQFUFCN55/
>>> 
>>>
>>
>> --
>> As a result of Coronavirus-related precautions, NYU and the Center for
>> Brain Imaging operations will be managed remotely until further notice.
>> All telephone calls and e-mail correspondence are being monitored
>> remotely during our normal business hours of 9am-5pm, Monday through Friday.
>>
>> For MRI scanner-related emergency, please contact: Keith 

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-09-11 Thread Dominik Holler
On Thu, Sep 10, 2020 at 6:26 PM Konstantinos B  wrote:

> Hi all
>
> We have a small installation based on OVIRT 4.3.
> 1 Cluster is based on Centos 7 and the other on OVIRT NG Node image.
>
> The environment was stable till an upgrade took place a couple of months
> ago.
> As such we had to re-install one of the Centos 7 node and start from
> scratch.
>

To trigger the automatic configuration of the host, it is required to
configure ovirt-provider-ovn as the default network provider for the
cluster before adding the host to oVirt.


> Even though the installation completed successfully and VMs are created,
> the following are not working as expected:
> 1. ovn geneve tunnels are not established with the other Centos 7 node in
> the cluster.
> 2. Centos 7 node is configured by ovirt engine however no geneve tunnel is
> established when "ovn-sbctl show" is issued on the engine.
>

Does "ovn-sbctl show" list the hosts?


> 3. no flows are shown on the engine on port 6642 for the ovs db.
>
> Does anyone have any experience on how to troubleshoot OVN on ovirt?
>
>
/var/log/openvswitch/ovncontroller.log on the host should contain a helpful
hint.



> Thank you
> ___
> 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/LBVGLQJBWJF3EKFITPR72LBPA5A43WWW/
>
___
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:


[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-04 Thread Dominik Holler
Sverker, is this bug blocking you, or can you work around it?

On Thu, Sep 3, 2020 at 8:52 PM Dominik Holler  wrote:

> Sverker, thanks!
>
> On Thu, Sep 3, 2020 at 6:50 PM Sverker Abrahamsson <
> sver...@abrahamsson.com> wrote:
>
>> Hi Dominik,
>> bug filed at https://bugzilla.redhat.com/show_bug.cgi?id=1875520. I'm
>> doing a new install to get fresh vdsm and supervdsm logs which will be
>> attached as soon as they've failed.
>> /Sverker
>> Den 2020-09-03 kl. 18:03, skrev Dominik Holler:
>>
>>
>>
>> On Thu, Sep 3, 2020 at 12:42 PM Sverker Abrahamsson <
>> sver...@abrahamsson.com> wrote:
>>
>>> Hi Ales,
>>> this is a CentOS 8 so my impression was that you always have
>>> NetworkManager then? At least my attempt to remove it failed miserably.
>>>
>>
>> Yes, on CentOS 8 hosts oVirt requires the interfaces managed by
>> NetworkManager.
>>
>>
>>> The enp4s0 config was created by the install, so it should be controlled
>>> by NetworkManager.
>>>
>>
>> This should work. Can you please report a bug on vdsm [1]?
>> Would be helpful if the vdsm.log and supervdsm.log would be attached to
>> this bug.
>>
>> [1]
>>   https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm
>>
>>
>>
>>> /Sverker
>>> Den 2020-09-03 kl. 12:29, skrev Ales Musil:
>>>
>>>
>>>
>>> On Thu, Sep 3, 2020 at 12:21 PM Sverker Abrahamsson <
>>> sver...@abrahamsson.com> wrote:
>>>
>>>> Hi Ales,
>>>> right now I have a manually created ovirtmgmt bridge (virbr0 and vnet0
>>>> seems to be created during the failed attempt to deploy hosted engine):
>>>>
>>>> [root@h1-mgmt ~]# nmcli con show
>>>> NAME  UUID  TYPE  DEVICE
>>>> enp4s0af7ccb53-011b-4c36-998a-1878b4ae7100  ethernet  enp4s0
>>>> Bridge ovirtmgmt  9a0b07c0-2983-fe97-ec7f-ad2b51c3a3f0  bridge
>>>> ovirtmgmt
>>>> virbr0aa593151-2c12-4cf7-985b-f105b3575d09  bridgevirbr0
>>>> enp4s0.4000   ecc8064d-18c1-99b7-3fe4-9c5a593ece6f  vlan
>>>> enp4s0.4000
>>>> vnet0 a6db45bd-93c8-4c37-85fc-0c58ba3e9d00  tun   vnet0
>>>> [root@h1-mgmt ~]# nmstatectl show
>>>> ---
>>>> dns-resolver:
>>>>   config:
>>>> search: []
>>>> server:
>>>> - 213.133.98.98
>>>>   running:
>>>> search: []
>>>> server:
>>>> - 213.133.98.98
>>>> route-rules:
>>>>   config: []
>>>> routes:
>>>>   config:
>>>>   - destination: 0.0.0.0/0
>>>> metric: -1
>>>> next-hop-address: 144.76.84.65
>>>> next-hop-interface: enp4s0
>>>> table-id: 0
>>>>   - destination: ::/0
>>>> metric: -1
>>>> next-hop-address: fe80::1
>>>> next-hop-interface: enp4s0
>>>> table-id: 0
>>>>   running:
>>>>   - destination: 0.0.0.0/0
>>>> metric: 100
>>>> next-hop-address: 144.76.84.65
>>>> next-hop-interface: enp4s0
>>>> table-id: 254
>>>>   - destination: 144.76.84.65/32
>>>> metric: 100
>>>> next-hop-address: ''
>>>> next-hop-interface: enp4s0
>>>> table-id: 254
>>>>   - destination: 172.27.1.0/24
>>>> metric: 425
>>>> next-hop-address: ''
>>>> next-hop-interface: ovirtmgmt
>>>> table-id: 254
>>>>   - destination: 192.168.1.0/24
>>>> metric: 0
>>>> next-hop-address: ''
>>>> next-hop-interface: virbr0
>>>> table-id: 254
>>>>   - destination: 2a01:4f8:192:1148::/64
>>>> metric: 100
>>>> next-hop-address: ''
>>>> next-hop-interface: enp4s0
>>>> table-id: 254
>>>>   - destination: ::/0
>>>> metric: 100
>>>> next-hop-address: fe80::1
>>>> next-hop-interface: enp4s0
>>>> table-id: 254
>>>>   - destination: fe80::/64
>>>> metric: 100
>>>> next-hop-address: ''
>>>> next-hop-interface: enp4s0
>>>> table-id: 254
>>>>   - destination: ff00::/8
>>>> metric: 256
>>>> next-hop-

[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-03 Thread Dominik Holler
Sverker, thanks!

On Thu, Sep 3, 2020 at 6:50 PM Sverker Abrahamsson 
wrote:

> Hi Dominik,
> bug filed at https://bugzilla.redhat.com/show_bug.cgi?id=1875520. I'm
> doing a new install to get fresh vdsm and supervdsm logs which will be
> attached as soon as they've failed.
> /Sverker
> Den 2020-09-03 kl. 18:03, skrev Dominik Holler:
>
>
>
> On Thu, Sep 3, 2020 at 12:42 PM Sverker Abrahamsson <
> sver...@abrahamsson.com> wrote:
>
>> Hi Ales,
>> this is a CentOS 8 so my impression was that you always have
>> NetworkManager then? At least my attempt to remove it failed miserably.
>>
>
> Yes, on CentOS 8 hosts oVirt requires the interfaces managed by
> NetworkManager.
>
>
>> The enp4s0 config was created by the install, so it should be controlled
>> by NetworkManager.
>>
>
> This should work. Can you please report a bug on vdsm [1]?
> Would be helpful if the vdsm.log and supervdsm.log would be attached to
> this bug.
>
> [1]
>   https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm
>
>
>
>> /Sverker
>> Den 2020-09-03 kl. 12:29, skrev Ales Musil:
>>
>>
>>
>> On Thu, Sep 3, 2020 at 12:21 PM Sverker Abrahamsson <
>> sver...@abrahamsson.com> wrote:
>>
>>> Hi Ales,
>>> right now I have a manually created ovirtmgmt bridge (virbr0 and vnet0
>>> seems to be created during the failed attempt to deploy hosted engine):
>>>
>>> [root@h1-mgmt ~]# nmcli con show
>>> NAME  UUID  TYPE  DEVICE
>>> enp4s0af7ccb53-011b-4c36-998a-1878b4ae7100  ethernet  enp4s0
>>> Bridge ovirtmgmt  9a0b07c0-2983-fe97-ec7f-ad2b51c3a3f0  bridge
>>> ovirtmgmt
>>> virbr0aa593151-2c12-4cf7-985b-f105b3575d09  bridgevirbr0
>>> enp4s0.4000   ecc8064d-18c1-99b7-3fe4-9c5a593ece6f  vlan
>>> enp4s0.4000
>>> vnet0 a6db45bd-93c8-4c37-85fc-0c58ba3e9d00  tun   vnet0
>>> [root@h1-mgmt ~]# nmstatectl show
>>> ---
>>> dns-resolver:
>>>   config:
>>> search: []
>>> server:
>>> - 213.133.98.98
>>>   running:
>>> search: []
>>> server:
>>> - 213.133.98.98
>>> route-rules:
>>>   config: []
>>> routes:
>>>   config:
>>>   - destination: 0.0.0.0/0
>>> metric: -1
>>> next-hop-address: 144.76.84.65
>>> next-hop-interface: enp4s0
>>> table-id: 0
>>>   - destination: ::/0
>>> metric: -1
>>> next-hop-address: fe80::1
>>> next-hop-interface: enp4s0
>>> table-id: 0
>>>   running:
>>>   - destination: 0.0.0.0/0
>>> metric: 100
>>> next-hop-address: 144.76.84.65
>>> next-hop-interface: enp4s0
>>> table-id: 254
>>>   - destination: 144.76.84.65/32
>>> metric: 100
>>> next-hop-address: ''
>>> next-hop-interface: enp4s0
>>> table-id: 254
>>>   - destination: 172.27.1.0/24
>>> metric: 425
>>> next-hop-address: ''
>>> next-hop-interface: ovirtmgmt
>>> table-id: 254
>>>   - destination: 192.168.1.0/24
>>> metric: 0
>>> next-hop-address: ''
>>> next-hop-interface: virbr0
>>> table-id: 254
>>>   - destination: 2a01:4f8:192:1148::/64
>>> metric: 100
>>> next-hop-address: ''
>>> next-hop-interface: enp4s0
>>> table-id: 254
>>>   - destination: ::/0
>>> metric: 100
>>> next-hop-address: fe80::1
>>> next-hop-interface: enp4s0
>>> table-id: 254
>>>   - destination: fe80::/64
>>> metric: 100
>>> next-hop-address: ''
>>> next-hop-interface: enp4s0
>>> table-id: 254
>>>   - destination: ff00::/8
>>> metric: 256
>>> next-hop-address: ''
>>> next-hop-interface: enp4s0
>>> table-id: 255
>>> interfaces:
>>> - name: ;vdsmdummy;
>>>   type: linux-bridge
>>>   state: down
>>>   ipv4:
>>> enabled: false
>>>   ipv6:
>>> enabled: false
>>>   mac-address: DE:D3:A8:24:27:F6
>>>   mtu: 1500
>>> - name: br-int
>>>   type: unknown
>>>   state: down
>>>   ipv4:
>>> enabled: false
>>>   ipv6:
>>> enabled: false
>>>   mac-address: 6E:37:94:63:E0:4B
>>>   mtu: 1500
>>>

[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-03 Thread Dominik Holler
gt;>   - destination: ff00::/8
>> metric: 256
>> next-hop-address: ''
>> next-hop-interface: enp4s0
>> table-id: 255
>> interfaces:
>> - name: ;vdsmdummy;
>>   type: linux-bridge
>>   state: down
>>   ipv4:
>> enabled: false
>>   ipv6:
>> enabled: false
>>   mac-address: B2:9E:E0:61:71:88
>>   mtu: 1500
>> - name: br-int
>>   type: unknown
>>   state: down
>>   ipv4:
>> enabled: false
>>   ipv6:
>> enabled: false
>>   mac-address: 6E:37:94:63:E0:4B
>>   mtu: 1500
>> - name: enp4s0
>>   type: ethernet
>>   state: up
>>   ethernet:
>> auto-negotiation: true
>> duplex: full
>> speed: 1000
>>   ipv4:
>> address:
>> - ip: 144.76.84.73
>>   prefix-length: 32
>> dhcp: false
>> enabled: true
>>   ipv6:
>> address:
>> - ip: 2a01:4f8:192:1148::2
>>   prefix-length: 64
>> - ip: fe80::62a4:4cff:fee9:4ac
>>   prefix-length: 64
>> auto-dns: true
>> auto-gateway: true
>> auto-routes: true
>> autoconf: true
>> dhcp: true
>> enabled: true
>>   mac-address: 60:A4:4C:E9:04:AC
>>   mtu: 1500
>> - name: enp4s0.4000
>>   type: vlan
>>   state: up
>>   ipv4:
>> address:
>> - ip: 172.27.1.1
>>   prefix-length: 24
>> dhcp: false
>> enabled: true
>>   ipv6:
>> autoconf: false
>> dhcp: false
>> enabled: false
>>   mac-address: 60:A4:4C:E9:04:AC
>>   mtu: 1500
>>   vlan:
>> base-iface: enp4s0
>> id: 4000
>> - name: lo
>>   type: unknown
>>   state: down
>>   ipv4:
>> enabled: false
>>   ipv6:
>> enabled: false
>>   mtu: 65536
>> - name: ovs-system
>>   type: unknown
>>   state: down
>>   ipv4:
>> enabled: false
>>   ipv6:
>> enabled: false
>>   mac-address: A2:35:7A:6C:B7:EF
>>   mtu: 1500
>>
>> /Sverker
>>
>
> Was the enp4s0 always managed by NetworkManager or only after the attempt
> to make the ovirtmgmt? If not that would explain the failure.
> Also the workaround would be to configure the interface via NetworkManager
> and then run the host deploy again.
>
> Thanks,
> Ales
>
>
>
>> Den 2020-09-03 kl. 11:54, skrev Ales Musil:
>>
>>
>>
>> On Thu, Sep 3, 2020 at 11:51 AM Sverker Abrahamsson via Users <
>> users@ovirt.org> wrote:
>>
>>> Hi Dominik
>>> That is my issue, I don't get to where I can get the ovirtmgmt bridge
>>> established because vdsm insists on creating it. It used to be possible to
>>> create that bridge statically and vdsm would just skip it but seems to be
>>> broken now.
>>>
>>> If it would be possible to use OVN for the management network that would
>>> solve my issue and would be the preferable solution, but as you write that
>>> isn't possible which was what I suspected.
>>>
>>> Do you have any other suggestion on how to solve this issue? That I get
>>> the external interface untagged and the internal network tagged is not
>>> possible to change.
>>>
>>> /Sverker
>>>
>>
>> Hello Sverker,
>>
>> can you please share output from "nmcli con show" and "nmstatectl show"?
>>
>> Thank you.
>> Regards,
>> Ales
>>
>>> Den 2020-09-03 kl. 10:52, skrev Dominik Holler:
>>>
>>>
>>>
>>> On Wed, Sep 2, 2020 at 10:38 PM Sverker Abrahamsson via Users <
>>> users@ovirt.org> wrote:
>>>
>>>> Well, unforturnatly I don't have a choise since it is out of my
>>>> control.
>>>> I only have one physical network port where the external traffic is
>>>> untagged and the internal vlan is tagged. If I could run with OVN
>>>>
>>>
>>> OVN is for VM traffic only, not usable for the management network.
>>>
>>>
>>>> instead I wouldn't need that tagged vlan, but I haven't been able to
>>>> get
>>>> that to work neither.
>>>>
>>>>
>>> Please let us know if OVN does not work for VM traffic for you.
>>>
>>>
>>>> It's perfectly possible to have both tagged and untagged traffic on the
>>>> same switch port, issue is that vdsm tries to take control over the
>>>> network without being able to be flexib

[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-03 Thread Dominik Holler
On Wed, Sep 2, 2020 at 10:38 PM Sverker Abrahamsson via Users <
users@ovirt.org> wrote:

> Well, unforturnatly I don't have a choise since it is out of my control.
> I only have one physical network port where the external traffic is
> untagged and the internal vlan is tagged. If I could run with OVN
>

OVN is for VM traffic only, not usable for the management network.


> instead I wouldn't need that tagged vlan, but I haven't been able to get
> that to work neither.
>
>
Please let us know if OVN does not work for VM traffic for you.


> It's perfectly possible to have both tagged and untagged traffic on the
> same switch port, issue is that vdsm tries to take control over the
> network without being able to be flexible enough.. I'm attempting now to
> have ovirtmgmt bridge created before, that used to be possible but
> according to previous mails on the list it went broken somewhere at 4.x.
>
> /Sverker
>
> Den 2020-09-02 kl. 21:39, skrev Strahil Nikolov:
> > Switchports can either be tagged or untagged.
> > I'm not sure that your setup is supported at all.
> >
> > Best Regards,
> > Strahil Nikolov
> >
> >
> >
> >
> >
> >
> > В сряда, 2 септември 2020 г., 20:41:57 Гринуич+3, Sverker Abrahamsson
> via Users  написа:
> >
> >
> >
> >
> >
> > Pretty formatting the "desired state" it seems that vdsm tries to remove
> > the ip of my underlying interface, that is enp4s0:
> >

> {
> >  'interfaces': [{
> >  'name': 'enp4s0',
> >  'state': 'up',
> >  'mtu': 1500
> >  }, {
> >  'vlan': {
> >  'id': 4000,
> >  'base-iface': 'enp4s0'
> >  },
> >  'name': 'enp4s0.4000',
> >  'type': 'vlan',
> >  'state': 'up',
> >  'mtu': 1500,
> >  'ipv4': {
> >  'enabled': False
> >  },
> >  'ipv6': {
> >  'enabled': False
> >  }
> >  }, {
> >  'name': 'ovirtmgmt',
> >  'type': 'linux-bridge',
> >  'state': 'up',
> >  'mtu': 1500,
> >  'bridge': {
> >  'port': [{
> >  'name': 'enp4s0.4000'
> >  }
> >  ],
> >  'options': {
> >  'stp': {
> >  'enabled': False
> >  }
> >  }
> >  },
> >  'ipv4': {
> >  'enabled': True,
> >  'address': [{
> >  'ip': '172.27.1.1',
> >  'prefix-length': 24
> >  }
> >  ],
> >  'dhcp': False
> >  },
> >  'ipv6': {
> >  'enabled': False
> >  }
> >  }
> >  ],
> >  'dns-resolver': {
> >  'config'
> >  : {
> >  'server': ['213.133.98.98']
> >  }
> >  }
> > }
> >
>

Thanks, this is helpful information.
Can you please share the getCapabilities result sent from vdsm to Engine
directly before the setupNetworks request,
and the parameters of the setupNetworks request from Engine to vdsm?
Both are in the vdsm.log during adding the host.


> >
> > This is my interfaces before vdsm attemtpts to change the config:
> >
> > enp4s0: flags=4163  mtu 1500
> >  inet 144.76.84.73  netmask 255.255.255.255  broadcast 0.0.0.0
> >  inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64  scopeid 0x20
> >  inet6 2a01:4f8:192:1148::2  prefixlen 64  scopeid 0x0
> >  ether 60:a4:4c:e9:04:ac  txqueuelen 1000  (Ethernet)
> >  RX packets 293442  bytes 385541799 (367.6 MiB)
> >  RX errors 0  dropped 0  overruns 0  frame 0
> >  TX packets 91095  bytes 31160348 (29.7 MiB)
> >  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >  device interrupt 17  memory 0xf7d0-f7d2
> >
> > enp4s0.4000: flags=4163  mtu 1500
> >  inet 172.27.1.1  netmask 255.255.255.0  broadcast 172.27.1.255
> >  inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64  scopeid 0x20
> >  ether 60:a4:4c:e9:04:ac  txqueuelen 1000  (Ethernet)
> >  RX packets 0  bytes 0 (0.0 B)
> >  RX errors 0  dropped 0  overruns 0  frame 0
> >  TX packets 13  bytes 938 (938.0 B)
> >  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > I.e. enp4s0 is the external interface that must not be changed, bridge
> > must be created on the vlan interface. I would prefer to create the
> > bridge manually and not through vdsm if that is possible.
> >
> > /Sverker
> >
> > Den 2020-09-02 kl. 19:14, skrev Sverker Abrahamsson via Users:
> >> Hi,
> >> I'm attempting to install hosted engine but getting this failure:
> >>
> >> [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg":
> >> "The host has been set in non_operational status, 

[ovirt-users] Re: Hosted engine + OVN

2020-09-03 Thread Dominik Holler
On Wed, Sep 2, 2020 at 9:08 PM Sverker Abrahamsson via Users <
users@ovirt.org> wrote:

> Was it ever solved to install hosted engine with ovn? I tried a few
> years ago, got it almost to work but then gave up.
>

OVN works with hosted engine.
Please let us know if you have any issues.


> ___
> 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/6KWV2MKV6E3ABQL6DGKVJ7FZTGNG3JPK/
>
___
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/S5CIYZICJMDL7DKHJRWJF2EUBIVWYSGM/


[ovirt-users] Re: HP blade G7, with be2net.

2020-09-01 Thread Dominik Holler
On Tue, Sep 1, 2020 at 7:27 AM Remulo  wrote:

> Hello
>
> I have some blades with 10GE interface that have / need the Emulex be2net
> driver, however it is no longer available on Redhat8 / Centos8.
>


Why do you think the be2net is not available on CentOS8?
"modprobe be2net" is succeeding for me.
Which NICs are you referring to?



> Is there any way to install ovirt to work on these machines?
>
>
Maybe not required here, but there is also the CentOS plus kernel, which
contains additional drivers.


> Here are some links to problems with Redhat.
>
> Emulex NIC using be2net driver
> https://access.redhat.com/solutions/1229853
> https://access.redhat.com/solutions/514353
>
> I did a lot of research and couldn't get a functional driver for ovirt.
>
> Thank you.
>
> --
> Atenciosamente,
> Rêmulo Ferreira.
> ___
> 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/JZY7GYTWN3VQDKD3X75AAD2CWSHHIP5I/
>
___
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/FJ7XEA2QACNMRC3I73PC2ELPFV5Z7EZZ/


[ovirt-users] Re: How to diable dhcp in ovirt network

2020-08-17 Thread Dominik Holler
On Mon, Aug 10, 2020 at 10:38 AM Adam Xu  wrote:

> Hi everyone
>
> Recently, when I install okd on ovirt. The installation process was failed
> because the vm automatically acquired an IP address from DHCP before the
> installer assigned it.
> Our DHCP is enabled by a layer 3 switch, I tried to diable dhcp using
> network filter. but there is no entry related to blocking the DHCP
> feature.  Is there any way for ovirt to disable DHCP?
>
>
Would a dedicated VLAN or ovirt-provider-ovn network help to isolate from
the DHCP server?


> --
> Adam Xu
>
> ___
> 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/EEKZHUOYW5KTKLBEHWVCSHNOMXCXVAVD/
>
___
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/MR4UZSOXFJOQ6QBGQJCBARIMMFXZDT22/


[ovirt-users] Request for feedback about "Overview of Networking in oVirt"

2020-08-11 Thread Dominik Holler
Hello,
there is a new documentation
"Overview of Networking in oVirt"
available in
https://www.ovirt.org/documentation/networking-overview/
Please let me know if you have any questions, comments, suggestions, or any
kind of critics about this text.
If you want to improve, you could also create directly a Pull Request on
https://github.com/ovirt/ovirt-site .

Thanks
Dominik
___
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/CKUSYEZR5BBGLHL3K5T4KD4YNYOREU5Q/


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

2020-07-31 Thread Dominik Holler
On Fri, Jul 31, 2020 at 12:54 AM Mark R  wrote:

> Following up, as noted in the bug report (
> https://bugzilla.redhat.com/show_bug.cgi?id=1860479 ) this doesn't appear
> to be oVirt / VDSM having issues. You can replicate the same inability to
> attach a bond to a bridge by simply booting the 8.2.2004 installation media
> and trying a few manual 'ip' commands. With older 8.1 or any 7.x install
> media, there's no problem, but starting with 8.2, you can't attach a bond
> to a bridge anymore.
>
> It looks like there may be some similar reports on bugzilla recently. I
> just wanted to note here on the list that this isn't an oVirt problem,
> looks to be an issue with the OS (kernel?).
>
> Thanks again!
>

Thanks for reporting the bug, providing additional information, and this
update. This is a very productive way to solve this issue.



> 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/KUUZJTAF5CWWIUFZPTZMKZFY5QIXUNKI/
>
___
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/7VT7B2CDHIDES26SAGVKS3X5IRFDTIKD/


[ovirt-users] Re: Changing FQDN

2020-07-31 Thread Dominik Holler
On Fri, Jul 31, 2020 at 2:44 PM Alex K  wrote:

> Hi all,
>
> I am running ovirt 4.2.8
> I did change ovirt engine FQDN using ovirt-engine-rename tool following
>
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/administration_guide/chap-Utilities#Updating_SSL_Certificates
>
> Hosts FQDN is also changed and all seem fine apart from OVN connection and
> ImageIO proxy.
>
> About OVN, i just configured OVN and when I test connection I get:
>
> Failed with error Certificate for  doesn't match any of the
> subject alternative names: [old fqdn] and code 5050)
>


Can you please replace all occurrences of the old fqdn by the new fqdn in
/etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
and
systemctl restart ovirt-provider-ovn
and let us know if this solves the problem?

This step is not yet automated by ovirt-engine-rename in oVirt-4.2. ,
please find more details in
https://bugzilla.redhat.com/1501798





>
> about Imageio proxy when I test the connection I do get nothing. No error
> at engine.log or at GUI.
>
> Thus it seems that I have to generate/replace new certs.
> Is there a way I can fix this until I switch to 4.3 and eventually to 4.4
> where it seems that this is handled from the rename tool?
>
> Thanks for any assistance.
> Alex.
>
> ___
> 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/XKOUI5FPDDUY3FGGOEBHTX5JQDMZ4DY6/
>
___
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/KGLUWBFXDZDEOFEGSIBCDE3FHUTVZX37/


[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: oVirt Network problem.

2020-07-22 Thread Dominik Holler
On Mon, Jul 20, 2020 at 2:19 PM Emil Dumitrache 
wrote:

> Hello,
> I am new to oVirt.
> I have a problem and I don't know how to deal with it, i added another
> network besides the management network and after that the node did not
> respond to the oVIrt manager.
> I had to change the DNS to the new IP of the new network so that oVIrt
> manager can manage it.
> Now i have an error:
> Out-of-sync: Default route: host true, DC false.
> I checked on the node and the second network has DEFROUTE=NO and the
> management network to yes. I don't know why the manager is seeing that.
> Also the management IP does not respond to ping or anything.
> Please some advice for a newbie?
>
>
Should not happen, but oVirt gives a high degree of freedom in network
configuration.
Can you please share more details about the IP configuration of both
networks and how do you applied it?
At least the IP addresses (or at least a relevant abstraction, if they are
public),  subnet masks and the gateway would be helpful.
The parts of vdsm.log and the supervdsm.log of the host written during the
configuration would be helpful, too.




> The setup is:
> A standalone server with Centos7 and oVIrt manager installed and a node
> with ovirt node os.
>
> Thank you.
>
> [image: Tremend Logo]
> Emil Dumitrache
> IT Support Manager
> [image: Mobile] +40720450085   [image: Phone] +40-212-237-700
> <0040212237700>
> [image: Email] emil.dumitra...@tremend.com   [image: Website]
> www.tremend.com
> [image: Facebook]   [image:
> LinkedIN]  [image: Skype]
> --
> Fastest growing Romanian company in Deloitte Fast 50 CE 2016
> ___
> 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/JAAP5NSR5IV4XW5BYSP344BPV3CKHW6A/
>
___
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/B4EQG4XDSBNMIAZETNFIQCKGVHQABHMZ/


[ovirt-users] Re: ovirt+SDN

2020-07-22 Thread Dominik Holler
On Mon, Jul 20, 2020 at 5:11 PM Marco Mangione 
wrote:

> hello,
>
> anyone are using OVIRT with a SDN controller?
>

Which scenario do you want to address?
oVirt includes ovirt-provider-ovn, which supports isolated networks


> ___
> 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/HWSKISKE2CS4VPK7JGCSUDAL3AB2K3MF/
>
___
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/J73FPA3EXMO5W2VX74BEIZQ23IAIKQ4J/


[ovirt-users] Re: VDSM not binding on IPv4 after ovirt-engine restart

2020-06-30 Thread Dominik Holler
On Tue, Jun 30, 2020 at 6:13 PM Erez Zarum  wrote:

> While troubleshooting a fresh installation of (after a failed one) that
> caused all the hosts but the one running the hosted-engine to become in
> “Unassigned” state I noticed that the ovirt-engine complains about not
> being able to contact the VDSM.
> I noticed that VDSM has stopped listening on IPv4.
>
>
Thanks for sharing the details.


> I didn’t disable any IPv6 as it states not to disable it on hosts that are
> capable running the hosted-engine  and it seems that the reason behind it
> is that the hosted-engine talks to the host it runs on through “localhost”,
> this also explains why the host which the hosted-engine runs on is “OK”.
>
> Below is from a host that does not run the hosted-engine:
> # ss -atn | grep 543
> LISTEN 0  5*:54322*:*
> ESTAB  0  0  127.0.0.1:54792  127.0.0.1:54321
> ESTAB  0  0  127.0.0.1:54798  127.0.0.1:54321
> LISTEN 0  5 [::]:54321 [::]:*
> ESTAB  0  0   [:::127.0.0.1]:54321
>  [:::127.0.0.1]:54798
> ESTAB  0  0   [:::127.0.0.1]:54321
>  [:::127.0.0.1]:54792
> ESTAB  0  0[::1]:54321[::1]:50238
> ESTAB  0  0[::1]:50238[::1]:54321
>
> Below is from a host that runs the hosted-engine at the moment:
> # ss -atn | grep 543
> LISTEN 0  5*:54322*:*
> LISTEN 0  5 [::]:54321 [::]:*
> ESTAB  0  0[::1]:51230[::1]:54321
> ESTAB  0  0[::1]:54321[::1]:51242
> ESTAB  0  0 [:::10.46.20.23]:54321
>  [:::10.46.20.20]:45706
> ESTAB  0  0 [:::10.46.20.23]:54321
>  [:::10.46.20.20]:45746
> ESTAB  0  0[::1]:51240[::1]:54321
> ESTAB  0  0[::1]:54321[::1]:51230
> ESTAB  0  0[::1]:51242[::1]:54321
> ESTAB  0  0[::1]:54321[::1]:51240
>
> The hosted-engine IP is 10.46.20.20 and the host is 10.46.20.23.
>
>
Why do you think the host does not listen to IPv4 anymore?
Can you please share the output of
"nc -vz  10.46.20.23 54321"
executed on engine VM or another host?


> /etc/hosts on all hosts:
> 127.0.0.1  localhost localhost.localdomain localhost4
> localhost4.localdomain4
> ::1localhost localhost.localdomain localhost6
> localhost6.localdomain6
>
> Perhaps this is relevant but all hosts are enrolled into IDM (FreeIPA) and
> as an outcome they all have a DNS record and a PTR record as well as the
> ovirt-engine VM.
>
> # cat /etc/vdsm/vdsm.conf
> [vars]
> ssl = true
> ssl_ciphers = HIGH:!aNULL
> ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1
>
> [addresses]
> management_port = 54321
>
> I have tried adding “management_ip = 0.0.0.0” but then it only binds to
> IPv4 and yet, the host still shows as Unassigned, sometimes it switches to
> “NonResponsive” and trying to “Reinstall” the host fails, the ovirt-engine
> complains it can't contact/reach the VDSM, while using netcat from the
> ovirt-engine it works.
>
> I have KSM and Memory Ballooning enabled on the Cluster as well.
>
> oVirt 4.3.10 installed on CentOS 7.8.2003
> The self-hosted Engine runs on an external GlusterFS, before reinstalling
> everything (fresh start of OS, etc..) I tried iSCSI as well.
>
>
> ___
> 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/NCTWZLS2VPIABOBCDK2JSTDFXT2V3SFQ/
>
___
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/RAAIRUIARXLSJOI57CVSPVJ5XKIIAELI/


[ovirt-users] Re: ovirt-provider-ovn syncrhonisation

2020-06-26 Thread Dominik Holler
On Thu, Jun 25, 2020 at 12:02 PM  wrote:

> Hi - during the last reboot all my ovn networks appeared in oVirt but
> weren't reflected on the physical host, no VMs would boot that had an OVN
> network attached.
>
>
Do you still have the ovn-controller.log from a host of this situation?


> I was looking at my logs and I can see the following -
>
> Failed to synchronize networks of Provider ovirt-provider-ovn.
>
>
Are there any more detailed hints in engine.log or ovirt-provider-ovn.log
why this failed?


> Networks of Provider ovirt-provider-ovn were successfully synchronized.

There was an issue with this host/engine where they lost connection which
> explains the Failed to Sync. The problem is it's since all been rebooted
> and it doesn't look like the ovirt-provider-ovn has tried to sync since, as
> I understand it, it should sync every 5 minutes?
>
> Is it just a case that successful syncs aren't always report in the events
> log?


The event log is rate limited, so the latest reported event about
synchronization reflects the current state.
But engine.log is verbose about the sync.


> I've checked my timing properties for sync of external providers and all
> seems correct. So now I'm worried another reboot will result in losing all
> the ovn networks I've created through oVirt again!
>
>
Let's try to understand what caused the issue.


> Also worth noting AutoSync is turned on for the provider.
> ___
> 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/ZICYAE4JB5LLR3PBPWQNTUPDWEU22FCZ/
>
___
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/VNC5TF5W5H5M7AQ6WSDXLCORQIRFLKVH/


[ovirt-users] Re: status of oVirt 4.4.x and CentOS 8.2

2020-06-19 Thread Dominik Holler
Hello Mark,
can you please share the relevant lines of supervdsm.log from the host?
Helpful to understand the intended change are the lines starting with the
relevant "call setupNetworks",
including the line containing "Desired state"
until some lines below "Unexpected failure of libnm when running the
mainloop"
The most recent line containing "return network_caps with" is helpful to
understand the initial state before the error occurred.
Thanks
Dominik





On Fri, Jun 19, 2020 at 6:16 PM Mark R  wrote:

> The error with a bit more info from the events page, after adding network
> to an interface fails:
>
> VDSM rack4slot11.domain.com command HostSetupNetworksVDS failed: Internal
> JSON-RPC error: {'reason': 'Unexpected failure of libnm when running the
> mainloop: run execution'}
>
> Sorry, should have included that in the other message.
>
> 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/3BHB7KKSSTHCN2AN5ZAIY5MZVFI7IG36/
>
___
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/4OBNBGYGMTN4AFUOJVXAJQUALW3GJ7BB/


[ovirt-users] Re: oVirt-4.4 on CentOS 8.2

2020-06-16 Thread Dominik Holler
On Mon, Jun 15, 2020 at 10:20 PM Dominik Holler  wrote:

> Hello,
> CentOS 8.2 was released before oVirt was prepared for CentOS 8.2 .
> Currently oVirt-4.4 fails to install on CentOS 8.2 .
> This will be fixed soon.
>

An updated version of ovn and ovs is available already on some mirrors.
Please let me know if you have any problems regarding ovs/ovn on CentOS 8.2.


> Dominik
>
___
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/OJANYWGYNIXTXOLE2EKSJ3PNPUV6EG5Z/


[ovirt-users] Re: It looks like big changes are happening, Centos moving from 8.1.1911 to 8.2.2004 perhaps

2020-06-15 Thread Dominik Holler
Yes, this is because of  Centos moving from 8.1.1911 to 8.2.2004

On Mon, Jun 15, 2020 at 10:11 PM Glenn Marcy  wrote:

> I hope this situation settles down before rc5
>
>
This will be fixed quickly.


> trying to run 4.4.1-rc4 hosted engine setup, got
>
> [ ERROR ] fatal: [localhost -> ovirt-engine.example.com]: FAILED! =>
> {"changed": false, "failures": [], "msg": "Depsolve Error occured:
>  Problem: package ovirt-engine-4.4.1.3-1.el8.noarch requires
> ovirt-provider-ovn >= 1.2.1, but none of the providers can be installed
>  - package ovirt-provider-ovn-1.2.30-1.el8.noarch requires openvswitch >=
> 2.7, but none of the providers can be installed
>  - cannot install the best candidate for the job
>  - nothing provides librte_bitratestats.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_bus_pci.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_bus_vdev.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_bus_vmbus.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_cmdline.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_common_cpt.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_eal.so.9()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_eal.so.9(DPDK_17.08)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_eal.so.9(DPDK_18.11)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_eal.so.9(DPDK_2.0)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_ethdev.so.11()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_ethdev.so.11(DPDK_16.07)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_ethdev.so.11(DPDK_17.05)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_ethdev.so.11(DPDK_18.05)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_ethdev.so.11(DPDK_18.08)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_ethdev.so.11(DPDK_18.11)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_ethdev.so.11(DPDK_2.2)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_gro.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_gso.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_hash.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_ip_frag.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_kvargs.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_latencystats.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_mbuf.so.4()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_mbuf.so.4(DPDK_2.1)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_member.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_mempool.so.5()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_mempool.so.5(DPDK_16.07)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_mempool.so.5(DPDK_2.0)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_mempool_bucket.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_mempool_ring.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_mempool_stack.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_meter.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_meter.so.2(DPDK_18.08)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_meter.so.2(DPDK_2.0)(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_metrics.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_net.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_pci.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_pdump.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_pmd_bnxt.so.2()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_pmd_e1000.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_pmd_enic.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_pmd_failsafe.so.1()(64bit) needed by
> openvswitch-2.11.1-5.el8.x86_64
>  - nothing provides librte_pmd_i40e.so.2()(64bit) needed by
> 

[ovirt-users] oVirt-4.4 on CetOS 8.2

2020-06-15 Thread Dominik Holler
Hello,
CentOS 8.2 was released before oVirt was prepared for CentOS 8.2 .
Currently oVirt-4.4 fails to install on CentOS 8.2 .
This will be fixed soon.
Dominik
___
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/IZHXD6ZP4X3UYVWVN6XCMNNJRLWTGORM/


[ovirt-users] Re: oVirt 4.4 install fails

2020-06-02 Thread Dominik Holler
On Thu, May 28, 2020 at 10:02 PM Me  wrote:

> Hi All
>
> Not sure where to start, but here goes.
>
> I'm not totally new to oVirt, I used RHEV V3.x in production for several
> years, it was a breeze to setup.
>
> Installing 4.4 on to a host with local SSD and FC for storage.
>
> Issue 1, having selected the SSD for install which has failed 4.4 beta
> on it (several times), I reclaim the space and after a few minutes of
> not being able to enter a root password on the next install screen, it
> fails as it can't delete the data on the SSD! Yes, really tried this
> several times, choosing the recover option and getting a prompt,
> fdisk /dev/sda delete the two partitions created by oVirt and I can
> install. This was the case with the beta I tried a few weeks ago too.
>
> Having reconfigured the switch attached the the host as a dumb 10GBE
> port as the enterprise OS installer still doesn't appear to support
> anything more advanced like teaming and VLANS, I have the initial
> install on the single SSD and a network connection.
>
>
How did you install the host?
In the graphical installer, you can add a VLAN or a bond by clicking on
"Network & Host Name" in the installation summary and the "+" sign in the
left pane.


> Issue 2, I use FF 72.0.2 on Linux x64 to connect by
> https://hostname:9090 to the web interface, but I can't enter login
> details as the boxes (everything) are disabled There is no warning
> like "we don't like your choice of browser", but the screen is a not
> very accessible dark grey on darker grey (a poor choice in what I
> thought were more enlightened times) so this maybe the case. I have
> disabled all security add-ons in FF, makes no difference.
>
> Any suggestions?
>
> M
>
>
>
>
>
>
>
> ___
> 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/HPMNMKCEFJRSSU57UGLSIJQ5WLYZTPJ7/
>
___
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/SN6FAYI2QEOKOBJQPH7QFX2AK3P6WVSF/


[ovirt-users] Re: oVirt 4.4 and management network requirements

2020-05-26 Thread Dominik Holler
On Tue, May 26, 2020 at 6:20 PM Gianluca Cecchi 
wrote:

> On Tue, May 26, 2020 at 6:02 PM Dominik Holler  wrote:
>
>>
>>> Based on this thread in late 2017
>>>
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/T7RGXRNY24OV2F2PTXIVA6NN636HPLXF/
>>>
>>> where I received an answer that for same cluster is not possible and no
>>> other answers regarding instead its feasibility
>>>
>>>
>> Even it is technically possible to have the same management network in
>> two IP subnetworks,
>> this would create a knot in my head because a logical network represents
>> usually a layer 2 network in oVirt.
>>
>> What is the drawback of having a cluster with its own management network
>> per server farm?
>>
>>
>>> Gianluca
>>>
>>
> Often it happens that you have to work in pre-existing environments where
> network (and not only) rules are already established and restricted and not
> under your control.
> In my case it happened that there were already in place dedicated networks
> for putting mgmt in site 1 and site 2 and that they were different ranges
> and also there wasn't a unique layer2 network transported across both
> sites
>
>
I see. Are multiple management networks for multiple clusters creating any
pain?



> Gianluca
>
___
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/OVLYYZCG4QKJ7VZ7LHK6OZC7OJZYMHKB/


[ovirt-users] Re: oVirt 4.4 and management network requirements

2020-05-26 Thread Dominik Holler
On Tue, May 26, 2020 at 5:03 PM Gianluca Cecchi 
wrote:

>
>
> On Tue, May 26, 2020 at 4:22 PM Dominik Holler  wrote:
>
>>
>>
>> On Tue, May 26, 2020 at 4:18 PM Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> On Tue, May 26, 2020 at 4:14 PM Nir Soffer  wrote:
>>>
>>>> On Tue, May 26, 2020 at 4:37 PM Gianluca Cecchi <
>>>> gianluca.cec...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>> does oVirt 4.4. support management network distributed between routed
>>>>> networks and not bound to a single one?
>>>>> In some environments I see situations where there are 2 different
>>>>> server farms with networks not necessarily mapped to the same ranges and 
>>>>> so
>>>>> it could be useful to let oVirt hosts of the same cluster to be able to
>>>>> communicate but not on the same physical network.
>>>>> Eg vSphere can do it.
>>>>>
>>>>
>>>> Looks like more details are needed, like how such a network looks like.
>>>>
>>>> Dominic should know better about this.
>>>>
>>>>
>>>
>>> Like server farm1 has its historically pre-defined/configured/ecc mgmnt
>>> network on 10.4.167.x, while server farm2 on 10.4.169.x for example.
>>> So hosts in server farm1 would have ip on the first one, while servers
>>> in the server farm2 on the second one.
>>> The two networks are routed.
>>>
>>>
>> Thanks for sharing the scenario.
>> Why might this scenario not work out of the box?
>>
>>
>>> Gianluca
>>>
>>>
> Based on this thread in late 2017
>
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/T7RGXRNY24OV2F2PTXIVA6NN636HPLXF/
>
> where I received an answer that for same cluster is not possible and no
> other answers regarding instead its feasibility
>
>
Even it is technically possible to have the same management network in two
IP subnetworks,
this would create a knot in my head because a logical network represents
usually a layer 2 network in oVirt.

What is the drawback of having a cluster with its own management network
per server farm?


> Gianluca
>
___
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/UZDVIH67RSIA6X2XSBXFFZYCJAFZRVX3/


[ovirt-users] Re: oVirt 4.4 and management network requirements

2020-05-26 Thread Dominik Holler
On Tue, May 26, 2020 at 4:18 PM Gianluca Cecchi 
wrote:

> On Tue, May 26, 2020 at 4:14 PM Nir Soffer  wrote:
>
>> On Tue, May 26, 2020 at 4:37 PM Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> Hello,
>>> does oVirt 4.4. support management network distributed between routed
>>> networks and not bound to a single one?
>>> In some environments I see situations where there are 2 different server
>>> farms with networks not necessarily mapped to the same ranges and so it
>>> could be useful to let oVirt hosts of the same cluster to be able to
>>> communicate but not on the same physical network.
>>> Eg vSphere can do it.
>>>
>>
>> Looks like more details are needed, like how such a network looks like.
>>
>> Dominic should know better about this.
>>
>>
>
> Like server farm1 has its historically pre-defined/configured/ecc mgmnt
> network on 10.4.167.x, while server farm2 on 10.4.169.x for example.
> So hosts in server farm1 would have ip on the first one, while servers in
> the server farm2 on the second one.
> The two networks are routed.
>
>
Thanks for sharing the scenario.
Why might this scenario not work out of the box?


> Gianluca
>
>
___
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/T2OWMWCM4BFTAP5VO55QTV2S24VP23BD/


[ovirt-users] Re: ovirt node 4.4 and infiniband

2020-05-25 Thread Dominik Holler via Users
On Mon, May 25, 2020 at 11:29 AM Giulio Casella  wrote:

> Hi all,
> I have in production a 4.3.9 setup of ovirt, based on a standalone
> engine, not HE.
> I have 3 datacenters (an 3 clusters). One of these clusters is composed
> of many tenth of HP blades, accessing storage via InfiniBand (used as
> normal NICs, via ipoib). They're not the state of the art, but I cannot
> renew the entire hardware.
>
> After a setup of ovirt node 4.4 I cannot see ib0 nic.
>
> I managed to see it installing CentOS 8, enabling Mellanox repo
> (
> https://linux.mellanox.com/public/repo/mlnx_ofed/latest/rhel8.1/mellanox_mlnx_ofed.repo
> )
> and installing package "mlnx-ofed-basic".
>
>
Does installing mlnx-ofed-basic enables a CentOS 8 based oVirt host to use
Infiniband?


> In Ovirt Node it's not possible, that package require dependencies from
> CentOS 8 repos, not present in ovirt repo.
>
> Is there any chances to have infiniband NICs working in ovirt?
>
> TIA,
> gc
> ___
> 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/DSB62G3CWZ5YE7DAMAUE72LMBZ24FNNG/
>
___
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: ${hyperkitty_url}


[ovirt-users] Re: Host "Unassigned Logical Networks" list is wrong

2020-05-19 Thread Dominik Holler
On Tue, May 19, 2020 at 1:25 PM Matthias Leopold <
matthias.leop...@meduniwien.ac.at> wrote:

> Hi,
>
> I'm having a special issue with assigning logical networks to host
> interfaces via label.
> I'm used to assigning logical networks (tagged VLANs, VM network flag) a
> "Network label", which I can choose from a drop down menu in the UI
> dialog. These networks are automatically flagged "assign" and "require"
> in my cluster and I expect them to be synced to hosts physical interface
> to which I "drag and dropped" the label. This always seemed to work and
> I never worried.
>
> Now I noticed that when I look at the host "Setup Host Networks" dialog
> again, that the last(?) logical networks I provisioned as explained
> above show up as "Unassigned Logical Networks" with a mouse over text of
> "Network should be assigned to 'foo' via label 'bar'. However for some
> reason it isn't". This has to be some presentation error, because the
> networks are in fact assigned which is also visible in the hosts
> "Network Interfaces" tab.
>
> The "Sync All Network" buttons in "Host" - "Network Interfaces" and
> "Cluster" - "Logical Networks" tabs are inactive.
> When hosts are put to maintenance and activated again the error disappears.
>
> My oVirt version is 4.3.7.
> Cluster switch type is "Linux Bridge".
>
> This may seem a minor error, but since it affects my production clusters
> and a couple of VLANs I can't afford to play around with host network
> configuration. Can anybody explain this? Any help would be appreciated.
>
>

Does "Refresh Capabilities" resolve the issue?


> thx
> Matthias
>
>
> ___
> 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/75FXB6SP3GSX4NIORCT6OM3HSWP56JPY/
>
___
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/22MSNPB4QRHHIPWMDTRYYGMVV6V7X63H/


[ovirt-users] Re: Bridge not forwarding frames on node.

2020-05-15 Thread Dominik Holler
On Fri, May 15, 2020 at 2:41 PM Stefano Danzi  wrote:

>
>
> Il 15/05/2020 14:29, Dominik Holler ha scritto:
>
>
>
> On Fri, May 15, 2020 at 9:35 AM Stefano Danzi  wrote:
>
>>
>>
>> Il 14/05/2020 20:13, Strahil Nikolov ha scritto:
>> > On May 14, 2020 6:16:06 PM GMT+03:00, Stefano Danzi 
>> wrote:
>> >>
>> >> Il 14/05/2020 12:50, Dominik Holler ha scritto:
>> >>>
>> >>> On Wed, May 13, 2020 at 9:44 PM s.danzi > >>> <mailto:s.da...@hawai.it>> wrote:
>> >>>
>> >>>  Hi to all!
>> >>>
>> >>>  I'm having an issue with networks bridges on ovirt node.
>> >>>
>> >>>  It's look like this bug:
>> >>>  https://bugzilla.redhat.com/show_bug.cgi?id=1279161
>> >>>
>> >>>  On VM I have a bridge between a tap device and network
>> >> interface.
>> >>>  On node side the interface is bridged with bond0 vlan 128
>> >>>  (bond0.128 lacp).
>> >>>
>> >>>  When I ping an host on the other side of tap device I can see
>> >> this:
>> >>>  Arp request goes from my lan to the tap device on vm. Arp reply
>> >>>  return from tap vm and bridge forward this to vm networks
>> >>>  interface. Using tcpdump on vm interface on node I can see the
>> >> arp
>> >>>  reply, using tcpdump on bond0.128 or on bridge I can't see the
>> >> arp
>> >>>  reply.  Arp request is forwarded from bond0.128 to vm net but arp
>> >>>  reply isn't forwarded from vm net to bond0.128.
>> >>>
>> >>>
>> >>>
>> >>> Any chance that there is network filtering involved?
>> >>> Please check if the related vNIC profile has No Network Filter.
>> >>> If there is a Network Filter set, please shutdown the VM, set to No
>> >>> Network Filter in the vNIC profile, and start the VM again and check
>> >>> if the issue is gone.
>> >> Hi! No Network filter It was my first check.
>>
>
> Did you power off the VM after removing the network filter from the vNIC
> profile?
> There is currently no indication of the running vNIC configuration does
> not match the
> desired configuration (BZ1113630).
>
> Yes, of corse
>
>
Thanks, I just wanted to avoid misunderstandings.


> > Have you checked the MTU ?
>> > You need to keep it a little bit lower on the VM, as you have vlan on
>> the hypervisor.
>> >
>> > Best Regards,
>> > Strahil Nikolov
>> Hi! I have to check, but it is strange.
>> Arp replies originated from the VM has not problems, only ARP replies
>> that came from TAP device in VM where not forwarded to real LAN.
>>
>
> Do you have a TAP device inside the VM?
>
>
> Yes! This VM act as L2 VPN server. Inside the VM tap device is bridged
> with vm lan adapter.
>
>
This should work, so let me ask some detailed questions:

Does the issue reproduce, if you are using a single NIC instead of a bond?

Can you please share the output of
bridge fdb show br ovirtmgmt
and
brctl showmacs ovirtmgmt
while replacing ovirtmgmt with the name of your bridge?
What are relevant MAC addresses like bridge/bond, vNIC and tun device in
the output?

What is the output of

ebtables -t filter -L

?

The thread
[ovirt-users] DHCP Client in Guest VM does not work on ovirtmgmt
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/566IC5K2B2JJV77ZQO73KGJNMRJNQ67X/#566IC5K2B2JJV77ZQO73KGJNMRJNQ67X
might be similar.



>
>> Exactly as descived in bz1279161 (that's solved in bz1135347 but it's
>> not public and I can't read it)
>>
>>
> Unfortunately BZ1135347 does not look helpful here.
>
>
>
>
___
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/MBIMK6A4RSVHVR44CUR6FEMEZPZYV6OT/


[ovirt-users] Re: Glance disk images credentials oVirt4.4

2020-05-15 Thread Dominik Holler
On Thu, May 14, 2020 at 8:33 PM  wrote:

> So if I use this to build a VM  and I setup Cloud_init to set user id and
> passwords.
> should I not be able to login to the VM from Console?
>
>
Yes, as long as the guest processes the information provided via cloud-init.
CentOS 7, CentOS 8 and Fedora cloud images will work for sure.


>
> Bryan
> ___
> 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/K3CA6ABS5SD2TBI7FBPMKCGDUUNMHMLT/
>
___
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/F6LUDRYQGMI4Q25FXVS2UZTZPMJ7JDO7/


[ovirt-users] Re: Bridge not forwarding frames on node.

2020-05-15 Thread Dominik Holler
On Fri, May 15, 2020 at 9:35 AM Stefano Danzi  wrote:

>
>
> Il 14/05/2020 20:13, Strahil Nikolov ha scritto:
> > On May 14, 2020 6:16:06 PM GMT+03:00, Stefano Danzi 
> wrote:
> >>
> >> Il 14/05/2020 12:50, Dominik Holler ha scritto:
> >>>
> >>> On Wed, May 13, 2020 at 9:44 PM s.danzi  >>> <mailto:s.da...@hawai.it>> wrote:
> >>>
> >>>  Hi to all!
> >>>
> >>>  I'm having an issue with networks bridges on ovirt node.
> >>>
> >>>  It's look like this bug:
> >>>  https://bugzilla.redhat.com/show_bug.cgi?id=1279161
> >>>
> >>>  On VM I have a bridge between a tap device and network
> >> interface.
> >>>  On node side the interface is bridged with bond0 vlan 128
> >>>  (bond0.128 lacp).
> >>>
> >>>  When I ping an host on the other side of tap device I can see
> >> this:
> >>>  Arp request goes from my lan to the tap device on vm. Arp reply
> >>>  return from tap vm and bridge forward this to vm networks
> >>>  interface. Using tcpdump on vm interface on node I can see the
> >> arp
> >>>  reply, using tcpdump on bond0.128 or on bridge I can't see the
> >> arp
> >>>  reply.  Arp request is forwarded from bond0.128 to vm net but arp
> >>>  reply isn't forwarded from vm net to bond0.128.
> >>>
> >>>
> >>>
> >>> Any chance that there is network filtering involved?
> >>> Please check if the related vNIC profile has No Network Filter.
> >>> If there is a Network Filter set, please shutdown the VM, set to No
> >>> Network Filter in the vNIC profile, and start the VM again and check
> >>> if the issue is gone.
> >> Hi! No Network filter It was my first check.
>

Did you power off the VM after removing the network filter from the vNIC
profile?
There is currently no indication of the running vNIC configuration does not
match the
desired configuration (BZ1113630).


> > Have you checked the MTU ?
> > You need to keep it a little bit lower on the VM, as you have vlan on
> the hypervisor.
> >
> > Best Regards,
> > Strahil Nikolov
> Hi! I have to check, but it is strange.
> Arp replies originated from the VM has not problems, only ARP replies
> that came from TAP device in VM where not forwarded to real LAN.
>

Do you have a TAP device inside the VM?


> Exactly as descived in bz1279161 (that's solved in bz1135347 but it's
> not public and I can't read it)
>
>
Unfortunately BZ1135347 does not look helpful here.
___
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/MYPWA6MEKO4UQ3CTFQLR3SM6IPF2ZIHE/


[ovirt-users] Re: Bridge not forwarding frames on node.

2020-05-14 Thread Dominik Holler
On Wed, May 13, 2020 at 9:44 PM s.danzi  wrote:

> Hi to all!
>
> I'm having an issue with networks bridges on ovirt node.
>
> It's look like this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1279161
>
> On VM I have a bridge between a tap device and network interface.  On node
> side the interface is bridged with bond0 vlan 128 (bond0.128 lacp).
>
> When I ping an host on the other side of tap device I can see this:
>
> Arp request goes from my lan to the tap device on vm. Arp reply return
> from tap vm and bridge forward this to vm networks interface. Using tcpdump
> on vm interface on node I can see the arp reply, using tcpdump on bond0.128
> or on bridge I can't see the arp reply.  Arp request is forwarded from
> bond0.128 to vm net but arp reply isn't forwarded from vm net to bond0.128.
>
>

Any chance that there is network filtering involved?
Please check if the related vNIC profile has No Network Filter.
If there is a Network Filter set, please shutdown the VM, set to No Network
Filter in the vNIC profile, and start the VM again and check if the issue
is gone.



> Very strange.
>
> ___
> 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/6ONQZEHXKW6NLYP2OVVCUINCJ5IN5RHZ/
>
___
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/WPSV4SMHR4N5S7XBUTOPHUVOAUJ3PJZ5/


[ovirt-users] Re: Can't add freshly installed node.. host has no default route

2020-05-12 Thread Dominik Holler
On Tue, May 12, 2020 at 4:25 PM Giorgio Biacchi  wrote:

> On 5/12/20 12:28 PM, Dominik Holler wrote:
> >
> >
> > On Tue, May 12, 2020 at 8:49 AM Giorgio Biacchi  > <mailto:gior...@di.unimi.it>> wrote:
> >
> > On 5/11/20 5:53 PM, Dominik Holler wrote:
> > >
> > >
> > > On Mon, May 11, 2020 at 12:31 PM Giorgio Biacchi
> > mailto:gior...@di.unimi.it>
> > > <mailto:gior...@di.unimi.it <mailto:gior...@di.unimi.it>>> wrote:
> > >
> > > Hi list,
> > > I've spent a couple of days trying to understand why this was
> > > happening...
> > >
> > > For the installation I have a well tested installation server
> > with a
> > > custom kickstart file to setup ssh keys and custom hooks for
> > infiniband
> > > and I'm installing Ovirt Node 4.3.9 via pxe, this is
> particularly
> > > useful
> > > when I have to install a bunch of blades at once.. In the past
> > I had no
> > > issues and all was working like a charm until now when some
> > hardware
> > > failed and I had to replace it.
> > >
> > > As expected I have no issues in the node installation
> > process.. the
> > > troubles begins when I try to add the node, installation fails
> > and in
> > > the UI I have an exclamation mark with the message "Host has
> > no default
> > > route." but I can ping and do ssh to the host from the
> > manager.. the
> > > problem is somewhere else in the communication between the
> > engine and
> > > vdsmd preventing the engine to refresh the host capabilities.
> > >
> > > So from the engine I tried:
> > >
> > > [root@manager ~]# openssl s_client -connect 172.20.22.78:54321
> > <http://172.20.22.78:54321>
> > > <http://172.20.22.78:54321>
> > > CONNECTED(0003)
> > > ---
> > > Certificate chain
> > >   0 s:/CN=cn128.lagrange.di.unimi.it/O=VDSM
> > <http://cn128.lagrange.di.unimi.it/O=VDSM>
> > > <http://cn128.lagrange.di.unimi.it/O=VDSM> Certificate
> > > i:/CN=VDSM Certificate Authority
> > >   1 s:/CN=VDSM Certificate Authority
> > > i:/CN=VDSM Certificate Authority
> > > ---
> > >
> > > The host has still the self signed vdsm certificate.. and on
> the
> > > host in
> > > vdsm.log I find:
> > >
> > > 2020-05-11 09:52:25,433+ ERROR (Reactor thread)
> > > [ProtocolDetector.SSLHandshakeDispatcher] ssl handshake:
> SSLError,
> > > address: :::159.149.129.220 (sslutils:264)
> > >
> > > So I tried to enroll the certificate from the UI and from the
> > events
> > > tab
> > > I sow the enrolling was successful but:
> > >
> > > [root@manager ~]# openssl s_client -connect 172.20.22.78:54321
> > <http://172.20.22.78:54321>
> > > <http://172.20.22.78:54321>
> > >
> > > 140084336994192:error:140790E5:SSL routines:ssl23_write:ssl
> > handshake
> > > failure:s23_lib.c:177:
> > > CONNECTED(0003)
> > > ---
> > > no peer certificate available
> > > ---
> > >
> > > there's still some issue with the certificates.. so on the
> > host again:
> > >
> > > [root@cn128 vdsm]# find /etc/pki/vdsm/ -type f -cmin -10|
> > xargs ls -l
> > > -rw---. 1 root kvm  1424 May 11 09:56
> > /etc/pki/vdsm/certs/cacert.pem
> > > -rw---. 1 root kvm  5108 May 11 09:57
> > > /etc/pki/vdsm/certs/vdsmcert.pem
> > > -r--r-. 1 root kvm  1704 May 11 09:56
> > /etc/pki/vdsm/keys/vdsmkey.pem
> > > -rw-r--r--. 1 root root 1424 May 11 09:57
> > > /etc/pki/vdsm/libvirt-spice/ca-cert.pem
> > > -rw-r--r--. 1 root root 5108 May 11 09:57
> > > /etc/pki/vdsm/libvirt-spice/server-cert.pem
> > > -r--r-. 1 root root 1704 May 11 09:56
> > > /etc/pki/vdsm/libvirt-spice/server-key.pem
>

[ovirt-users] Re: Can't add freshly installed node.. host has no default route

2020-05-12 Thread Dominik Holler
On Tue, May 12, 2020 at 8:49 AM Giorgio Biacchi  wrote:

> On 5/11/20 5:53 PM, Dominik Holler wrote:
> >
> >
> > On Mon, May 11, 2020 at 12:31 PM Giorgio Biacchi  > <mailto:gior...@di.unimi.it>> wrote:
> >
> > Hi list,
> > I've spent a couple of days trying to understand why this was
> > happening...
> >
> > For the installation I have a well tested installation server with a
> > custom kickstart file to setup ssh keys and custom hooks for
> infiniband
> > and I'm installing Ovirt Node 4.3.9 via pxe, this is particularly
> > useful
> > when I have to install a bunch of blades at once.. In the past I had
> no
> > issues and all was working like a charm until now when some hardware
> > failed and I had to replace it.
> >
> > As expected I have no issues in the node installation process.. the
> > troubles begins when I try to add the node, installation fails and in
> > the UI I have an exclamation mark with the message "Host has no
> default
> > route." but I can ping and do ssh to the host from the manager.. the
> > problem is somewhere else in the communication between the engine and
> > vdsmd preventing the engine to refresh the host capabilities.
> >
> > So from the engine I tried:
> >
> > [root@manager ~]# openssl s_client -connect 172.20.22.78:54321
> > <http://172.20.22.78:54321>
> > CONNECTED(0003)
> > ---
> > Certificate chain
> >   0 s:/CN=cn128.lagrange.di.unimi.it/O=VDSM
> > <http://cn128.lagrange.di.unimi.it/O=VDSM> Certificate
> > i:/CN=VDSM Certificate Authority
> >   1 s:/CN=VDSM Certificate Authority
> > i:/CN=VDSM Certificate Authority
> > ---
> >
> > The host has still the self signed vdsm certificate.. and on the
> > host in
> > vdsm.log I find:
> >
> > 2020-05-11 09:52:25,433+ ERROR (Reactor thread)
> > [ProtocolDetector.SSLHandshakeDispatcher] ssl handshake: SSLError,
> > address: :::159.149.129.220 (sslutils:264)
> >
> > So I tried to enroll the certificate from the UI and from the events
> > tab
> > I sow the enrolling was successful but:
> >
> > [root@manager ~]# openssl s_client -connect 172.20.22.78:54321
> > <http://172.20.22.78:54321>
> >
> > 140084336994192:error:140790E5:SSL routines:ssl23_write:ssl handshake
> > failure:s23_lib.c:177:
> > CONNECTED(0003)
> > ---
> > no peer certificate available
> > ---
> >
> > there's still some issue with the certificates.. so on the host
> again:
> >
> > [root@cn128 vdsm]# find /etc/pki/vdsm/ -type f -cmin -10| xargs ls
> -l
> > -rw---. 1 root kvm  1424 May 11 09:56
> /etc/pki/vdsm/certs/cacert.pem
> > -rw---. 1 root kvm  5108 May 11 09:57
> > /etc/pki/vdsm/certs/vdsmcert.pem
> > -r--r-. 1 root kvm  1704 May 11 09:56
> /etc/pki/vdsm/keys/vdsmkey.pem
> > -rw-r--r--. 1 root root 1424 May 11 09:57
> > /etc/pki/vdsm/libvirt-spice/ca-cert.pem
> > -rw-r--r--. 1 root root 5108 May 11 09:57
> > /etc/pki/vdsm/libvirt-spice/server-cert.pem
> > -r--r-. 1 root root 1704 May 11 09:56
> > /etc/pki/vdsm/libvirt-spice/server-key.pem
> >
> > It seems that cacert.pem and vdsmcert.pem have wrong permissions..
> > let's
> > try to fix it..
> >
> > [root@cn128 vdsm]# chown 36:36 /etc/pki/vdsm/certs/cacert.pem
> > /etc/pki/vdsm/certs/vdsmcert.pem
> >
> > And now:
> >
> > [root@manager ~]# openssl s_client -connect 172.20.22.78:54321| less
> > CONNECTED(0003)
> > ---
> > Certificate chain
> >   0 s:/O=lagrange.di.unimi.it/CN=172.20.22.78
> > <http://lagrange.di.unimi.it/CN=172.20.22.78>
> >
> > i:/C=US/O=lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941
> > <http://lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941>
> >   1
> > s:/C=US/O=lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941
> > <http://lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941>
> >
> > i:/C=US/O=lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941
> > <http://lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941>
> > ---
> >
> > Now I can finally refresh the host capabilities and setup the host
> > networks..
&

[ovirt-users] Re: Can't add freshly installed node.. host has no default route

2020-05-11 Thread Dominik Holler
On Mon, May 11, 2020 at 12:31 PM Giorgio Biacchi 
wrote:

> Hi list,
> I've spent a couple of days trying to understand why this was happening...
>
> For the installation I have a well tested installation server with a
> custom kickstart file to setup ssh keys and custom hooks for infiniband
> and I'm installing Ovirt Node 4.3.9 via pxe, this is particularly useful
> when I have to install a bunch of blades at once.. In the past I had no
> issues and all was working like a charm until now when some hardware
> failed and I had to replace it.
>
> As expected I have no issues in the node installation process.. the
> troubles begins when I try to add the node, installation fails and in
> the UI I have an exclamation mark with the message "Host has no default
> route." but I can ping and do ssh to the host from the manager.. the
> problem is somewhere else in the communication between the engine and
> vdsmd preventing the engine to refresh the host capabilities.
>
> So from the engine I tried:
>
> [root@manager ~]# openssl s_client -connect 172.20.22.78:54321
> CONNECTED(0003)
> ---
> Certificate chain
>   0 s:/CN=cn128.lagrange.di.unimi.it/O=VDSM Certificate
> i:/CN=VDSM Certificate Authority
>   1 s:/CN=VDSM Certificate Authority
> i:/CN=VDSM Certificate Authority
> ---
>
> The host has still the self signed vdsm certificate.. and on the host in
> vdsm.log I find:
>
> 2020-05-11 09:52:25,433+ ERROR (Reactor thread)
> [ProtocolDetector.SSLHandshakeDispatcher] ssl handshake: SSLError,
> address: :::159.149.129.220 (sslutils:264)
>
> So I tried to enroll the certificate from the UI and from the events tab
> I sow the enrolling was successful but:
>
> [root@manager ~]# openssl s_client -connect 172.20.22.78:54321
>
> 140084336994192:error:140790E5:SSL routines:ssl23_write:ssl handshake
> failure:s23_lib.c:177:
> CONNECTED(0003)
> ---
> no peer certificate available
> ---
>
> there's still some issue with the certificates.. so on the host again:
>
> [root@cn128 vdsm]# find /etc/pki/vdsm/ -type f -cmin -10| xargs ls -l
> -rw---. 1 root kvm  1424 May 11 09:56 /etc/pki/vdsm/certs/cacert.pem
> -rw---. 1 root kvm  5108 May 11 09:57 /etc/pki/vdsm/certs/vdsmcert.pem
> -r--r-. 1 root kvm  1704 May 11 09:56 /etc/pki/vdsm/keys/vdsmkey.pem
> -rw-r--r--. 1 root root 1424 May 11 09:57
> /etc/pki/vdsm/libvirt-spice/ca-cert.pem
> -rw-r--r--. 1 root root 5108 May 11 09:57
> /etc/pki/vdsm/libvirt-spice/server-cert.pem
> -r--r-. 1 root root 1704 May 11 09:56
> /etc/pki/vdsm/libvirt-spice/server-key.pem
>
> It seems that cacert.pem and vdsmcert.pem have wrong permissions.. let's
> try to fix it..
>
> [root@cn128 vdsm]# chown 36:36 /etc/pki/vdsm/certs/cacert.pem
> /etc/pki/vdsm/certs/vdsmcert.pem
>
> And now:
>
> [root@manager ~]# openssl s_client -connect 172.20.22.78:54321| less
> CONNECTED(0003)
> ---
> Certificate chain
>   0 s:/O=lagrange.di.unimi.it/CN=172.20.22.78
> i:/C=US/O=lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941
>   1 s:/C=US/O=lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941
> i:/C=US/O=lagrange.di.unimi.it/CN=cn305.lagrange.di.unimi.it.35941
> ---
>
> Now I can finally refresh the host capabilities and setup the host
> networks..
>
> In attachment all the relevant logs, I don't know if I've found some
> bug.. this is the first time i had so many troubles adding a new host..
> so I decided to share my experience with the list..
>
>
Thanks for raising this.

On adding the host there is an error about  vdsm-hook-nestedvt which I
cannot interprete, maybe someone else can do.
In vdsm.log I noticed a strange behavior of setupNetworks, can you please
share the corresponding supervdsm.log, too?



> Cheers
> --
> gb
>
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34
> ___
> 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/6JTU3HB4WCI27WSLGEOSLMPYFU22EX5H/
>
___
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/LK47PGCYENSDO6LV7VRFPRO6UJEH2ASH/


[ovirt-users] Re: centos 8 stream status

2020-05-08 Thread Dominik Holler
On Wed, May 6, 2020 at 9:50 AM Nathanaël Blanchet  wrote:

> Hello,
>
> Centos 8 stream should be the preview of centos 8, so why not using
> right now it instead of waiting GA 8.2?
>
>

Currently there is
https://bugzilla.redhat.com/1832725



> --
> Nathanaël Blanchet
>
> Supervision réseau
> SIRE
> 227 avenue Professeur-Jean-Louis-Viala
> 34193 MONTPELLIER CEDEX 5
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14
> blanc...@abes.fr
> ___
> 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/WFGADEFI7FIUTHQUO4XN6HCG5U3HYBMP/
>
___
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/ZSHUQUXSVDFE3GGOFSP3NYLY4DC6EM37/


[ovirt-users] Re: Add custom Network Filter to oVirt

2020-04-30 Thread Dominik Holler
On Thu, Apr 30, 2020 at 8:43 AM Hendrik Peyerl  wrote:

> Thank you Dominik, are there any plans to add such a feature in the future?
>
>
No.
What could oVirt do, to make this flow more comfortable?


> Thanks,
> Hendrik
>
> > On 29. Apr 2020, at 21:25, Dominik Holler  wrote:
> >
> >
> >
> > On Wed, Apr 29, 2020 at 6:40 PM Sandro Bonazzola 
> wrote:
> >
> >
> > Il giorno mer 29 apr 2020 alle ore 15:35 Hendrik Peyerl <
> hpey...@plusline.net> ha scritto:
> > Hello all,
> >
> > can anyone give me a hint on where to find documentation on how to add
> custom created network filters through oVirt?
> >
> > +Dominik Holler have you any link at hand for this?
> >
> >
> > Custom network filters are not supported and documented, but should work.
> > Probably you are already aware of
> > https://libvirt.org/formatnwfilter.html
> > which describes how to add a network filter for libvirt on a single host.
> >
> > oVirt does not help to distribute the custom network filters for libvirt
> to the hosts,
> > it is up to the user to ensure that the custom network filter is
> available to libvirt on all oVirt hosts.
> >
> > To enable oVirt to use a custom network filter of libvirt, its name has
> to be added to oVirt's database to the table
> > network_filter
> > manually.
> >
> >
> >
> >
> > Thanks,
> >
> > Hendrik
> > ___
> > 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/O57QAOTVOLKXNYZBTEVQNIZ75EDVMZRV/
> >
> >
> > --
> > Sandro Bonazzola
> > MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
> > Red Hat EMEA
> > sbona...@redhat.com
> >
> >
> 
> > Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
>
>
___
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/VSF3LZVN6MHHEQXZMCKVLWLM4RFBL5AQ/


[ovirt-users] Re: Add custom Network Filter to oVirt

2020-04-29 Thread Dominik Holler
On Wed, Apr 29, 2020 at 6:40 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno mer 29 apr 2020 alle ore 15:35 Hendrik Peyerl <
> hpey...@plusline.net> ha scritto:
>
>> Hello all,
>>
>> can anyone give me a hint on where to find documentation on how to add
>> custom created network filters through oVirt?
>
>
> +Dominik Holler  have you any link at hand for this?
>
>

Custom network filters are not supported and documented, but should work.
Probably you are already aware of
https://libvirt.org/formatnwfilter.html
which describes how to add a network filter for libvirt on a single host.

oVirt does not help to distribute the custom network filters for libvirt to
the hosts,
it is up to the user to ensure that the custom network filter is available
to libvirt on all oVirt hosts.

To enable oVirt to use a custom network filter of libvirt, its name has to
be added to oVirt's database to the table
network_filter
manually.



>
>>
>> Thanks,
>>
>> Hendrik
>> ___
>> 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/O57QAOTVOLKXNYZBTEVQNIZ75EDVMZRV/
>>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://www.redhat.com/>*
> <https://www.redhat.com/en/summit?sc_cid=7013a02D2QxAAK>*
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> <https://mojo.redhat.com/docs/DOC-1199578>*
>
___
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/OCNRLUUSYSZULRYXCUMGDTAFT6Y7ITCI/


[ovirt-users] Re: oVirt 4.4.0 Beta release refresh is now available for testing

2020-04-07 Thread Dominik Holler
On Mon, Apr 6, 2020 at 9:48 AM Sandro Bonazzola  wrote:

>
>
> Il giorno dom 5 apr 2020 alle ore 19:32 Strahil Nikolov <
> hunter86...@yahoo.com> ha scritto:
>
>>
>> Hey Sandro,
>>
>> Can you clarify which CPUs will not be supported  in 4.4 ?
>>
>
> I can give the list of supported CPU according to ovirt-engine code:
>
> select fn_db_add_config_value('ServerCPUList',
> '1:Intel Nehalem Family:vmx,nx,model_Nehalem:Nehalem:x86_64; '
> || '2:Secure Intel Nehalem
> Family:vmx,spec_ctrl,ssbd,md_clear,model_Nehalem:Nehalem,+spec-ctrl,+ssbd,+md-clear:x86_64;
> '
> || '3:Intel Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64; '
> || '4:Secure Intel Westmere
> Family:aes,vmx,spec_ctrl,ssbd,md_clear,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64;
> '
> || '5:Intel SandyBridge
> Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64; '
> || '6:Secure Intel SandyBridge
> Family:vmx,spec_ctrl,ssbd,md_clear,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64;
> '
> || '7:Intel IvyBridge Family:vmx,nx,model_IvyBridge:IvyBridge:x86_64; '
> || '8:Secure Intel IvyBridge
> Family:vmx,spec_ctrl,ssbd,md_clear,model_IvyBridge:IvyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64;
> '
> || '9:Intel Haswell Family:vmx,nx,model_Haswell:Haswell:x86_64; '
> || '10:Secure Intel Haswell
> Family:vmx,spec_ctrl,ssbd,md_clear,model_Haswell:Haswell,+spec-ctrl,+ssbd,+md-clear:x86_64;
> '
> || '11:Intel Broadwell Family:vmx,nx,model_Broadwell:Broadwell:x86_64; '
> || '12:Secure Intel Broadwell
> Family:vmx,spec_ctrl,ssbd,md_clear,model_Broadwell:Broadwell,+spec-ctrl,+ssbd,+md-clear:x86_64;
> '
> || '13:Intel Skylake Client
> Family:vmx,nx,model_Skylake-Client:Skylake-Client:x86_64; '
> || '14:Secure Intel Skylake Client
> Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd,+md-clear:x86_64;
> '
> || '15:Intel Skylake Server
> Family:vmx,nx,model_Skylake-Server:Skylake-Server:x86_64; '
> || '16:Secure Intel Skylake Server
> Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd,+md-clear:x86_64;
> '
> || '17:Intel Cascadelake Server
> Family:vmx,model_Cascadelake-Server:Cascadelake-Server,-hle,-rtm,+arch-capabilities:x86_64;
> '
> || '18:Secure Intel Cascadelake Server
> Family:vmx,md-clear,mds-no,model_Cascadelake-Server:Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities:x86_64;
> '
> || '1:AMD Opteron G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64; '
> || '2:AMD Opteron G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64; '
> || '3:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; '
> || '4:Secure AMD
> EPYC:svm,nx,ibpb,ssbd,model_EPYC:EPYC,+ibpb,+virt-ssbd:x86_64; '
> || '1:IBM POWER8:powernv,model_POWER8:POWER8:ppc64; '
> || '2:IBM POWER9:powernv,model_POWER9:POWER9:ppc64; '
> || '1:IBM z114, z196:sie,model_z196-base:z196-base:s390x; '
> || '2:IBM zBC12, zEC12:sie,model_zEC12-base:zEC12-base:s390x; '
> || '3:IBM z13s, z13:sie,model_z13-base:z13-base:s390x; '
> || '4:IBM z14:sie,model_z14-base:z14-base:s390x;',
> '4.4');
>
>
>
>> Also, does oVirt 4.4 support teaming or it is still staying with bonding.
>> Network Manager was mentioned, but it's not very clear.
>>
>
> +Dominik Holler  can you please reply to this?
>
>

oVirt stays with bonding.
Reasons why oVirt should support teaming are gathered in
*Bug 1351510* <https://bugzilla.redhat.com/show_bug.cgi?id=1351510> - [RFE]
Support using Team devices instead of bond devices
https://bugzilla.redhat.com/show_bug.cgi?id=1351510



> What is the version of gluster bundled  with 4.4 ?
>>
>
> Latest Gluster 7 shipped by CentOS Storage SIG, right now it is 7.4 (
> https://docs.gluster.org/en/latest/release-notes/7.4/)
>
>
>
>>
>> Best Regards,
>> Strahil Nikolov
>>
>>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://www.redhat.com/>*
> <https://www.redhat.com/en/summit?sc_cid=7013a02D2QxAAK>*
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> <https://mojo.redhat.com/docs/DOC-1199578>*
>
___
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/QPOMSOKTZSWZDWMZ4ZXBL3653YIGSHJ5/


[ovirt-users] Re: Local network

2020-03-31 Thread Dominik Holler
Port security requires subnets.
Can you please ensure that you used an external network with port security
explicitly disabled?
In doubt, please create a new external network with port security
explicitly disabled and try again with the new network?

On Tue, Mar 31, 2020 at 2:16 PM Tommaso - Shellrent 
wrote:

> This is what i've got:
>
>
>
> *ovs-vsctl show*
> 03a038d4-e81c-45e0-94d1-6f18d6504f1f
> Bridge br-int
> fail_mode: secure
> Port "ovn-765f43-0"
> Interface "ovn-765f43-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="xxx.169.yy.6"}
> Port br-int
> Interface br-int
> type: internal
> Port "vnet1"
> Interface "vnet1"
> Port "ovn-b33f6e-0"
> Interface "ovn-b33f6e-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="xxx.169.yy.2"}
> Port "vnet3"
> Interface "vnet3"
> Port "ovn-8678d9-0"
> Interface "ovn-8678d9-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="xxx.169.yy.8"}
> Port "ovn-fdd090-0"
> Interface "ovn-fdd090-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="xxx.169.yy.4"}
> ovs_version: "2.11.0"
>
>
> I suppose that the vnic are:
> Port "vnet1"
> Interface "vnet1"
> Port "vnet3"
> Interface "vnet3"
>
>
>
>
> on the engine:
> *ovn-nbctl show*
> switch a1f30e99-3ab7-46a4-925d-287871905cab
> (ovirt-local_network_definitiva-d58aea97-bb20-4e8f-bcc3-5277754846bb)
> port b82f3479-b459-4c26-aff0-053d15c74ddd
> addresses: ["56:6f:96:b1:00:4c"]
> port 52f09a28-1645-45ff-9b84-1e53a81bb399
> addresses: ["56:6f:96:b1:00:4b"]
>
>
> *ovn-sbctl show*
>
> Chassis "ab5bdfdd-8df4-4e9b-9ce9-565cfd513a4d"
> hostname: "pvt-41f18-002.serverlet.com"
> Encap geneve
> ip: "aaa.31.bbb.224"
> options: {csum="true"}
> Port_Binding "b82f3479-b459-4c26-aff0-053d15c74ddd"
> Port_Binding "52f09a28-1645-45ff-9b84-1e53a81bb399"
>
>
> Il 31/03/20 13:39, Staniforth, Paul ha scritto:
>
> The engine runs the controller so ovn-sbctl won't work, on the hosts, use
> ovs-vsctl show
>
> Paul S.
> --
> *From:* Tommaso - Shellrent 
> 
> *Sent:* 31 March 2020 12:13
> *To:* Staniforth, Paul 
> ; users@ovirt.org 
> 
> *Subject:* Re: [ovirt-users] Local network
>
>
> *Caution External Mail:* Do not click any links or open any attachments
> unless you trust the sender and know that the content is safe.
>
> Hi.
>
>  on engine all seems fine.
>
> on host the command "ovn-sbctl show" is stuck, and with a strace a se the
> following error:
>
>
> connect(5, {sa_family=AF_LOCAL,
> sun_path="/var/run/openvswitch/ovnsb_db.sock"}, 37) = -1 ENOENT (No such
> file or directory)
>
>
>
>
>
>
> Il 31/03/20 11:18, Staniforth, Paul ha scritto:
>
>
> .Hello Tommaso,
>on your oVirt engine host run
> check the north bridge controller
> ovn-nbctl show
> this should show a software switch for each ovn logical network witch any
> ports that are active( in your case you should have 2)
>
> check the south bridge controller
> ovn-sbctl show
> this should show the software switch on each host with a geneve tunnel.
>
> on each host run
> ovs-vsctl show
> this should show the virtual switch with a geneve tunnel to each other
> host and a port for any active vnics
>
> Regards,
> Paul S.
>
> --
> *From:* Tommaso - Shellrent 
> 
> *Sent:* 31 March 2020 09:27
> *To:* users@ovirt.org  
> *Subject:* [ovirt-users] Local network
>
>
> *Caution External Mail:* Do not click any links or open any attachments
> unless you trust the sender and know that the content is safe.
>
> Hi to all.
>
>I'm trying to connect two vm, on the same "local storage" host, with an
> internal isolated network.
>
> My setup;
>
> VM A:
>
>- eth0 with an external ip
>- eth1, with 1922.168.1.1/24
>
> VM B
>
>- eth0 with an external ip
>- eth1, with 1922.168.1.2/24
>
> the eth1 interfaces are connetter by a network created on external
> provider ovirt-network-ovn , whithout a subnet defined.
>
> Now, the external ip works fine, but the two vm cannot connect through the
> local network
>
> ping: ko
> arping: ko
>
>
> any idea to what to check?
>
>
> Regards
> --
> --
> [image: Shellrent - Il primo hosting italiano Security First]
> *Tommaso De Marchi*
> *COO - Chief Operating Officer*
> Shellrent Srl
> Via dell'Edilizia, 19 - 36100 Vicenza
> Tel. 0444321155 <+390444321155> | Fax 04441492177
> To view the terms under which this email is distributed, please go to:-
> http://leedsbeckett.ac.uk/disclaimer/email/
>
> --
> --
> [image: Shellrent - Il primo hosting italiano Security First]
> *Tommaso De Marchi*
> *COO - Chief Operating Officer*
> Shellrent Srl
> Via 

[ovirt-users] Re: Several virtual machines all with the same MAC address ?

2020-03-17 Thread Dominik Holler
On Tue, Mar 17, 2020 at 2:49 PM Li Xo  wrote:

> Hello,
> I need to replicate some file servers that must have the same MAC address
> to work properly and which will be placed on different VLANs to avoid MAC
> conflicts.
> With VMware and VirtualBox this is quite simple and works without
> particular problems but it seems that oVirt does not allow it or I did not
> find how to proceed.
> So 2 questions:
> - does it is possible ?
>

Yes.


> - what must be done to allow oVirt to handle it ?
>


You can enable this using *"Allow Duplicates" *as described in
https://www.ovirt.org/documentation/admin-guide/chap-Global_Configuration.html#mac-address-pools



> Thanks,
> Li
> ___
> 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/7TPNQLDVM3ERSAZAK77V6RJ5P3KH55O2/
>
___
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/CX32JZ7FD4OBNCKQWQK6Z4R2JEHDNJVU/


[ovirt-users] Re: What should I do to support DPDK in ovirt, any instruction?

2020-03-17 Thread Dominik Holler
On Mon, Mar 16, 2020 at 2:15 PM lifuqi...@sunyainfo.com <
lifuqi...@sunyainfo.com> wrote:

>
> Hi All,
> I found that there is rarely topics about supporting dpdk in ovirt 4.2
>
>

What is your motivation to have a look at dpdk?


> in Internet except
> https://blogs.ovirt.org/2018/07/upgraded-dpdk-support-in-ovirt/; and I
> can't get information such as  whether or not should I install dpdk or ovn
> manual? And I will get an error when I execute such cmds:
> ansible-playbook ovirt.dpdk-setup/tasks/main.yml
> ansible-playbook oVirt.dpdk-setup
>
>
> I have some experience about ovn and dpdk, but I can't make ovirt
> supporting dpdk according the instruction in
> https://blogs.ovirt.org/2018/07/upgraded-dpdk-support-in-ovirt/;
>
>
In the meantime, an additional step is required:
dpdk has to be enabled manually in the vdsm.conf on the host:
https://github.com/oVirt/vdsm/commit/ce1231d128f19b47c4b8c04bdb19f9d6f1268570


> Is there anybody helping me?  Thank you.
>
> Mark
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/VVRC6NMM373JZZCYPQLQTOZXEK5NDZ24/
>
___
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/UA6GEWDQ63BIXA5ZOU75KRMCULB3QIF4/


[ovirt-users] Re: The problem with create VM

2020-03-05 Thread Dominik Holler
On Fri, Mar 6, 2020 at 1:35 AM Nir Soffer  wrote:

> On Thu, Mar 5, 2020 at 1:16 PM  wrote:
> >
> > I began use ovirt recently. I tried create one VM on ovirt plateform.
> But I nerver start VM. I had the message like:
> >
> > L'hôte x..fr n'a pas pu satisfaire le filtre Network de type
> interne car réseau d'affichage ${DisplayNames} manquant.
>
> Google translated this to:
> The host x..fr could not satisfy the Network filter of
> internal type because display network $ {DisplayNames} missing.
>
> There are two issues:
> - The missing display network - maybe Dominic can help
>


Can you check in
Compute > Clusters > relevant_cluster > Logical Networks > Manage Networks
if the role "Display Network" is assigned to another networks than
ovirtmgmt?
If so, you might want to mark this network as "Require" and ensure that
this network is attached to all hosts in the cluster.

In case you want to do first steps with oVirt, I recommend all roles in the
"Manage Networks" to be assigned to ovirtmgmt.


> - Placeholder "${DisplayNames}" in the message. This is probably a
> missing translation or bug in the translation code
>   please file ovirt-engine bug for this
>
>
Indeed, looks like a typo in the french translation.
A bug created by
https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine
for the component FrontEnd.Webadmin would be helpful.


> Nir
>
> >
> > I don't understand where is the problem.
> >
> > Could you help me?
> >
> > Thanks
> >
> > Anne
> > ___
> > 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/RB66ESCX7EN7PQI2TIMJ6FAWVEYYK5G6/
>
>
___
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/N4YILPS77NLLJWFGCCPTLALDF34JMXJR/


[ovirt-users] Re: subnets

2020-03-04 Thread Dominik Holler
On Tue, Mar 3, 2020 at 1:48 PM  wrote:

> Uncheck passthrough and make sure the vnic is part of a legitimate network.
>
>
>

Does this mean that there are still problems to schedule the VM?
If so, please share the relevant lines of engine.log.


> Eric Evans
>
> Digital Data Services LLC.
>
> 304.660.9080
>
>
>
> *From:* Dominik Holler 
> *Sent:* Tuesday, March 03, 2020 6:03 AM
> *To:* eev...@digitaldatatechs.com
> *Cc:* users 
> *Subject:* [ovirt-users] Re: subnets
>
>
>
>
>
>
>
> On Sat, Feb 29, 2020 at 9:03 PM  wrote:
>
> When I attach a vnic to  a vm and try to start it I get the following
> message:
>
>
>
>- Cannot run VM. There is no host that satisfies current scheduling
>constraints. See below for details:
>- The host kvm04 did not satisfy internal filter Network because there
>are no free virtual functions which are suitable for virtual nic(s) nic3. A
>virtual function is considered as suitable if the VF's configuration of its
>physical function contains the virtual nic's network/network label.
>- The host kvm02 did not satisfy internal filter Network because there
>are no free virtual functions which are suitable for virtual nic(s) nic3. A
>virtual function is considered as suitable if the VF's configuration of its
>physical function contains the virtual nic's network/network label.
>- The host kvm01 did not satisfy internal filter
>VmToHostsAffinityGroups because it did not match positive affinity rules .
>
> I am new to ovirt and never had an issue with kvm hypervisor.
>
>
>
> Can you please ensure that the checkbox Passthrough of the vNIC profile is
> not actived?
>
>
> https://www.ovirt.org/documentation/admin-guide/chap-Logical_Networks.html#creating-or-editing-a-vnic-profile
>
>
>
>
>
>
>
> Eric Evans
>
> Digital Data Services LLC.
>
> 304.660.9080
>
>
>
> *From:* Alex K 
> *Sent:* Saturday, February 29, 2020 2:48 PM
> *To:* eev...@digitaldatatechs.com
> *Cc:* users 
> *Subject:* [ovirt-users] Re: subnets
>
>
>
>
>
> On Sat, Feb 29, 2020, 18:38  wrote:
>
> I have a network in place with several subnets, one for iscsi and one for
> virtual pbx and VoIP phones. I use the iscsi in Ovirt, but I cannot get
> Ovirt to recognize and use the physical vlan 3 network for phones. If I add
> it and the subnet, Ovirt will make give it an IP, but it's an isolated
> network with no connectivity to the other vm's or the Internet.
>
> You will need to attach a vm to a network in order the vm to have access
> to the specific network. This should be straightforward from web gui.
>
> I have read several topics on this but I can't get it to work properly.
> Any help would be appreciated.
> Thanks.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/CYXBJM43M6TR6GZKU3AKE2LTCGDBS7MK/
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/JNBUBZ3UY4URQ6F3433DWPPOYY2YXVG7/
>
>
>
>
___
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/NXALYVRZKZCMDC4XLJLAUSTGVRA2OERV/


[ovirt-users] Re: subnets

2020-03-03 Thread Dominik Holler
On Sat, Feb 29, 2020 at 9:03 PM  wrote:

> When I attach a vnic to  a vm and try to start it I get the following
> message:
>
>
>
>- Cannot run VM. There is no host that satisfies current scheduling
>constraints. See below for details:
>- The host kvm04 did not satisfy internal filter Network because there
>are no free virtual functions which are suitable for virtual nic(s) nic3. A
>virtual function is considered as suitable if the VF's configuration of its
>physical function contains the virtual nic's network/network label.
>- The host kvm02 did not satisfy internal filter Network because there
>are no free virtual functions which are suitable for virtual nic(s) nic3. A
>virtual function is considered as suitable if the VF's configuration of its
>physical function contains the virtual nic's network/network label.
>- The host kvm01 did not satisfy internal filter
>VmToHostsAffinityGroups because it did not match positive affinity rules .
>
> I am new to ovirt and never had an issue with kvm hypervisor.
>

Can you please ensure that the checkbox Passthrough of the vNIC profile is
not actived?
https://www.ovirt.org/documentation/admin-guide/chap-Logical_Networks.html#creating-or-editing-a-vnic-profile



>
>
> Eric Evans
>
> Digital Data Services LLC.
>
> 304.660.9080
>
>
>
> *From:* Alex K 
> *Sent:* Saturday, February 29, 2020 2:48 PM
> *To:* eev...@digitaldatatechs.com
> *Cc:* users 
> *Subject:* [ovirt-users] Re: subnets
>
>
>
>
>
> On Sat, Feb 29, 2020, 18:38  wrote:
>
> I have a network in place with several subnets, one for iscsi and one for
> virtual pbx and VoIP phones. I use the iscsi in Ovirt, but I cannot get
> Ovirt to recognize and use the physical vlan 3 network for phones. If I add
> it and the subnet, Ovirt will make give it an IP, but it's an isolated
> network with no connectivity to the other vm's or the Internet.
>
> You will need to attach a vm to a network in order the vm to have access
> to the specific network. This should be straightforward from web gui.
>
> I have read several topics on this but I can't get it to work properly.
> Any help would be appreciated.
> Thanks.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/CYXBJM43M6TR6GZKU3AKE2LTCGDBS7MK/
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/JNBUBZ3UY4URQ6F3433DWPPOYY2YXVG7/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/JFGDGZ4FAIDQWYMKPIBCJ7SPN6QFFJ54/


[ovirt-users] Re: oVirt 4.3.8 ovn vms doesn't ping

2020-02-27 Thread Dominik Holler
On Wed, Feb 26, 2020 at 7:02 PM Gianluca Cecchi 
wrote:

> On Wed, Feb 26, 2020 at 6:01 PM Dominik Holler  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 10:16 AM Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> Hello,
>>> I have an environment with oVirt 4.3.8.
>>> All seems ok from a configuration point of view, but if I use OVN based
>>> interfaces on two VMs, they are not able to ping, both if I put them on the
>>> same host and if I put on different hosts.
>>> At this point they are both running on the same host and their only vnic
>>> is on ovn172 network (defined as 192.168.172.0/24).
>>>
>>
>> Did the VMs got an IP address via DHCP from OVN?
>>
>
> No, both VMs are static ip
>
>
>> Can you please create a new OVN network with port security disabled and
>> try again?
>>
>
> Ah ah! I forgot this thing of the port security again
> Putting the Vms on a port security disabled OVN network they are able to
> ping each other both when on same host and on hosts sitting in different
> physical datacenters
>
> Is it possible to change to disabled an existing OVN network with port
> security enabled?
> It seems all is greyed out when editing
>

Yes, you have to disable directly via OpenStack API.
Please note that the attribute of the network applies only to ports that
are created after the attribute is changed on the network.
So if you want to disable port security for an existing port, you have to
disable this on the port via the OpenStack API.



>
> Thanks. You already told me this in the past
>
>
I am always happy to hear your feedback!


> Gianluca
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/APWEBELSUJKGGU4FLQ3AKNRZJILAEGLJ/


[ovirt-users] Re: Windows deployment

2020-02-26 Thread Dominik Holler
On Wed, Feb 26, 2020 at 11:45 PM  wrote:

> It is a Red Hat Virtio Ethernet Adapter.
>
>
>

Would a e1000 or rtl8139 work for your scenario?



> Eric Evans
>
> Digital Data Services LLC.
>
> 304.660.9080
>
>
>
> *From:* Dominik Holler 
> *Sent:* Wednesday, February 26, 2020 11:55 AM
> *To:* eev...@digitaldatatechs.com
> *Cc:* users 
> *Subject:* [ovirt-users] Re: Windows deployment
>
>
>
>
>
>
>
> On Wed, Feb 26, 2020 at 4:45 PM  wrote:
>
> I have a Windows Deployment server that works with Hyper-V. I am tryng to
> see if it will bare metal provision to Ovirt.
>
>
>
> Do you want to provision Windows into an oVirt VM?
>
>
>
> I have the necessary drivers loaded
>
>
>
> I am not familiar with the Windows deployment server.
>
> Would you help me to understand which drivers are loaded to what?
>
>
>
> and initially it gets an IP and starts the installation.
>
>
>
> I understand that the windows installer is starting. Where does he get the
> files from?
>
>
>
> When it comes to the screen starting setup, I get an IP error. I have
> included a screenshot.
>
>
>
> Might this be related to network drivers?
>
> If Windows in an oVirt VM, what is the type of the virtual NIC?
>
> Maybe using the e1000 or rtl8139 as type of the virtual NIC helps until
> the VirtIO drivers are ins
> talled?
>
>
>
> Has anyone see this before?
>
> I also considered provisioning from Foreman but I would rather use what I
> have instead of recreating the entire installation.
> Any help would be appreciated.
>
> Here is a link to the actual error:
>
> ftp://ftp.digitaldatatechs.com/pub/Windows%20Provision.jpg
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/BGGJTCK7PZKCUS65BBDP6UXX4KIHW7V5/
>
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/B2Z77CA4HYHJ7X7ADEDE5XUP2STXTGSI/


[ovirt-users] Re: oVirt 4.3.8 ovn vms doesn't ping

2020-02-26 Thread Dominik Holler
On Wed, Feb 26, 2020 at 10:16 AM Gianluca Cecchi 
wrote:

> Hello,
> I have an environment with oVirt 4.3.8.
> All seems ok from a configuration point of view, but if I use OVN based
> interfaces on two VMs, they are not able to ping, both if I put them on the
> same host and if I put on different hosts.
> At this point they are both running on the same host and their only vnic
> is on ovn172 network (defined as 192.168.172.0/24).
>

Did the VMs got an IP address via DHCP from OVN?
Can you please create a new OVN network with port security disabled and try
again?
Was the openvswitch or ovn package upgraded during the update?


> I have this
>
> manager
> # ovn-nbctl show
> switch fc2fc4e8-ff71-4ec3-ba03-536a870cd483
> (ovirt-ovn192-1e252228-ade7-47c8-acda-5209be358fcf)
> switch 87012fa6-ffaa-4fb0-bd91-b3eb7c0a2fc1
> (ovirt-ovn193-d43a7928-0dc8-49d3-8755-5d766dff821a)
> port 8141047d-10c0-41f6-bedc-130552a115ef
> addresses: ["00:1a:4a:17:01:54 dynamic"]
> port 90559419-cb8e-45ae-ad61-6c16c4aff598
> addresses: ["00:1a:4a:17:01:52 dynamic"]
> port b3db190f-086a-4c79-99a0-77f811f66c80
> addresses: ["00:1a:4a:17:01:53 dynamic"]
> switch 9e77163a-c4e4-4abf-a554-0388e6b5e4ce
> (ovirt-ovn172-4ac7ba24-aad5-432d-b1d2-672eaeea7d63)
> port 3641cae4-18df-4fba-a2bd-7b0c60a87162
> addresses: ["00:1a:4a:19:01:59 dynamic"]
> port aaddc425-3a38-49bf-bfc7-9eaeab82906e
> addresses: ["00:1a:4a:19:01:58 dynamic"]
>
> The two macs correspond to what I see for VMs in web admin gui and at os
> level of the two VMs.
>
> On the host where VMs are running I have:
> # ovs-vsctl show
> f1a41e9c-16fb-4aa2-a386-2f366ade4d3c
> Bridge br-int
> fail_mode: secure
> Port "ovn-b8872a-0"
> Interface "ovn-b8872a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.34"}
> Port br-int
> Interface br-int
> type: internal
> Port "vnet0"
> Interface "vnet0"
> Port "ovn-1dce5b-0"
> Interface "ovn-1dce5b-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.32"}
> Port "vnet1"
> Interface "vnet1"
> ovs_version: "2.11.0"
>
> So apparently I see the vnet0 and vnet1 ports associated with the two VMs
> How can I check more in depth the reason why they don't ping?
>

If OVN would be unhappy, there would be an hint in
/var/log/openvswitch/*.log .
If the VMs get an IP address via DHCP, OVN should be fine.
In this case we have to check if we blocked by traffic in an unintended way.


> Both VMs are CentOS 8.1 but I don't know if it is relevant.
>
> Thanks,
> Gianluca
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/DAFG32P7R5Y67O2PI6URTAHPPY4MWJ76/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/RKETN6KMHE2FLHNLFVV3WXZWNLMNTGLK/


[ovirt-users] Re: Windows deployment

2020-02-26 Thread Dominik Holler
On Wed, Feb 26, 2020 at 4:45 PM  wrote:

> I have a Windows Deployment server that works with Hyper-V. I am tryng to
> see if it will bare metal provision to Ovirt.


Do you want to provision Windows into an oVirt VM?


> I have the necessary drivers loaded


I am not familiar with the Windows deployment server.
Would you help me to understand which drivers are loaded to what?


> and initially it gets an IP and starts the installation.


I understand that the windows installer is starting. Where does he get the
files from?


> When it comes to the screen starting setup, I get an IP error. I have
> included a screenshot.
>

Might this be related to network drivers?
If Windows in an oVirt VM, what is the type of the virtual NIC?
Maybe using the e1000 or rtl8139 as type of the virtual NIC helps until the
VirtIO drivers are ins
talled?

Has anyone see this before?
>
> I also considered provisioning from Foreman but I would rather use what I
> have instead of recreating the entire installation.
> Any help would be appreciated.
>
> Here is a link to the actual error:
>
> ftp://ftp.digitaldatatechs.com/pub/Windows%20Provision.jpg
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/BGGJTCK7PZKCUS65BBDP6UXX4KIHW7V5/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/RHWNXBIIGWLEQZWHYIVS543MZNSHXJJ6/


[ovirt-users] Re: Error while making hosts

2020-02-07 Thread Dominik Holler
On Fri, Feb 7, 2020 at 3:26 PM  wrote:

> Hello,
> I am a student and as a school project i have to make virtual environment
> using oVirt. I just installed the oVirt-engine with the recomended
> configuration in the documentation and when i try to make a new host i got
> this error:
> Error while executing action: Cannot add Host. Connecting to host via SSH
> has failed, verify that the host is reachable (IP address, routable address
> etc.) You may refer to the engine.log file for further details.
> When i checked the log file the only thing that was there is that there
> is:
> 2020-02-06 03:59:24,594-05 ERROR
> [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (default task-30)
> [d54ee4df-32c8-474c-b315-51ad1131091a] Failed to establish session with
> host 'test': SSH connection timed out connecting to 'root@10.10.0.20'
>

Can you ssh root@10.10.0.20 from Engine's machine?
Can Engine's machine ping 10.10.0.20?
Can Engine's machine connect to 10.10.0.20 port 22 (e.g. check with "nc -vz
10.10.0.2 22")?
What is the network configuration of the host with the IP address
10.10.0.20 before and after adding it to oVirt?
Please have a look at the relevant files in
/var/log/ovirt-engine/host-deploy/, and if exists /var/log/vdsm/* on the
host.
If these questions does not point you to the answer, please share the
answers to these questions and the logfiles.





> I was trying to make the host following this steps:
>
> Adding a Host to the oVirt Engine
>
> 1.Click Compute → Hosts.
>
> 2.Click New.
>
> 3.Use the drop-down list to select the Data Center and Host Cluster for
> the new host.
>
> 4.Enter the Name and the Hostname of the new host. The standard SSH port,
> port 22, is auto-filled in the SSH Port field.
>
> 5.Select an authentication method to use for the Engine to access the host.
>
> Enter the root user’s password to use password authentication.
>
> Alternatively, copy the key displayed in the SSH PublicKey field to
> /root/.ssh/authorized_keys on the host to use public key authentication.
>
> 6.Click the Advanced Parameters button to expand the advanced host
> settings.
>
> i. Optionally disable automatic firewall configuration.
>
> ii. Optionally add a host SSH fingerprint to increase security. You can
> add it manually, or fetch it automatically.
>
> 7.Optionally configure Power Management, SPM, Console, Network Provider,
> and Kernel. See Explanation of Settings and Controls in the New Host and
> Edit Host Windows for more information. Hosted Engine is used when
> deploying or undeploying a host for a self-hosted engine deployment.
>
> 8.Click OK.
>
> The new host displays in the list of hosts with a status of Installing,
> and you can view the progress of the installation in the details pane.
> After a brief delay the host status changes to Up.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/HWSFFHMS6ECHK4B7GZXS4PCUY5CYAJQL/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/7GGTWP7NS66UY62245PIWHHPER6RDZKF/


[ovirt-users] Re: oVirt MAC Pool question

2020-02-04 Thread Dominik Holler
On Mon, Feb 3, 2020 at 12:10 PM Vrgotic, Marko 
wrote:

> Hi Dominik,
>
>
>
> Thank you – please find the sql query output file attached.
>
>
>
> In addition, today, while spawning set of VMs, and we are mostly using
> Ansible (98% of the time), we got this message:
>
> An exception occurred during task execution. To see the full traceback,
> use -vvv. The error was: ovirtsdk4.Error: Fault reason is "Operation
> Failed". Fault detail is "[MAC Address 56:6f:ef:88:0b:23 is already in use
> by VM or snapshot: fred-appcloud.]". HTTP response code is 409.
> fatal: [suilen-th-scalernode3.avinity.tv -> localhost]: FAILED! =>
> {"changed": false, "msg": "Fault reason is \"Operation Failed\". Fault
> detail is \"[MAC Address 56:6f:ef:88:0b:23 is already in use by VM or
> snapshot: fred-appcloud.]\". HTTP response code is 409."}
>
>
>
> The mac addresses are not defined in ovirt_vm or cloud_init_nics module,
> we always let oVirt assign mac address.
>

Thanks for your input!
I am highly interested if you can confirm, that no virtual NIC with a
duplicated MAC address is created?

The issue you are running into might be
*Bug 1760170* <https://bugzilla.redhat.com/show_bug.cgi?id=1760170> - If an
in-use MAC is held by a VM on a different cluster, the engine does not
attempt to get the next free MAC.

What happens in this bug is that a new MAC address is generated, which is
not yet used inside the mac pool.
But oVirt runs a final check before creating the vNIC, to ensure that no
duplicated MAC is used across all managed VMs (across all mac pools),
which fails because the MAC is used in a cluster that is associated with
another mac pool.

Would a workaround like adjusting all MAC addresses of all vNICs according
to the mac pool ranges which are associated with the cluster be achievable
for you, e.g. by re-creating the vNICs?



>
>
> In addition, I have enabled “deny duplicates;” and “one-lease-per-client;”
> on our isc-dhcp  for subnet, in order to try to prevent this.
>
>
>
> As mentioned in previous email, I have already switched last week to
> having unique pool per cluster and here are the ranges:
>
> [root@ovirt-engine ~]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh
> -c "select from_mac, to_mac from mac_pools, mac_pool_ranges where
> id=mac_pool_id"
>
>  from_mac  |  to_mac
>
> ---+---
>
> 56:6f:ef:88:00:00 | 56:6f:ef:88:ff:ff
>
> 56:6f:ef:86:00:00 | 56:6f:ef:86:ff:ff
>
> 56:6f:ef:82:00:00 | 56:6f:ef:82:ff:ff
>
> 56:6f:ef:84:00:00 | 56:6f:ef:84:ff:ff
>
>
>
> Kindly awaiting your reply.
>
>
>
> If additional information is required, I will be happy to provide.
>
>
>
>
>
> -
>
> kind regards/met vriendelijke groeten
>
>
>
> Marko Vrgotic
> Sr. System Engineer @ System Administration
>
>
> ActiveVideo
>
> *o: *+31 (35) 6774131
>
> *e:* m.vrgo...@activevideo.com
> *w: *www.activevideo.com
>
>
>
> ActiveVideo Networks BV. Mediacentrum 3745 Joop van den Endeplein 1.1217
> WJ Hilversum, The Netherlands. The information contained in this message
> may be legally privileged and confidential. It is intended to be read only
> by the individual or entity to whom it is addressed or by their designee.
> If the reader of this message is not the intended recipient, you are on
> notice that any distribution of this message, in any form, is strictly
> prohibited.  If you have received this message in error, please immediately
> notify the sender and/or ActiveVideo Networks, LLC by telephone at +1
> 408.931.9200 and delete or destroy any copy of this message.
>
>
>
>
>
>
>
>
>
>
>
> *From: *Dominik Holler 
> *Date: *Monday, 3 February 2020 at 10:11
> *To: *"Vrgotic, Marko" 
> *Cc: *Yedidyah Bar David , "users@ovirt.org" <
> users@ovirt.org>
> *Subject: *Re: [ovirt-users] oVirt MAC Pool question
>
>
>
>
>
>
>
> On Fri, Jan 31, 2020 at 9:56 AM Vrgotic, Marko 
> wrote:
>
> Dear Yedidyah,
>
> We are actually seeing collisions, which is why I reached out in first
> place.
> Strange is that is did not happen since few weeks ago, and since then I
> saw it multiple times.
>
>
>
> I am interested in reproducing this issue.
>
> Can you please describe how this situation was created?
>
> Are the related virtual NICs created in oVirt, or are they imported?
>
> Is it still possible to create duplicates, or do you have a backup of the
> db during this period?
>
> Can you please share the output of
>
> /usr/share/ovirt-engine/dbscripts/engine-psql.sh  -c "se

[ovirt-users] Re: Failed to synchronize networks of Provider ovirt-provider-ovn

2020-02-03 Thread Dominik Holler
On Mon, Feb 3, 2020 at 1:07 PM  wrote:

> Hi Dominik!
> So, this solution helps!
> But, if i do step #7 it returns to pervious (bad) state and i need to do
> all 6 steps again.
>

Step 7 is now independent from the other steps.
You are welcome to post the error message where the certificates fail.
https://github.com/oVirt/ovirt-provider-ovn/blob/master/README.adoc
explains the ssl configuration of the ovirt-provider-ovn.



> Thank u 4 help!!!
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/LQAQFSSPE6EBCUCJV7BFAEIP4DTMFKGD/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/RPTTQ4UAMXB3D5AUKTDIH2QU36W22KV3/


[ovirt-users] Re: Failed to synchronize networks of Provider ovirt-provider-ovn

2020-02-03 Thread Dominik Holler
On Mon, Feb 3, 2020 at 11:39 AM Strahil Nikolov 
wrote:

> On February 3, 2020 11:23:57 AM GMT+02:00, Dominik Holler <
> dhol...@redhat.com> wrote:
> >On Wed, Oct 2, 2019 at 12:29 PM Mail SET Inc. Group 
> >wrote:
> >
> >> --reconfigure-optional-components not helps. And  the file
> >/etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
> >> not exists after setup.
> >>
> >> [root@engine ~]# rm
> >> /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
> >>
> >>
> >> [root@engine ~]# engine-setup --reconfigure-optional-components
> >> [ INFO  ] Stage: Initializing
> >> [ INFO  ] Stage: Environment setup
> >>   Configuration files:
> >> ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf',
> >> '/etc/ovirt-engine-setup.conf.d/10-packaging.conf',
> >> '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf']
> >>   Log file:
> >>
> >/var/log/ovirt-engine/setup/ovirt-engine-setup-20191002131904-4iwth0.log
> >>   Version: otopi-1.8.3 (otopi-1.8.3-1.el7)
> >> [ INFO  ] Stage: Environment packages setup
> >> [ INFO  ] Stage: Programs detection
> >> [ INFO  ] Stage: Environment setup (late)
> >> [ INFO  ] Stage: Environment customization
> >>
> >>
> >>   --== PRODUCT OPTIONS ==--
> >>
> >>
> >>   Set up Cinderlib integration
> >>   (Currently in tech preview)
> >>   (Yes, No) [No]:
> >> [ INFO  ] ovirt-provider-ovn already installed, skipping.
> >>
> >>
> >>
> >
> >
> >The old installation is still detected.
> >
> >1. backup /etc/ovirt-provider-ovn/
> >2. restore the original
> >/etc/ovirt-provider-ovn/ovirt-provider-ovn.conf,
> >e.g. to
> >
> https://github.com/oVirt/ovirt-provider-ovn/blob/master/provider/ovirt-provider-ovn.conf
> >3. /backup etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf,
> >4. rename ovirt-provider-ovn external provider entity in oVirt
> >webadmin,
> >5. comment OVESETUP_OVN/ovirtProviderOvnId
> >in /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
> >6. engine-setup --reconfigure-optional-components
> >7. If modifications of the certificates are required, please create a
> >new
> >file in /etc/ovirt-provider-ovn/conf.d/ , e.g. 50-ssl-modifications
> >
> >Do these steps solve the problem for you?
> >
> >
> >Dec 18 21:01:02  password should be the usual admin@interal
> >password
> >
> >
> >>
> >>   --== PACKAGES ==--
> >>
> >>
> >> [ INFO  ] Checking for product updates...
> >> [ INFO  ] No product updates found
> >>
> >>
> >>   --== NETWORK CONFIGURATION ==--
> >>
> >>
> >>   Setup can automatically configure the firewall on this
> >system.
> >>   Note: automatic configuration of the firewall may overwrite
> >> current settings.
> >>   NOTICE: iptables is deprecated and will be removed in
> >future
> >> releases
> >>   Do you want Setup to configure the firewall? (Yes, No)
> >[Yes]:
> >> [ INFO  ] firewalld will be configured as firewall manager.
> >>
> >>
> >>   --== DATABASE CONFIGURATION ==--
> >>
> >>
> >>   The detected DWH database size is 111 MB.
> >>   Setup can backup the existing database. The time and space
> >> required for the database backup depend on its size. This process
> >takes
> >> time, and in some cases (for instance, when the size is few GBs) may
> >take
> >> several hours to complete.
> >>   If you choose to not back up the database, and Setup later
> >fails
> >> for some reason, it will not be able to restore the database and all
> >DWH
> >> data will be lost.
> >>   Would you like to backup the existing database before
> >upgrading
> >> it? (Yes, No) [Yes]:
> >>   Perform full vacuum on the oVirt engine history
> >>   database ovirt_engine_history@localhost?
> >>   This operation may take a while depending on this setup
> >health
> >> and the
> >>   configuration of the db vacuum process.
> >>   See https://www.postgresql.org/docs/10/sql-vacuum.html
> >>   (Yes, No) [No]:
> >>
> >>
> >>   --== OVIRT ENGINE CON

[ovirt-users] Re: Failed to synchronize networks of Provider ovirt-provider-ovn

2020-02-03 Thread Dominik Holler
ble
> [ INFO  ] Cleaning stale zombie tasks and commands
>
>
>   --== CONFIGURATION PREVIEW ==--
>
>
>   Default SAN wipe after delete   : False
>   Firewall manager: firewalld
>   Update Firewall : True
>   Host FQDN   : engine.set.local
>   Set up Cinderlib integration: False
>   Engine database secured connection  : False
>   Engine database user name   : engine
>   Engine database name: engine
>   Engine database host: localhost
>   Engine database port: 5432
>   Engine database host name validation: False
>   Engine installation : True
>   PKI organization: set.local
>   Set up ovirt-provider-ovn   : True
>   Configure WebSocket Proxy   : True
>   DWH installation: True
>   DWH database secured connection : False
>   DWH database host   : localhost
>   DWH database user name  : ovirt_engine_history
>   DWH database name   : ovirt_engine_history
>   Backup DWH database : True
>   DWH database port   : 5432
>   DWH database host name validation   : False
>   Configure Image I/O Proxy   : True
>   Configure VMConsole Proxy   : True
>
>
>   Please confirm installation settings (OK, Cancel) [OK]:
> [ INFO  ] Cleaning async tasks and compensations
> [ INFO  ] Unlocking existing entities
> [ INFO  ] Checking the Engine database consistency
> [ INFO  ] Stage: Transaction setup
> [ INFO  ] Stopping engine service
> [ INFO  ] Stopping ovirt-fence-kdump-listener service
> [ INFO  ] Stopping dwh service
> [ INFO  ] Stopping Image I/O Proxy service
> [ INFO  ] Stopping vmconsole-proxy service
> [ INFO  ] Stopping websocket-proxy service
> [ INFO  ] Stage: Misc configuration (early)
> [ INFO  ] Stage: Package installation
> [ INFO  ] Stage: Misc configuration
> [ INFO  ] Upgrading CA
> [ INFO  ] Updating /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf to
> use apache key and certificate
> [ INFO  ] Backing up database localhost:ovirt_engine_history to
> '/var/lib/ovirt-engine-dwh/backups/dwh-20191002132135.4DV89M.dump'.
> [ INFO  ] Creating/refreshing DWH database schema
> [ INFO  ] Configuring Image I/O Proxy
> [ INFO  ] Configuring WebSocket Proxy
> [ INFO  ] Backing up database localhost:engine to
> '/var/lib/ovirt-engine/backups/engine-20191002132145.CzmG31.dump'.
> [ INFO  ] Creating/refreshing Engine database schema
> [ INFO  ] Creating/refreshing Engine 'internal' domain database schema
>   Unregistering existing client registration info.
> [ INFO  ] Generating post install configuration file
> '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'
> [ INFO  ] Stage: Transaction commit
> [ INFO  ] Stage: Closing up
> [ INFO  ] Starting engine service
> [ INFO  ] Starting dwh service
> [ INFO  ] Restarting ovirt-vmconsole proxy service
>
>
>   --== SUMMARY ==--
>
>
> [ INFO  ] Restarting httpd
>   Web access is enabled at:
>   http://engine.set.local:80/ovirt-engine
>   https://engine.set.local:443/ovirt-engine
>   Internal CA
> 98:A1:43:62:A6:0E:FE:4E:13:FA:0E:3F:F8:68:0C:62:01:31:16:BA
>   SSH fingerprint:
> SHA256:NrIqDX9x7XrqE7CXpm/D9xpqnF9J162+42xiFiR5m1s
> [WARNING] Less than 16384MB of memory is available
>
>
>   --== END OF SUMMARY ==--
>
>
> [ INFO  ] Stage: Clean up
>   Log file is located at
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20191002131904-4iwth0.log
> [ INFO  ] Generating answer file
> '/var/lib/ovirt-engine/setup/answers/2019100213-setup.conf'
> [ INFO  ] Stage: Pre-termination
> [ INFO  ] Stage: Termination
> [ INFO  ] Execution of setup completed successfully
>
>
> [root@engine ~]# tail -f /var/log/ovirt-provider-ovn.log
> error = stream.connect()
>   File "/usr/lib64/python2.7/site-packages/ovs/stream.py", line 802, in
> connect
> self.socket.do_handshake()
>   File "/usr/lib/python2.7/site-packages/OpenSSL/SSL.py", line 1716, in
> do_handshake
> self._raise_ssl_error(self._ssl, result)
>   File "/usr/lib/python2.7/site-packages/OpenSSL/SSL.py", line 1456, in
> _raise_ssl_error
> _raise_current_error()
>   File "/usr/li

[ovirt-users] Re: oVirt MAC Pool question

2020-02-03 Thread Dominik Holler
On Fri, Jan 31, 2020 at 9:56 AM Vrgotic, Marko 
wrote:

> Dear Yedidyah,
>
> We are actually seeing collisions, which is why I reached out in first
> place.
> Strange is that is did not happen since few weeks ago, and since then I
> saw it multiple times.
>

I am interested in reproducing this issue.
Can you please describe how this situation was created?
Are the related virtual NICs created in oVirt, or are they imported?
Is it still possible to create duplicates, or do you have a backup of the
db during this period?
Can you please share the output of
/usr/share/ovirt-engine/dbscripts/engine-psql.sh  -c "select
vm_interface.mac_addr,vm_interface.vm_guid,vm_interface.name,vm_static.cluster_id,cluster.mac_pool_id,mac_pools.allow_duplicate_mac_addresses,mac_pool_ranges.from_mac,mac_pool_ranges.to_mac
from  vm_interface left join vm_static on vm_interface.vm_guid =
vm_static.vm_guid) left join cluster on vm_static.cluster_id =
cluster.cluster_id) left join mac_pools on cluster.mac_pool_id =
mac_pools.id) left join mac_pool_ranges on mac_pools.id =
mac_pool_ranges.mac_pool_id) order by vm_interface.mac_addr;"
and point us to the virtual NICs or VMs which contained the duplicated MACs?


> For now I am simply going to create new mac pool for each of the clusters
> and switch to it, hoping it's not going to affect existing VMs.
>
>
This will affect only newly created virtual NICs.


> Regarding planning, if I would have known, that same mac pool is created
> across datacenters/clusters, I would have taken it into account.
>

Even the mac pool is shared, the mac addresses should be unique across all
datacenters managed by a single oVirt Engine.


> Relying on common sense, I just did not expect this to be the case, but to
> my fault I should have applied trust-but-verify approach.
>
>
> -
> kind regards/met vriendelijke groeten
>
> Marko Vrgotic
> Sr. System Engineer
>
> ActiveVideo
> e: m.vrgo...@activevideo.com
>
>
> On 26/01/2020, 07:45, "Yedidyah Bar David"  wrote:
>
> On Thu, Jan 23, 2020 at 2:30 PM Vrgotic, Marko
>  wrote:
> >
> > Hi Yedidyah,
> >
> > Thank you for you update.
> >
> > This platform started with 4.3 deployment.
> > The Default mac address pool, apparently on all Clusters (5) is:
> >  from_mac  |  to_mac
> > ---+---
> >  56:6f:ef:88:00:00 | 56:6f:ef:88:ff:ff
> >
>
> I think I misled you, or for some reason didn't understand your
> original post. The default pool is for "everything". I thought you
> refer to different setups - separate engines - and the bug I mentioned
> about changing the default was addressed at this scenario.
>
> Inside a single engine, there is only one default.
>
> You should not see collisions *inside* it. Do you? The engine should
> know no to allocated the same mac to two different NICs.
>
> > Interestingly enough, I am alos not able to add another mac pool to
> Default. I can only create new one,
>
> Correct.
>
> > let's say MacPool2 and also create only single pool inside. Option
> to add second mac range under same name is grayed out, whether I login as
> SuperUser or Admin to Aministration Portal.
>
> Indeed. You can only change it, not add a new one with the same name.
>
> >
> > Never mind, it is as so, but I am still not "happiest" with:
> > > Question2: Would there be an harming effect on existing VMs if
> the default mac pool would be changed?
> >=>I am pretty certain it's harmless, but didn't try that
> myself.
> >  Reason is that I have 600VMs on 5 cluster setup in production - If
> I make the change where currently required and we are wrong, its going to
> affect almost half of those existing VMs. I did test the change on the
> staging, and it did not seem to have any harmful effect but that one has
> like 5VMs atm.
> >
> > I will run some additional tests on staging to see if I can get more
> comfortable before making change in production, but if anyone else can
> contribute boosting the confidence, please let me know.
>
> Ccing Dominik from the network team.
>
> I am pretty certain that people do change/add pools live, but guess
> not often - I guess most people plan ahead and then don't touch.
>
> Groetjes,
> --
> Didi
>
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/WOOLC3OTOZ7D44UXXNP6R2XAF4W2CZAC/


[ovirt-users] Re: VM migrations stalling over migration-only network

2020-01-20 Thread Dominik Holler
On Mon, Jan 20, 2020 at 2:34 PM Milan Zamazal  wrote:

> Ben  writes:
>
> > Hi Milan,
> >
> > Thanks for your reply. I checked the firewall, and saw that both the
> bond0
> > interface and the VLAN interface bond0.20 had been added to the default
> > zone, which I believe should provide the necessary firewall access
> (output
> > below)
> >
> > I double-checked the destination host's VDSM logs and wasn't able to find
> > any warning or error-level logs during the migration timeframe.
> >
> > I checked the migration_port_* and *_port settings in qemu.conf and
> > libvirtd.conf and all lines are commented. I have not modified either
> file.
>
> The commented out settings define the default port used for migrations,
> so they are valid even when commented out.  I can see you have
> libvirt-tls open below, not sure about the QEMU ports.  If migration
> works when not using a separate migration network then it should work
> with the same rules for the migration network, so I think your settings
> are OK.
>
> The fact that you don't get any better explanation than "unexpectedly
> failed" and that it fails before transferring any data indicates a
> possible networking error, but I can't help with that, someone with
> networking knowledge should.
>
>
Can you please share the relevant lines which logs the start of the
migration on the source host from vdsm.log?
This line should contain the IP address on migration network of the
destination host.
Please note that there are two network connections: the libvirt's control
data is transmitted on the management
network encrypted, while the qemu's data is transmitted on the migration
network.
On source host, can you please
ping -M do -s $((9000 - 28))
dest_ip_address_on_migration_network_from_vdsm_log
nc -vz dest_ip_address_on_migration_network_from_vdsm_log
dest_port_on_migration_network_from_vdsm_log




> You can also try to enable libvirt debugging on both the sides in
> /etc/libvirt/libvirtd.conf and restart libvirt (beware, those logs are
> huge).  libvirt logs should report some error.
>
> > [root@vhost2 vdsm]# firewall-cmd --list-all
> > public (active)
> >   target: default
> >   icmp-block-inversion: no
> >   interfaces: bond0 bond0.20 em1 em2 migration ovirtmgmt p1p1
> >   sources:
> >   services: cockpit dhcpv6-client libvirt-tls ovirt-imageio
> ovirt-vmconsole
> > snmp ssh vdsm
> >   ports: 1311/tcp 22/tcp 6081/udp 5666/tcp
> >   protocols:
> >   masquerade: no
> >   forward-ports:
> >   source-ports:
> >   icmp-blocks:
> >   rich rules:
> >
> > On Mon, Jan 20, 2020 at 6:29 AM Milan Zamazal 
> wrote:
> >
> >> Ben  writes:
> >>
> >> > Hi, I'm pretty stuck at the moment so I hope someone can help me.
> >> >
> >> > I have an oVirt 4.3 data center with two hosts. Recently, I attempted
> to
> >> > segregate migration traffic from the the standard ovirtmgmt network,
> >> where
> >> > the VM traffic and all other traffic resides.
> >> >
> >> > I set up the VLAN on my router and switch, and created LACP bonds on
> both
> >> > hosts, tagging them with the VLAN ID. I confirmed the routes work
> fine,
> >> and
> >> > traffic speeds are as expected. MTU is set to 9000.
> >> >
> >> > After configuring the migration network in the cluster and dragging
> and
> >> > dropping it onto the bonds on each host, VMs fail to migrate.
> >> >
> >> > oVirt is not reporting any issues with the network interfaces or sync
> >> with
> >> > the hosts. However, when I attempt to live-migrate a VM, progress
> gets to
> >> > 1% and stalls. The transfer rate is 0Mbps, and the operation
> eventually
> >> > fails.
> >> >
> >> > I have not been able to identify anything useful in the VDSM logs on
> the
> >> > source or destination hosts, or in the engine logs. It repeats the
> below
> >> > WARNING and INFO logs for the duration of the process, then logs the
> last
> >> > entries when it fails. I can provide more logs if it would help. I'm
> not
> >> > even sure where to start -- since I am a novice at networking, at
> best,
> >> my
> >> > suspicion the entire time was that something is misconfigured in my
> >> > network. However, the routes are good, speed tests are fine, and I
> can't
> >> > find anything else wrong with the connections. It's not impacting any
> >> other
> >> > traffic over the bond interfaces.
> >> >
> >> > Are there other requirements that must be met for VMs to migrate over
> a
> >> > separate interface/network?
> >>
> >> Hi, did you check your firewall settings?  Are the required ports open?
> >> See migration_port_* options in /etc/libvirt/qemu.conf and *_port
> >> options in /etc/libvirt/libvirtd.conf.
> >>
> >> Is there any error reported in the destination vdsm.log?
> >>
> >> Regards,
> >> Milan
> >>
> >> > 2020-01-12 03:18:28,245-0500 WARN  (migmon/a24fd7e3) [virt.vm]
> >> > (vmId='a24fd7e3-161c-451e-8880-b3e7e1f7d86f') Migration stalling:
> >> remaining
> >> > (4191MiB) > lowmark (4191MiB). (migration:854)
> >> > 2020-01-12 03:18:28,245-0500 INFO  (migmon/a24fd7e3) 

[ovirt-users] Re: ovirt-provider-ovn external network provider

2020-01-14 Thread Dominik Holler
Hello Paul,

On Mon, Jan 13, 2020 at 3:46 PM  wrote:

> Hello I was testing the ovirt-provider-ovn which was working but at some
> point  seems to have stopped.
>
>
Sounds like the ovn-controller on the hosts has a problem.

Please ensure that the ovn-controller is running on all relevant hosts.
If it is running and not working, can you please share the
ovn-controller.log with us?

Do you have any idea, what happened to the point in time it stopped working?
I heard similar stories already multiple times, but in the past, the users
just restarted ovn-controller and all hosts and it was working again,
but it would be helpful to understand why it was stopped, to prevent
this from happening again.




> The logical networks are created and VMs have their ports created and
> attached on the hosts they run or migrate to but their are no geneve
> tunnels created and on the engine host "ovn-sbctl show" produces no output.
> Any help appreciated.
>
> Thanks,
>Paul S.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/SX2SJ7Y5S7JJPEPMUHEHQMSOUSZUOECF/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/Q7GBAUA6G4N62OECKB6P5DUSPDAHGAXG/


[ovirt-users] Re: Ovirt OVN help needed

2019-12-17 Thread Dominik Holler
 : []
> rstp_statistics : {}
> rstp_status : {}
> statistics  : {}
> status  : {}
> tag : []
> trunks  : []
> vlan_mode   : []
> [root@ovirt1 ~]#
>
> [root@ovirt2 ~]# ovs-vsctl show
> 3dbab138-6b90-44c5-af05-b8a944c9bf20
> Bridge br-int
> fail_mode: secure
> Port "ovn-baa019-0"
> Interface "ovn-baa019-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="192.168.1.90"}
> Port br-int
> Interface br-int
> type: internal
> Port "vnet5"
> Interface "vnet5"
> Port "ovn-566849-0"
> Interface "ovn-566849-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="192.168.1.41"}
> ovs_version: "2.11.0"
> [root@ovirt2 ~]# ovs-vsctl list port
> _uuid   : 151e1188-f07a-4750-a620-392a08e7e7fe
> bond_active_slave   : []
> bond_downdelay  : 0
> bond_fake_iface : false
> bond_mode   : []
> bond_updelay: 0
> cvlans  : []
> external_ids: {ovn-chassis-id="
> baa0199e-d1a4-484c-af13-a41bcad19dbc@192.168.1.90"}
> fake_bridge : false
> interfaces  :
> [4d4bc12a-609a-4917-b839-d4f652acdc33]lacp: []
> mac : []
> name: "ovn-baa019-0"
> other_config: {}
> protected   : false
> qos : []
> rstp_statistics : {}
> rstp_status : {}
> statistics  : {}
> status  : {}
> tag : []
> trunks  : []
> vlan_mode   : []
>
> _uuid   : 3a862f96-b3ec-46a9-bcf6-f385e5def410
> bond_active_slave   : []
> bond_downdelay  : 0
> bond_fake_iface : false
> bond_mode   : []
> bond_updelay: 0
> cvlans  : []
> external_ids: {}
> fake_bridge : false
> interfaces  :
> [777f2819-ca27-4890-8d2f-11349ca0d398]lacp: []
> mac : []
> name: br-int
> other_config: {}
> protected   : false
> qos : []
> rstp_statistics : {}
> rstp_status : {}
> statistics  : {}
> status  : {}
> tag : []
> trunks  : []
> vlan_mode   : []
>
> _uuid   : a65109fa-f8b4-4670-8ae8-a2bd0bf6aba3
> bond_active_slave   : []
> bond_downdelay  : 0
> bond_fake_iface : false
> bond_mode   : []
> bond_updelay: 0
> cvlans  : []
> external_ids: {ovn-chassis-id="
> 5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"}
> fake_bridge : false
> interfaces  :
> [ed442077-f897-4e0b-97a1-a8051e9c3d56]lacp: []
> mac : []
> name: "ovn-566849-0"
> other_config: {}
> protected   : false
> qos     : []
> rstp_statistics : {}
> rstp_status : {}
> statistics  : {}
> status  : {}
> tag : []
> trunks  : []
> vlan_mode   : []
>
> _uuid   : a1622e6f-fcd0-4a8a-b259-ca4d0ccf1cd2
> bond_active_slave   : []
> bond_downdelay  : 0
> bond_fake_iface : false
> bond_mode   : []
> bond_updelay: 0
> cvlans  : []
> external_ids: {}
> fake_bridge : false
> interfaces  :
> [ca368654-54f3-49d0-a71c-8894426df6bf]lacp: []
> mac : []
> name: "vnet5"
> other_config: {}
> protected   : false
> qos : []
> rstp_statistics : {}
> rstp_status : {}
> statistics  : {}
> status  : {}
> tag : []
> trunks  : []
> vlan_mode   : []
> [root@ovirt2 ~]#
>
> Best Regards,
> Strahil Nikolov
>
> On Dec 16, 2019 23:28, Dominik Holler  wrote:
> >
> >
> >
> > On Sat, Dec 14, 2019 at 11:36 AM Strahil Nikolov 
> wrote:
> >>
> >> Hi Dominik,
> >>
> >> yes I was looking for those settings.
> >>
> >> I have added again the external provider , but I guess the mess is even
> bigger as I made some stupid decisions (like removing 2 port groups :)
> without knowing what I'm doing) .
> >> Sadly I can't remove all packages on the engine and hosts 

[ovirt-users] Re: Ovirt OVN help needed

2019-12-16 Thread Dominik Holler
On Sat, Dec 14, 2019 at 11:36 AM Strahil Nikolov 
wrote:

> Hi Dominik,
>
> yes I was looking for those settings.
>
> I have added again the external provider , but I guess the mess is even
> bigger as I made some stupid decisions (like removing 2 port groups :)
> without knowing what I'm doing) .
> Sadly I can't remove all packages on the engine and hosts and reinstall
> them from scratch.
>
> Pip fails to install the openstacksdk (centOS7 is not great for such
> tasks) on the engine and my lack of knowledge in OVN makes it even more
> difficult.
>
> So the symptoms are that 2 machines can communicate with each other only
> if they are on the same host ,while on separate - no communications is
> happening.
>
>
This indicates that the tunnels between the hosts are not created.
Can you please check the /var/log/openvswitch/ovn-controller.log on both
hosts for errors and warnings, or share parts of the files here?
If this does not point us to a problem, ovn has to be reconfigured. If
possible, most easy way to do this would be to ensure that
ovirt-provider-ovn is the default network provider of the cluster of the
hosts, put one host after another in maintance mode and reinstall.



> How I created the network via UI:
>
> 1. Networks - new
> 2. Fill in the name
> 3. Create on external provider
> 4. Network Port security -> disabled (even undefined does not work)
> 5.Connect to physical network -> ovirtmgmt
>
>
> I would be happy to learn more about OVN and thus I would like to make it
> work.
>
> Here is some info from the engine:
>
> [root@engine ~]# ovn-nbctl show
> switch 1288ed26-471c-4bc2-8a7d-4531f306f44c
> (ovirt-pxelan-2a88b2e0-d04b-4196-ad50-074501e4ed08)
> port c1eba112-5eed-4c04-b25c-d3dcfb934546
> addresses: ["56:6f:5a:65:00:06"]
> port 8b52ab60-f474-4d51-b258-cb2e0a53c34a
> type: localnet
> addresses: ["unknown"]
> port b2753040-881b-487a-92a1-9721da749be4
> addresses: ["56:6f:5a:65:00:09"]
> [root@engine ~]# ovn-sbctl show
> Chassis "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> hostname: "ovirt3.localdomain"
> Encap geneve
> ip: "192.168.1.41"
> options: {csum="true"}
> Chassis "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> hostname: "ovirt1.localdomain"
> Encap geneve
> ip: "192.168.1.90"
> options: {csum="true"}
> Chassis "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> hostname: "ovirt2.localdomain"
> Encap geneve
> ip: "192.168.1.64"
> options: {csum="true"}
> Port_Binding "b2753040-881b-487a-92a1-9721da749be4"
> Port_Binding "c1eba112-5eed-4c04-b25c-d3dcfb934546"
>
>
> Is it possible to remove the vNICs , Virtual Network + and recreate the
> ovn db to start over ?
>

@Miguel Duarte de Mora Barroso  Is there a hardcore
way bypassing ovirt-provider-ovn to do this?


> I guess the other option is to create a VM that can be used to install
> python openstacksdk and modify via the python script from your previous
> e-mail.
>
>
Yes, a fedora VM in oVirt works great and creating a template from the
images from ovirt-image-repository is comfortable.


>
> Best Regards,
> Strahil Nikolov
>
>
> В петък, 13 декември 2019 г., 10:11:51 ч. Гринуич+2, Dominik Holler <
> dhol...@redhat.com> написа:
>
>
>
>
> On Fri, Dec 13, 2019 at 5:51 AM Strahil  wrote:
>
> Hi Dominik, All,
>
> I've checked '
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/W6U4XJHNMYMD3WIXDCPGOXLW6DFMCYIM/'
> and the user managed to clear up and start over.
>
> I have removed the ovn-external-provider  from UI, but I forgot to copy
> the data from the fields.
>
> Do you know any refference guide (or any tips & tricks) for adding OVN ?
>
>
> The ovirt-provider-ovn entity can be added to oVirt Engine as a new
> provider with
> Type: External Network Provider
> Network Plugin: oVirt Network Provider for OVN
> Provider URL: https://YOUR_ENGINE_FQDNt:9696
> Username: admin@internal
> Password: admin@interal password
> Host Name: YOUR_ENGINE_FQDN
> API Port: 35357
> API Version: v2.0
>
> Is this the information you need?
>
>
> Thanks in advance.
>
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 20:49, Strahil  wrote:
>
> Hi Dominik,
>
> Thanks for the reply.
>
> Sadly the openstack module is missing on the engine and I have to figure
> it out.
>
> Can't I just undeploy the ovn and then redeploy it back ?
>
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 09

[ovirt-users] Re: Cannot forward traffic through VXLAN

2019-12-16 Thread Dominik Holler
On Fri, Dec 13, 2019 at 3:56 PM  wrote:

> > On Thu, Dec 12, 2019 at 4:27 PM  >
> >
> >
> > Not external logical networks, with vNIC profiles, have no network filter
> > during the VM is started (or the vNIC is hotplugged),
> > allows any MAC address. This works without any hook required.
> > In most simple flow for a lab would be to remove the network filter from
> > ovirtmgmt, attach ovirtmgmt to a VM and boot the VM.
> >
> Well this is where theory contradicts practice...
> Based on what you say layer 2 frames would traverse the VM Network bridge
> and reach VyOS vnic, which they do not.
> Layer 2 frames are dropped after leaving the VM and before reaching the
> VyOS vnic.
> In theory if the VM bridge did not know where they should be forwarded it
> should broadcast them to all attached ports, which again it is not been
> done.
> So i am not sure if it is a bug, or a feature...
>

This works very reliably.
To check the oVirt networking related part, I tried the following setup:

VM1 <-vlan4->VM0<->ovirtmgmt<->dhcpserver/gateway

With a bridge on VM0 which connects the interfaces connected to vlan4 and
ovirtmgmt.
VM0 was the "CentOS 8 test image v20191009 for x86_64 (280f3e8)"
from ovirt-image-repository.
I installed cockpit in VM0 and added a bridge on cockpit web UI over the
two virtual NICs on VM0.

VM1 was able to get an IP address via DHCP and ping through the gateway to
the outside world.

Are you able to replicate this as a first step to isolate the problem?



> >
> >
> > As I wrote above, layer 2 tunneling from one VM to another should work.
> > Are you force to extend the network on layer 2? If not,
> > two VMs connected by a tunnel or a VPN might be more straight and would
> > even limit layer 2 broadcasts.
> I agree Layer 3 would be the best way forward but we need layer 2
> extension since the firewalls require it for high availability as well and
> we need pcsd VIPs attached to monitored services to have high availability.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/WFV4A4YIDL7TFH2DQ3HYMO6UK5DLIIQT/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/YS4OZLQYA23DVQJSOTCKJTRZGWCQCKMW/


[ovirt-users] Re: ovirt vdsm and networking

2019-12-13 Thread Dominik Holler
On Fri, Dec 13, 2019 at 8:41 AM  wrote:

> Hi,
>
> We are running CentOS and ovirt 4.3.4. We currently have four nodes and
> have set up the networks as follows:
>
> ovirtmanagmeent network - set up as a tagged vlan with a static IP
> SAN network - set up as a tagged vlan with a static IP
> student network - set up as a tagged vlan
> fw network - set up as a tagged vlan
>
> The ovirtmanagement and SAN networks were configured on the CentOS boxes
> during after installing CentOS and before adding the nodes as hosts. The
> student network and the fw network were configured through the ovirt admin
> panel. However, because of this, the student network is not assigned a
> static IP on the nodes and serves the VM's using the DHCP on the firewall.
> The ovirt management network is set as the display network and every time I
> try to change that to the student network, ovirt admin panel tells me that
> I can't because there is no IP address assigned to the student network
> vlan. I tried using ip addr add to add a static IP on the one CentOS node,
> but this does not get picked up by ovirt and of course ovirt controls the
> actual vlan files on the CentOS box through VDSM, so any changes I make
> there will likely just be overwritten.
>
> So, my question is, should I stop VDSM, add the IP to the vlan files on
> the CentOS nodes and then restart VDSM or is there a proper way of solving
> this? I need the Display Network to be set to the student network.
>
>
Please use oVirt Engine to manage the network config of the host.
In the web UI, go to
Compute -> Hosts -> hostname -> Network Interfaces -> Setup Host
Networks ->  click the pencil icon to open the Edit Network window

Did this solve the problem?


> Thank you for any help.
>
> Kim
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/O5GJRNIPOXJLZ2KEPGZJZZNG57OTTLGI/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/JKBLKAPJQTD6ZX2MDJZIWBM2OXWAH6JS/


[ovirt-users] Re: Ovirt OVN help needed

2019-12-13 Thread Dominik Holler
On Fri, Dec 13, 2019 at 5:51 AM Strahil  wrote:

> Hi Dominik, All,
>
> I've checked '
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/W6U4XJHNMYMD3WIXDCPGOXLW6DFMCYIM/'
> and the user managed to clear up and start over.
>
> I have removed the ovn-external-provider  from UI, but I forgot to copy
> the data from the fields.
>
> Do you know any refference guide (or any tips & tricks) for adding OVN ?
>

The ovirt-provider-ovn entity can be added to oVirt Engine as a new
provider with
Type: External Network Provider
Network Plugin: oVirt Network Provider for OVN
Provider URL: https://YOUR_ENGINE_FQDNt:9696
Username: admin@internal
Password: admin@interal password
Host Name: YOUR_ENGINE_FQDN
API Port: 35357
API Version: v2.0

Is this the information you need?


> Thanks in advance.
>
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 20:49, Strahil  wrote:
>
> Hi Dominik,
>
> Thanks for the reply.
>
> Sadly the openstack module is missing on the engine and I have to figure
> it out.
>
> Can't I just undeploy the ovn and then redeploy it back ?
>
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 09:32, Dominik Holler  wrote:
>
> The cleanest way to clean up is to remove all entities on the OpenStack
> Network API on ovirt-provider-ovn, e.g. by something like
>
> https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
> This should work, if not, please report a bug.
>
> To bypass the ovirt-provider-ovn, which is not recommended and might end
> in an inconsistent state, you could use ovn-nbctl .
>
>
>
> On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov 
> wrote:
>
> Hi Community,
>
> can someone hint me how to get rid of some ports? I just want to 'reset'
> my ovn setup.
>
> Here is what I have so far:
>
> [root@ovirt1 openvswitch]# ovs-vsctl list interface
> _uuid   : be89c214-10e4-4a97-a9eb-1b82bc433a24
> admin_state : up
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : up
> lldp: {}
> mac : []
> mac_in_use  : "7a:7d:1d:a7:43:1d"
> mtu : []
> mtu_request : []
> name: "ovn-25cc77-0"
> ofport  : 6
> ofport_request  : []
> options : {csum="true", key=flow, remote_ip="192.168.1.64"}
> other_config: {}
> statistics  : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status  : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
> _uuid   : ec6a6688-e5d6-4346-ac47-ece1b8379440
> admin_state : down
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 13
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : down
> lldp: {}
> mac : []
> mac_in_use  : "66:36:dd:63:dc:48"
> mtu : 1500
> mtu_request : []
> name: br-int
> ofport  : 65534
> ofport_request  : []
> options : {}
> other_config: {}
> statistics  : {collisions=0, rx_bytes=0, rx_crc_err=0,
> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
> tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
> status  : {driver_name=openvswitch}
> type: internal
>
> _uuid   : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af
> admin_state : up
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex 

[ovirt-users] Re: Ovirt OVN help needed

2019-12-12 Thread Dominik Holler
On Thu, Dec 12, 2019 at 7:50 PM Strahil  wrote:

> Hi Dominik,
>
> Thanks for the reply.
>
> Sadly the openstack module is missing on the engine and I have to figure
> it out.
>

The module can be installed by 'pip install openstacksdk', please find an
example in
https://github.com/oVirt/ovirt-system-tests/blob/master/network-suite-master/control.sh#L20


> Can't I just undeploy the ovn and then redeploy it back ?
>

No idea, I never tried this.
In doubt, you can deleter one entity after another via ovn-nbctl.



> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 09:32, Dominik Holler  wrote:
>
> The cleanest way to clean up is to remove all entities on the OpenStack
> Network API on ovirt-provider-ovn, e.g. by something like
>
> https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
> This should work, if not, please report a bug.
>
> To bypass the ovirt-provider-ovn, which is not recommended and might end
> in an inconsistent state, you could use ovn-nbctl .
>
>
>
> On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov 
> wrote:
>
> Hi Community,
>
> can someone hint me how to get rid of some ports? I just want to 'reset'
> my ovn setup.
>
> Here is what I have so far:
>
> [root@ovirt1 openvswitch]# ovs-vsctl list interface
> _uuid   : be89c214-10e4-4a97-a9eb-1b82bc433a24
> admin_state : up
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : up
> lldp: {}
> mac : []
> mac_in_use  : "7a:7d:1d:a7:43:1d"
> mtu : []
> mtu_request : []
> name: "ovn-25cc77-0"
> ofport  : 6
> ofport_request  : []
> options : {csum="true", key=flow, remote_ip="192.168.1.64"}
> other_config: {}
> statistics  : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status  : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
> _uuid   : ec6a6688-e5d6-4346-ac47-ece1b8379440
> admin_state : down
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 13
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : down
> lldp: {}
> mac : []
> mac_in_use  : "66:36:dd:63:dc:48"
> mtu : 1500
> mtu_request : []
> name: br-int
> ofport  : 65534
> ofport_request  : []
> options : {}
> other_config: {}
> statistics  : {collisions=0, rx_bytes=0, rx_crc_err=0,
> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
> tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
> status  : {driver_name=openvswitch}
> type: internal
>
> _uuid   : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af
> admin_state : up
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : up
> lldp: {}
> mac : []
> mac_in_use  : "1a:85:d1:d9:e2:a5"
> mtu : []
> mtu_request : []
> name: "ovn-566849-0"
> ofport  : 5
> ofport_request  : []
> options : {csum="true"

[ovirt-users] Re: Cannot forward traffic through VXLAN

2019-12-12 Thread Dominik Holler
On Thu, Dec 12, 2019 at 4:27 PM  wrote:

> > On Thu, Dec 12, 2019 at 11:29 AM  >
> >
> > I see.
> > This will create an external OVN network.
> > As far as I know, OVN networks do not allow mac spoofing, even if port
> > security is disabled.
> >
> I have installed the vdsm hook for allow both promiscuous and mac-spoofing
> and have the same experience.
> So it is safe to assume that this cannot be supported in ovirt?
>


Not external logical networks, with vNIC profiles, have no network filter
during the VM is started (or the vNIC is hotplugged),
allows any MAC address. This works without any hook required.
In most simple flow for a lab would be to remove the network filter from
ovirtmgmt, attach ovirtmgmt to a VM and boot the VM.



> >
> > Are you able to use physical networks (oVirt logical network with VM
> > networking, optional VLAN tag, but not external)
> > to connect the oVirt VMs?
> >
> I can connect to VMs through the internet and IPSEC, but i wanted to
> extend them.
> Do you know of any other way where i can extend on VM network from ovirt
> to another hypervisor?
>

As I wrote above, layer 2 tunneling from one VM to another should work.
Are you force to extend the network on layer 2? If not,
two VMs connected by a tunnel or a VPN might be more straight and would
even limit layer 2 broadcasts.


> Any idea will help.
>
> Appreciate the till now assistance.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/PPOE54V2SXWZUNS5WFPH4E6RQHQHKUDP/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/5TPQLN2D7H3L5VGHXFQ3L624PWNU6SIE/


[ovirt-users] Re: Cannot forward traffic through VXLAN

2019-12-12 Thread Dominik Holler
On Thu, Dec 12, 2019 at 11:29 AM  wrote:

> > On Wed, Dec 11, 2019 at 5:31 PM  >
> > Is VyOS installed on the host, or in a VM?
> >
> VyOS is installed on the ovirt node
> >
> >
> > Does this mean that the VyOS VM on oVirt should forward layer 2 traffic
> to
> > the VyOS VM on proxmox?
> > Is there a way to share a VLAN? (This would avoid additional tunneling.)
> > Can you please share some details?
> >
> VLAN approach is not feasible unfortunatelly.
> VyOS VM on oVirt should forward Layer 2 traffic over ovirtmgmt network.
> So from oVirt's perspective there is no tunneling.
> >
> >
> > If VyOS is a VM on oVirt, network filtering should be disabled on the
> vNIC
> > profile which sends and
> > receives the unencapsulated traffic, before the oVirt VM is booted.
> >
> I have disabled all filters on the VM Network by selecting Network Port
> Security: Disabled
> >
> >
> > Don't understand.
> I have created a VM Network with no filters on ovirt named auth_net with
> the following parameters:
> 1. VM Network, check
> 2. MTU, custom 2000
> 3. Create on external provider, check
> 3a. External provider: ovirt-provider-ovn
>

I see.
This will create an external OVN network.
As far as I know, OVN networks do not allow mac spoofing, even if port
security is disabled.

Are you able to use physical networks (oVirt logical network with VM
networking, optional VLAN tag, but not external)
to connect the oVirt VMs?



> 3b. Network Port Security: Disabled
>
> This is done as to allow me to attach VMs to this network.
>
> I have attached 3 VMs on this VM Network.
> A firewall with IP e.g. 10.0.0.1
> The VyOS VM
> An LDAP VM with IP e.g. 10.0.0.5
>
> The VyOS VM is attached to the auth_net with no IP address and with L2TPv3
> via ovirtmgmt as to get the VM network Layer 2 traffic and forward it to
> the proxmox network through the VyOS routers.
> Even though i have not created any network filters traffic is dropped
> before reaching VyOS VM from the LDAP Auth server.
> TCPDUMP on the LDAP VM shows traffic leaving the LDAP VM.
> TCPDUMP on the VyOS VM does not show traffic reaching the vnic.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/BOEK5LTE6CMYTUKUXDJ7ZM6HAI4YOCFR/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/4KETATDBPV352XNGTYV4BJ3GNNLKMVDY/


[ovirt-users] Re: encrypted GENEVE traffic

2019-12-12 Thread Dominik Holler
On Thu, Dec 12, 2019 at 12:20 PM Pavel Nakonechnyi 
wrote:

> On Thursday, 12 December 2019 10:23:28 CET Dominik Holler wrote:
> > On Thu, Dec 12, 2019 at 10:06 AM Pavel Nakonechnyi 
> > > Could you direct me to the part of oVirt system which handles OVS
> tunnels
> > > creation?
> > >
> > > It seems that at some point oVirt issues a command similar to the
> > > following
> > > one:
> > >
> > > `ovs-vsctl add-port br-int ovn-xxx-0 -- set interface ovn-xxx-0 \
> > >
> > >  type=geneve options:csum=true key=flow options:remote_ip=1.1.1.1`
> > >
> > > I was not able to identify were the corresponding code is located. :(
> > >
> > > When I tried to do a bad thing, manual deletion of such tunnel
> interface:
> > >
> > > `ovs-vsctl del-port br-int ovn-xxx-0`
> > >
> > > it was immediately re-created or just was not deleted.. Still have to
> > > experiment with that..
> >
> > Yes, for VM OVS networking, oVirt does not use OVS directly, instead, OVN
> > is doing the work.
> >
> > During adding or reinstalling a host,
> >
> https://github.com/oVirt/ovirt-engine/tree/ovirt-engine-4.3/packaging/playbo
> > oks/roles/ovirt-provider-ovn-driver is triggered.
> > This triggers
> >
> https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/vdsm_tool/ovn
> > _config.py and
> >
> https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/scripts/setup
> > _ovn_controller.sh while the latter is really doing the work.
> >
> > I expect that this file has to be extended by the call from
> >
> http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/#configuring-ovn-i
> > psec
> >
> > Maybe the
> >
> http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/#enabling-ovn-ipse
> > c can be done in a first try manually.
> >
> > The weak point I expect is that the package  openvswitch-ipsec might be
> > missing in our repos, details in
> > http://docs.openvswitch.org/en/stable/tutorials/ipsec/#install-ovs-ipsec
> .
> >
> > In a first step, this package can be built manually.
> >
> > Any feedback on this would be very helpful, thanks for having a look!
> >
>
> Thank you, this was helpful. However, I am stuck with understanding how
> "tunnel" interfaces are created.
>
> For instance, if we execute `ovs-vsctl show` on some host, we get:
>
> ee590052-2dde-4635-94e0-a116511b9ba2
> Bridge br-int
> fail_mode: secure
> Port "ovn-6bb62c-0"
> Interface "ovn-6bb62c-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="1.1.1.2"}
> ...
>
> This relates to Southbound database stored on the engine, see the
> following
> excerpt:
>
> "Encap": {
> 
> "6d4b8487-7256-44f9-87b3-c885c7f4352f": {
> "ip": "172.18.53.202",
> "chassis_name": "6bb62cd8-6f97-47dd-8f0f-6bd1dbb73fd0",
> "options": ["map", [
> ["csum", "true"]
> ]],
> "type": "geneve"
> }
> ...
> "Chassis": {
> ...
> "8e3bac24-ef13-476c-a79b-e2c3f5e3b152": {
> "name": "6bb62cd8-6f97-47dd-8f0f-6bd1dbb73fd0",
> "hostname": "ovirt-h2.example.com",
> "encaps": ["uuid", "6d4b8487-7256-44f9-87b3-c885c7f4352f"],
> "external_ids": ["map", [
> ["datapath-type", ""],
> ["iface-types",
>
> "erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan"],
> ["ovn-bridge-mappings", ""]
> ]]
> }
> ...
>
> What creates all these chassis, mappings, encapsulations?


This is all done by OVN.
On every host runs the ovn-controller, which configures the tunnels
according to
the information he gets from ovn south db.
Please find a good entry in
http://www.openvswitch.org/support/dist-docs/ovn-architecture.7.html
but all documentation about OVN should work.


> I believe that it
> should be done by "ovirt-provider-ovn" (triggered by something from
> engine),
>

ovirt-provider-ovn is just a mapper from OpenStack Network API to OVN.
The talk in
https://archive.fosdem.org/2018/schedule/event/vai_leveraging_sdn_for_virtualization/
especially slide 26 explains more details.
You are welcome to ask more questions on this list.


> however, I was not able to find any clues where in particular it is
> implemented...
>
> Once this is understood, it will be possible to consider altering the
> corresponding code to include ipsec-related options.
>
>
This would be amazing!


>
>
> --
> WBR, Pavel
>
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/YN2OH5P5JXCQL5XGIEYZHFODJVPNAQ6T/


[ovirt-users] Re: encrypted GENEVE traffic

2019-12-12 Thread Dominik Holler
On Thu, Dec 12, 2019 at 10:06 AM Pavel Nakonechnyi 
wrote:

> On Wednesday, 11 December 2019 16:37:50 CET Dominik Holler wrote:
> > On Wed, Dec 11, 2019 at 1:21 PM Pavel Nakonechnyi 
> >
>
> > > Are there plans to introduce such support? (or explicitly not to..)
> >
> > The feature is tracked in
> > https://bugzilla.redhat.com/1782056
> >
> > If you would comment on the bug about your use case and why the feature
> > would be helpful in your scenario, this might help to push the feature.
> >
>
> Great, thanks, added a comment.
>
>
Thanks for helping to adjust oVirt!


>
> > > Is it possible to somehow manually configure such tunneling for
> existing
> > > virtual networks? (even in a limited way)
> >
> > I would be interested to know, how far we are away from the flow
> described
> > in
> > http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/ .
> > I expect that the openvswitch-ipsec package is missing. Any input on this
> > is welcome.
> >
>
> Could you direct me to the part of oVirt system which handles OVS tunnels
> creation?
>
> It seems that at some point oVirt issues a command similar to the
> following
> one:
>
> `ovs-vsctl add-port br-int ovn-xxx-0 -- set interface ovn-xxx-0 \
>  type=geneve options:csum=true key=flow options:remote_ip=1.1.1.1`
>
> I was not able to identify were the corresponding code is located. :(
>
> When I tried to do a bad thing, manual deletion of such tunnel interface:
>
> `ovs-vsctl del-port br-int ovn-xxx-0`
>
> it was immediately re-created or just was not deleted.. Still have to
> experiment with that..
>
>

Yes, for VM OVS networking, oVirt does not use OVS directly, instead, OVN
is doing the work.

During adding or reinstalling a host,
https://github.com/oVirt/ovirt-engine/tree/ovirt-engine-4.3/packaging/playbooks/roles/ovirt-provider-ovn-driver
is triggered.
This triggers
https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/vdsm_tool/ovn_config.py
and
https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/scripts/setup_ovn_controller.sh
while the latter is really doing the work.

I expect that this file has to be extended by the call from
http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/#configuring-ovn-ipsec

Maybe the
http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/#enabling-ovn-ipsec
can be done in a first try manually.

The weak point I expect is that the package  openvswitch-ipsec might be
missing in our repos, details in
http://docs.openvswitch.org/en/stable/tutorials/ipsec/#install-ovs-ipsec .

In a first step, this package can be built manually.

Any feedback on this would be very helpful, thanks for having a look!


>
> --
> WBR, Pavel
>  +32478910884
>
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/XSPAI2YDBXBEYB43P4EIAZMQPRDBTZY2/


[ovirt-users] Re: Cannot forward traffic through VXLAN

2019-12-11 Thread Dominik Holler
On Wed, Dec 11, 2019 at 5:31 PM  wrote:

> We currently have 2 bare metals.
> One holds the ovirt and the other proxmox.
>
> As to enable high availability and config sync on the proxmox hosted VMs
> we have deployed VyOS on both hyper-visors.
>
>
Is VyOS installed on the host, or in a VM?


> We then use L2TPv3 as to extend VM networks from proxmox to ovirt and vice
> versa.
>

Does this mean that the VyOS VM on oVirt should forward layer 2 traffic to
the VyOS VM on proxmox?
Is there a way to share a VLAN? (This would avoid additional tunneling.)
Can you please share some details?



> When that was finalized and all VMs were activated in ovirt we would
> delete proxmox and deploy ovirt and re-do the same think as to re-enable VM
> high availability.
>
> The issue is that VM Networks drop traffic towards the VyOS VM even
> through we have enable mac-spoofing and promiscuous on the VM custom
> properties.
>
>
If VyOS is a VM on oVirt, network filtering should be disabled on the vNIC
profile which sends and
receives the unencapsulated traffic, before the oVirt VM is booted.


> The VM Networks must drop frames for destination MAC addresses not
> directly hosted on it and i don't know how to disable/bypass that.
>

Don't understand.


> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/T6FKORHF3NCVWQFICPFSOR3OB3GOSDSY/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/NGOTA2HT7LVEJUHFKAHL2ZB36WVAS74P/


[ovirt-users] Re: Ovirt OVN help needed

2019-12-11 Thread Dominik Holler
The cleanest way to clean up is to remove all entities on the OpenStack
Network API on ovirt-provider-ovn, e.g. by something like
https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
This should work, if not, please report a bug.

To bypass the ovirt-provider-ovn, which is not recommended and might end in
an inconsistent state, you could use ovn-nbctl .



On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov 
wrote:

> Hi Community,
>
> can someone hint me how to get rid of some ports? I just want to 'reset'
> my ovn setup.
>
> Here is what I have so far:
>
> [root@ovirt1 openvswitch]# ovs-vsctl list interface
> _uuid   : be89c214-10e4-4a97-a9eb-1b82bc433a24
> admin_state : up
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : up
> lldp: {}
> mac : []
> mac_in_use  : "7a:7d:1d:a7:43:1d"
> mtu : []
> mtu_request : []
> name: "ovn-25cc77-0"
> ofport  : 6
> ofport_request  : []
> options : {csum="true", key=flow, remote_ip="192.168.1.64"}
> other_config: {}
> statistics  : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status  : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
> _uuid   : ec6a6688-e5d6-4346-ac47-ece1b8379440
> admin_state : down
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 13
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : down
> lldp: {}
> mac : []
> mac_in_use  : "66:36:dd:63:dc:48"
> mtu : 1500
> mtu_request : []
> name: br-int
> ofport  : 65534
> ofport_request  : []
> options : {}
> other_config: {}
> statistics  : {collisions=0, rx_bytes=0, rx_crc_err=0,
> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
> tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
> status  : {driver_name=openvswitch}
> type: internal
>
> _uuid   : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af
> admin_state : up
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : up
> lldp: {}
> mac : []
> mac_in_use  : "1a:85:d1:d9:e2:a5"
> mtu : []
> mtu_request : []
> name: "ovn-566849-0"
> ofport  : 5
> ofport_request  : []
> options : {csum="true", key=flow, remote_ip="192.168.1.41"}
> other_config: {}
> statistics  : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status  : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
>
> When I try to remove a port - it never ends (just hanging):
>
> [root@ovirt1 openvswitch]# ovs-vsctl --dry-run del-port br-int
> ovn-25cc77-0
> In journal  I see only this:
> дек 12 04:13:57 ovirt1.localdomain ovs-vsctl[22030]:
> ovs|1|vsctl|INFO|Called as ovs-vsctl --dry-run del-port br-int
> ovn-25cc77-0
>
> The stranger part to me is the log output:
>
> [root@ovirt1 openvswitch]# grep ovn-25cc77-0 /var/log/openvswitch/*.log
> /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:26:28.642Z|00032|bridge|INFO|bridge
> br-int: added interface ovn-25cc77-0 on port 14
> /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:45:15.646Z|00113|bridge|INFO|bridge
> br-int: deleted interface ovn-25cc77-0 on port 14
> /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:45:15.861Z|00116|bridge|INFO|bridge
> br-int: added interface ovn-25cc77-0 on port 2
> 

[ovirt-users] Re: Cannot forward traffic through VXLAN

2019-12-11 Thread Dominik Holler
On Wed, Dec 11, 2019 at 12:12 PM  wrote:

> Hi all
>
> I have a VM network created with some hosts and I have included a vyos
> router acting as a Layer 2 extension to another hypervisor through VXLAN.
>
>
This sounds interesting, but might be not supported by oVir. Can you share
details?

What is your motivation to do this?
Would the internal OVN networking work for you, too?


> I can see traffic reaching VMs from the other hypervisor to the ovirt
> hosted VMs.
> I can see traffic leaving the VMs hosted on the ovirt hypervisor.
> However, i do not see return traffic reaching the vyos VXLAN hosted on
> ovirt.
>
> I believe the VM network drops return traffic based on the destination MAC
> address.
>
> However, i have created the VM Network with security disabled.
>
> Can you please assist on how to troubleshoot?
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/Z3AVFZRF3CJTKIASTFGNE6KRTGOKZEIE/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/OELS7GH7ZI2OX5QJS3KB3QDZ67IE6H7B/


[ovirt-users] Re: encrypted GENEVE traffic

2019-12-11 Thread Dominik Holler
On Wed, Dec 11, 2019 at 1:21 PM Pavel Nakonechnyi 
wrote:

> Dear oVirt Community,
>
> From my understanding oVirt does not support Open vSwitch IPSEC tunneling
> for GENEVE traffic (which is described on pages
> http://docs.openvswitch.org/en/latest/howto/ipsec/ and
> http://docs.openvswitch.org/en/latest/tutorials/ipsec/).
>
>
Correct, currently this is not supported.


> Are there plans to introduce such support? (or explicitly not to..)
>
>
The feature is tracked in
https://bugzilla.redhat.com/1782056

If you would comment on the bug about your use case and why the feature
would be helpful in your scenario, this might help to push the feature.


> Is it possible to somehow manually configure such tunneling for existing
> virtual networks? (even in a limited way)
>
>
I would be interested to know, how far we are away from the flow described
in
http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/ .
I expect that the openvswitch-ipsec package is missing. Any input on this
is welcome.


> Alternatively, is it possible to deploy oVirt on top of the tunneled (i.e.
> via VXLAN, IPSec) interfaces? This will allow to encrypt all management
> traffic.
>
> Such requirement arises when using oVirt deployment on third-party
> premises with untrusted network.
>
> Thank in advance for any clarifications. :)
>
> --
> WBR, Pavel
>  +32478910884
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/PBLO4AQYZQQM2PO5IIFHEFJHPR6DZR63/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/CSWWCC2KTBG3R5AFPUPRM7KF3IOHLH2N/


[ovirt-users] Re: Issue in setting up

2019-12-09 Thread Dominik Holler
On Sun, Dec 8, 2019 at 8:05 PM Johns  wrote:

> Hi all,
>
> I just tried to use oVirt in multi-server, Manager in one VM and Host in a
> dedicated machine, every time I try to attach host I get this error.
>
> networks, the following networks are missing on host: 'ovirtmgmt'
>
> I have created a bridge but no luck , please help
>

Is there an error shown in the Administration Portal?
Can you please share the relevant part of engine.log (around
HostSetupNetworksCommand) and vdsm.log (around setupNetworks) and the
corresponding part of supervdsm.log?

If there is no HostSetupNetworksCommand in the engine.log, can you please
check
/var/log/ovirt-engine/host-deploy/
for helpful hints?


> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/ABNLG6YLUPJAAU26PCW46HWDX4FCZBHC/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/NJ3X2H3VKO3JXEWSJEA5M53NDCDYMYJA/


[ovirt-users] Re: VLANs with one NIC in ovirt

2019-12-06 Thread Dominik Holler
On Fri, Dec 6, 2019 at 3:44 PM  wrote:

> Hi Joseph, I did that but the problem is that I have an ovirtmgmt network
> by default and another network that is a VLAN, VLAN 5 exactly. But VMs that
> are in VLAN 5 cannot go outside.


If the route to outside is via untagged network, VLAN 5 should not able to
reach outside.


> Maybe it could be because the traffic on ovirtmgmt is unlabeled and on
> VLAN 5 it is tagged.


Yes.


> Or maybe I have to create some internal route so that VLAN 5 packets can
> exit on ovirtmgmt.


This would break the isolation between VLAN5 and ovirtmgmt.
Do you want to separate VLAN5 from ovirtmgmt?


> I don't know what exactly happens and I would like to help me.
>

Maybe you know already what happens, I just did not get your intention.

You can have separate layer 2 networks using VLANs, which are isolated.
They could be connected via a router, which can be a physical device, a
machine outside oVirt or
even an oVirt VM which has a vNIC for each network.

Most simple would be to connect the VMs to ovirtmgmt, but this way the VMs
could harm the physical hosts.



> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/3PG5CRONEFZYA6DSMCYTY3WJJ5DTSSX5/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/LX6C7Q4AWSUZ2STJSMCUIXSSHR2GGZBH/


  1   2   3   >