[ovirt-devel] Re: ssl error during host install

[Martin Necas]

Hi Vojtech,

could you please provide
- on host:
cat /etc/pki/vdsm/certs/cacert.pem
- on engine:
rpm -qa "*ansible-runner*"
cat /etc/ansible-runner-service/config.yaml

My guess is that in the ovirt-release44-pre is missing this patch [1]
but you have the newest ansible-runner.

[1] https://gerrit.ovirt.org/#/c/108532/

Martin Necas

On Tue, May 19, 2020 at 12:53 AM Vojtech Juranek 
wrote:

> Hi,
> I'm getting following SSL error when adding new host:
>
> engine:
>
> [...]
> 2020-05-18 18:28:35,530-04 WARN
> [org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable]
> (EE-ManagedThreadFactory-engine-Thread-42) [762c711c] Retry failed
> 2020-05-18 18:28:39,033-04 WARN
> [org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable]
> (EE-ManagedThreadFactory-engine-Thread-43) [762c711c] Retry failed
> 2020-05-18 18:28:39,033-04 ERROR
> [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand]
> (EE-ManagedThreadFactory-engine-Thread-3) [762c711c] Host installation
> failed for host 'ab082e77-315c-4cfe-8188-11fbee94c2b8', 'fc30-glance':
> Network error during communication with the host
>
> host (vdsm log):
>
> 2020-05-18 18:26:36,963-0400 ERROR (Reactor thread) [vds.dispatcher]
> uncaptured python exception, closing channel
>  52428, 0, 0) at 0x7f9f8c7e8d30> (:[X509] no
> certificate or crl found (_ssl.c:4053)
> [/usr/lib64/python3.7/asyncore.py|readwrite|110]
> [/usr/lib64/python3.7/asyncore.py|handle_write_event|441]
> [/usr/lib/python3.7/site-packages/yajsonrpc/betterAsyncore.py|handle_write|75]
> [/usr/lib/python3.7/site-packages/yajsonrpc/betterAsyncore.py|_delegate_call|173]
> [/usr/lib/python3.7/site-packages/vdsm/sslutils.py|handle_write|190]
> [/usr/lib/python3.7/site-packages/vdsm/sslutils.py|_handle_io|194]
> [/usr/lib/python3.7/site-packages/vdsm/sslutils.py|_set_up_socket|154])
> (betterAsyncore:184)
>
> Any idea what's wrong and/or how to fix it?
>
> Both engine and host are on FC30, host is installed from standard
> ovirt-release44-pre
> repo and engine is dev build of latest engine master with glance API v2
> patches [1].
>
> Thanks
> Vojta
>
> [1] https://gerrit.ovirt.org/#/q/topic
> :"Image+Service+API+v2"___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-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/devel@ovirt.org/message/VSM7HZN5EB27ADN6NJFQMN32Y42ZJESO/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/6VFCG2SJTBOGRXDHZUOCK2BCSAXVIBDY/

[ovirt-devel] ssl error during host install

[Vojtech Juranek]

Hi,
I'm getting following SSL error when adding new host:

engine:

[...]
2020-05-18 18:28:35,530-04 WARN  
[org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable] 
(EE-ManagedThreadFactory-engine-Thread-42) [762c711c] Retry failed
2020-05-18 18:28:39,033-04 WARN  
[org.ovirt.vdsm.jsonrpc.client.utils.retry.Retryable] 
(EE-ManagedThreadFactory-engine-Thread-43) [762c711c] Retry failed
2020-05-18 18:28:39,033-04 ERROR 
[org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] 
(EE-ManagedThreadFactory-engine-Thread-3) [762c711c] Host installation failed 
for host 'ab082e77-315c-4cfe-8188-11fbee94c2b8', 'fc30-glance': Network error 
during communication with the host

host (vdsm log):

2020-05-18 18:26:36,963-0400 ERROR (Reactor thread) [vds.dispatcher] uncaptured 
python exception, closing channel  (:[X509] no certificate or crl found (_ssl.c:4053) 
[/usr/lib64/python3.7/asyncore.py|readwrite|110] 
[/usr/lib64/python3.7/asyncore.py|handle_write_event|441] 
[/usr/lib/python3.7/site-packages/yajsonrpc/betterAsyncore.py|handle_write|75] 
[/usr/lib/python3.7/site-packages/yajsonrpc/betterAsyncore.py|_delegate_call|173]
 [/usr/lib/python3.7/site-packages/vdsm/sslutils.py|handle_write|190] 
[/usr/lib/python3.7/site-packages/vdsm/sslutils.py|_handle_io|194] 
[/usr/lib/python3.7/site-packages/vdsm/sslutils.py|_set_up_socket|154]) 
(betterAsyncore:184)

Any idea what's wrong and/or how to fix it?

Both engine and host are on FC30, host is installed from standard 
ovirt-release44-pre 
repo and engine is dev build of latest engine master with glance API v2 patches 
[1].

Thanks
Vojta

[1] https://gerrit.ovirt.org/#/q/topic:"Image+Service+API+v2;

signature.asc
Description: This is a digitally signed message part.
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/VSM7HZN5EB27ADN6NJFQMN32Y42ZJESO/

[ovirt-devel] Re: OST CI basic suite failure

[Michal Skrivanek]

> On 18 May 2020, at 11:59, Galit Rosenthal  wrote:
> 
> This is from last night
> https://jenkins.ovirt.org/job/ovirt-system-tests_compat-4.3-suite-master/443/artifact/exported-artifacts/test_logs/compat-4.3-suite-master/post-004_basic_sanity_pytest.py/lago-compat-4-3-suite-master-engine/_var_log/ovirt-engine/engine.log
>  
> 
> 

How does compat-4.3-suite-master work?
i.e. what is the actual engine and host version and which exact 002_bootstrap 
file is being used?


> 2020-05-17 21:43:46,410-04 ERROR 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (ForkJoinPool-1-worker-17) [1769ac4b] 
> EVENT_ID: VM_DOWN_ERROR(119), VM vm2 is down with error. Exit message: XML 
> error: Invalid PCI address :02:01.0. slot must be <= 0.
> 
> 
> On Mon, May 18, 2020 at 11:21 AM Yedidyah Bar David  > wrote:
> On Mon, May 18, 2020 at 10:47 AM Steven Rosenberg  > wrote:
> >
> > Dear Didi,
> >
> > We had issues with this previously when the Bios Type and Emulation Machine 
> > chipsets are not compatible, mixing Q35 Bios Types with i440fx Emulation 
> > Machine Types for example. We fixed the defaults and adjusted the OST tests 
> > accordingly. Maybe something else changed that brought the issue back.
> >
> 
> OK. We do not have the logs anymore to check which version it ran.
> Artem - I suggest to just rebase and try again, and ping if it fails again.
> 
> Good luck and best regards,
> 
> > With Best Regards.
> >
> > Steven.
> >
> > On Sun, May 17, 2020 at 4:36 PM Yedidyah Bar David  > > wrote:
> >>
> >> On Fri, May 15, 2020 at 4:24 PM Artem Hrechanychenko
> >> mailto:ahrec...@redhat.com>> wrote:
> >> >
> >> > Hi,
> >> > I'm getting failure on ci check for my patch for network suite changes
> >> > https://gerrit.ovirt.org/#/c/108317/ 
> >> > 
> >> >
> >> > CI failures
> >> > https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/9350/
> >> >  
> >> > 
> >> >
> >> > My patch does not change the basic-suite master and local run passed 
> >> > locally. Does anybody know or get something similar ?
> >>
> >> engine.log has:
> >>
> >> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/9350/artifact/check-patch.compat-4.3_suite_master.el7.x86_64/test_logs/compat-4.3-suite-master/post-004_basic_sanity_pytest.py/lago-compat-4-3-suite-master-engine/_var_log/ovirt-engine/
> >>  
> >> 
> >>
> >> 2020-05-15 08:38:25,062-04 ERROR
> >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> >> (ForkJoinPool-1-worker-23) [2e5b2649] EVENT_ID: VM_DOWN_ERROR(119), VM
> >> vm2 is down with error. Exit message: XML error: Invalid PCI address
> >> :02:01.0. slot must be <= 0.
> >>
> >> Perhaps it's this, or a similar/related one (found simply by searching
> >> for "Invalid PCI address"):
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1770697 
> >> 
> >>
> >> Best regards,
> >> --
> >> Didi
> >> ___
> >> Devel mailing list -- devel@ovirt.org 
> >> To unsubscribe send an email to devel-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/devel@ovirt.org/message/M367YCTWZLTCTUTV745QCR6R4ON7RKHY/
> >>  
> >> 
> 
> 
> 
> -- 
> Didi
> 
> 
> 
> -- 
> 
> GALIT ROSENTHAL
> SOFTWARE ENGINEER
> Red Hat 
> 
>  
> ga...@redhat.com T: 972-9-7692230 
> 
> 
>  
> ___
> Devel mailing list -- devel@ovirt.org 
> To unsubscribe send an email to devel-le...@ovirt.org 
> 
> Privacy Statement: https://www.ovirt.org/privacy-policy.html 
> 
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/ 
> 

[ovirt-devel] Re: are we storing the back-end fqdn (like the one used in gluster) in engine?

[Prajith Kesava Prasad]

On Mon, May 18, 2020 at 3:07 PM Yedidyah Bar David  wrote:

> On Mon, May 18, 2020 at 10:12 AM Prajith Kesava Prasad
>  wrote:
> >
> > Hi all,
> > I hope this email finds you well.
> >
> > I just wanted to check, does anyone know if there is a way to get the
> back-end hostname from the ovirt-engine?, (this scenario is most likely to
> occur when an external logical network is attached).
> >
> > I did see a way to get the network interface, with respect to each host.
> like Even though RHV-engine, contains logical network-attached to it, and
> its details (like ipv4). There is no primary key present that could help us
> identify that a network is gluster related or not. so we cannot actually
> get the details, because we won't know if a network is gluster network or
> something else.
> >
> > I just wanted to see, if there is any other way to get the details of
> the backend hostname?
>
> In "backend hostname", do you refer to the storage server?
>

  -->
 No by back-end hostname i mean the corresponding back-end fqdn that each
host has, for e.q:-
   I'm taking gluster as an example here:-
 in a 3 node deployment the front end host (which is visible in the hosts
tab of rhv-engine),
 now if there is an externalgluster_network attached , then inside the host
gluster peer status would show the backend hostname. which is different
from the front end fqdn.


>
> Please note that there is not a "the" storage server. You can have
> more than one.
>
> Nothing, AFAIU, in oVirt, forces storage traffic to go through a
> specific network.
>
> IIUC, once a user supplies some name for the storage server, the hosts
> simply lookup that name and connect to the resolved address.
> So users that want to use a specific network, should make sure the
> resolution points at an IP address on that network.
>
> Please explain exactly what you want to do.
>
> Adding Nir and Eyal from storage.
>
> Best regards,
> --
> Didi
>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/URQLU6RLAPWBNGW2XXE7RUG53ZQMJZRC/

[ovirt-devel] Re: OST CI basic suite failure

[Galit Rosenthal]

This is from last night
https://jenkins.ovirt.org/job/ovirt-system-tests_compat-4.3-suite-master/443/artifact/exported-artifacts/test_logs/compat-4.3-suite-master/post-004_basic_sanity_pytest.py/lago-compat-4-3-suite-master-engine/_var_log/ovirt-engine/engine.log

*2020-05-17 21:43:46,410-04 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(ForkJoinPool-1-worker-17) [1769ac4b] *

*EVENT_ID: VM_DOWN_ERROR(119), VM vm2 is down with error. Exit
message: XML error: Invalid PCI address :02:01.0. slot must be <=
0.
*


On Mon, May 18, 2020 at 11:21 AM Yedidyah Bar David  wrote:

> On Mon, May 18, 2020 at 10:47 AM Steven Rosenberg 
> wrote:
> >
> > Dear Didi,
> >
> > We had issues with this previously when the Bios Type and Emulation
> Machine chipsets are not compatible, mixing Q35 Bios Types with i440fx
> Emulation Machine Types for example. We fixed the defaults and adjusted the
> OST tests accordingly. Maybe something else changed that brought the issue
> back.
> >
>
> OK. We do not have the logs anymore to check which version it ran.
> Artem - I suggest to just rebase and try again, and ping if it fails again.
>
> Good luck and best regards,
>
> > With Best Regards.
> >
> > Steven.
> >
> > On Sun, May 17, 2020 at 4:36 PM Yedidyah Bar David 
> wrote:
> >>
> >> On Fri, May 15, 2020 at 4:24 PM Artem Hrechanychenko
> >>  wrote:
> >> >
> >> > Hi,
> >> > I'm getting failure on ci check for my patch for network suite changes
> >> > https://gerrit.ovirt.org/#/c/108317/
> >> >
> >> > CI failures
> >> >
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/9350/
> >> >
> >> > My patch does not change the basic-suite master and local run passed
> locally. Does anybody know or get something similar ?
> >>
> >> engine.log has:
> >>
> >>
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/9350/artifact/check-patch.compat-4.3_suite_master.el7.x86_64/test_logs/compat-4.3-suite-master/post-004_basic_sanity_pytest.py/lago-compat-4-3-suite-master-engine/_var_log/ovirt-engine/
> >>
> >> 2020-05-15 08:38:25,062-04 ERROR
> >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> >> (ForkJoinPool-1-worker-23) [2e5b2649] EVENT_ID: VM_DOWN_ERROR(119), VM
> >> vm2 is down with error. Exit message: XML error: Invalid PCI address
> >> :02:01.0. slot must be <= 0.
> >>
> >> Perhaps it's this, or a similar/related one (found simply by searching
> >> for "Invalid PCI address"):
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1770697
> >>
> >> Best regards,
> >> --
> >> Didi
> >> ___
> >> Devel mailing list -- devel@ovirt.org
> >> To unsubscribe send an email to devel-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/devel@ovirt.org/message/M367YCTWZLTCTUTV745QCR6R4ON7RKHY/
>
>
>
> --
> Didi
>
>

-- 

GALIT ROSENTHAL

SOFTWARE ENGINEER

Red Hat



ga...@redhat.comT: 972-9-7692230

___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/4YR6KWH2BMWXMAQG7OWHOULH574XBQOB/

[ovirt-devel] Re: are we storing the back-end fqdn (like the one used in gluster) in engine?

[Nir Soffer]

On Mon, May 18, 2020 at 12:37 PM Yedidyah Bar David  wrote:
>
> On Mon, May 18, 2020 at 10:12 AM Prajith Kesava Prasad
>  wrote:
> >
> > Hi all,
> > I hope this email finds you well.
> >
> > I just wanted to check, does anyone know if there is a way to get the 
> > back-end hostname from the ovirt-engine?, (this scenario is most likely to 
> > occur when an external logical network is attached).
> >
> > I did see a way to get the network interface, with respect to each host. 
> > like Even though RHV-engine, contains logical network-attached to it, and 
> > its details (like ipv4). There is no primary key present that could help us 
> > identify that a network is gluster related or not. so we cannot actually 
> > get the details, because we won't know if a network is gluster network or 
> > something else.
> >
> > I just wanted to see, if there is any other way to get the details of the 
> > backend hostname?
>
> In "backend hostname", do you refer to the storage server?
>
> Please note that there is not a "the" storage server. You can have
> more than one.
>
> Nothing, AFAIU, in oVirt, forces storage traffic to go through a
> specific network.

When using iSCSI storage, if multipath is configured correctly
(see DC > iSCSI Multipathing) multipath will use the configured interfaces
to access storage.

> IIUC, once a user supplies some name for the storage server, the hosts
> simply lookup that name and connect to the resolved address.
> So users that want to use a specific network, should make sure the
> resolution points at an IP address on that network.
>
> Please explain exactly what you want to do.
>
> Adding Nir and Eyal from storage.

With file based storage I don't think there is a way to limit access
to particular networks,
except the normal routing rules.

Network folks may help here.

Nir
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/D2KVU5LFGXMWZOET2CAOWGLNSJS3E6DV/

[ovirt-devel] Re: are we storing the back-end fqdn (like the one used in gluster) in engine?

[Yedidyah Bar David]

On Mon, May 18, 2020 at 10:12 AM Prajith Kesava Prasad
 wrote:
>
> Hi all,
> I hope this email finds you well.
>
> I just wanted to check, does anyone know if there is a way to get the 
> back-end hostname from the ovirt-engine?, (this scenario is most likely to 
> occur when an external logical network is attached).
>
> I did see a way to get the network interface, with respect to each host. like 
> Even though RHV-engine, contains logical network-attached to it, and its 
> details (like ipv4). There is no primary key present that could help us 
> identify that a network is gluster related or not. so we cannot actually get 
> the details, because we won't know if a network is gluster network or 
> something else.
>
> I just wanted to see, if there is any other way to get the details of the 
> backend hostname?

In "backend hostname", do you refer to the storage server?

Please note that there is not a "the" storage server. You can have
more than one.

Nothing, AFAIU, in oVirt, forces storage traffic to go through a
specific network.

IIUC, once a user supplies some name for the storage server, the hosts
simply lookup that name and connect to the resolved address.
So users that want to use a specific network, should make sure the
resolution points at an IP address on that network.

Please explain exactly what you want to do.

Adding Nir and Eyal from storage.

Best regards,
-- 
Didi
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/ZQTG76X7D4BBSJI3EXZUPNWA3QTYTFGQ/

[ovirt-devel] Re: OST CI basic suite failure

[Yedidyah Bar David]

On Mon, May 18, 2020 at 10:47 AM Steven Rosenberg  wrote:
>
> Dear Didi,
>
> We had issues with this previously when the Bios Type and Emulation Machine 
> chipsets are not compatible, mixing Q35 Bios Types with i440fx Emulation 
> Machine Types for example. We fixed the defaults and adjusted the OST tests 
> accordingly. Maybe something else changed that brought the issue back.
>

OK. We do not have the logs anymore to check which version it ran.
Artem - I suggest to just rebase and try again, and ping if it fails again.

Good luck and best regards,

> With Best Regards.
>
> Steven.
>
> On Sun, May 17, 2020 at 4:36 PM Yedidyah Bar David  wrote:
>>
>> On Fri, May 15, 2020 at 4:24 PM Artem Hrechanychenko
>>  wrote:
>> >
>> > Hi,
>> > I'm getting failure on ci check for my patch for network suite changes
>> > https://gerrit.ovirt.org/#/c/108317/
>> >
>> > CI failures
>> > https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/9350/
>> >
>> > My patch does not change the basic-suite master and local run passed 
>> > locally. Does anybody know or get something similar ?
>>
>> engine.log has:
>>
>> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/9350/artifact/check-patch.compat-4.3_suite_master.el7.x86_64/test_logs/compat-4.3-suite-master/post-004_basic_sanity_pytest.py/lago-compat-4-3-suite-master-engine/_var_log/ovirt-engine/
>>
>> 2020-05-15 08:38:25,062-04 ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (ForkJoinPool-1-worker-23) [2e5b2649] EVENT_ID: VM_DOWN_ERROR(119), VM
>> vm2 is down with error. Exit message: XML error: Invalid PCI address
>> :02:01.0. slot must be <= 0.
>>
>> Perhaps it's this, or a similar/related one (found simply by searching
>> for "Invalid PCI address"):
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1770697
>>
>> Best regards,
>> --
>> Didi
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-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/devel@ovirt.org/message/M367YCTWZLTCTUTV745QCR6R4ON7RKHY/



-- 
Didi
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/E7D4WW4R354OLMDA24R4CAVKYFGU6T6U/

[ovirt-devel] Re: OST CI basic suite failure

[Steven Rosenberg]

Dear Didi,

We had issues with this previously when the Bios Type and Emulation Machine
chipsets are not compatible, mixing Q35 Bios Types with i440fx Emulation
Machine Types for example. We fixed the defaults and adjusted the OST tests
accordingly. Maybe something else changed that brought the issue back.

With Best Regards.

Steven.

On Sun, May 17, 2020 at 4:36 PM Yedidyah Bar David  wrote:

> On Fri, May 15, 2020 at 4:24 PM Artem Hrechanychenko
>  wrote:
> >
> > Hi,
> > I'm getting failure on ci check for my patch for network suite changes
> > https://gerrit.ovirt.org/#/c/108317/
> >
> > CI failures
> >
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/9350/
> >
> > My patch does not change the basic-suite master and local run passed
> locally. Does anybody know or get something similar ?
>
> engine.log has:
>
>
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/9350/artifact/check-patch.compat-4.3_suite_master.el7.x86_64/test_logs/compat-4.3-suite-master/post-004_basic_sanity_pytest.py/lago-compat-4-3-suite-master-engine/_var_log/ovirt-engine/
>
> 2020-05-15 08:38:25,062-04 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (ForkJoinPool-1-worker-23) [2e5b2649] EVENT_ID: VM_DOWN_ERROR(119), VM
> vm2 is down with error. Exit message: XML error: Invalid PCI address
> :02:01.0. slot must be <= 0.
>
> Perhaps it's this, or a similar/related one (found simply by searching
> for "Invalid PCI address"):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1770697
>
> Best regards,
> --
> Didi
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-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/devel@ovirt.org/message/M367YCTWZLTCTUTV745QCR6R4ON7RKHY/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/XLJ4SA44RH4K3RHGV7PA5OGPXKFZT57W/

[ovirt-devel] are we storing the back-end fqdn (like the one used in gluster) in engine?

[Prajith Kesava Prasad]

Hi all,
I hope this email finds you well.

I just wanted to check, does anyone know if there is a way to get the
back-end hostname from the ovirt-engine?, (this scenario is most likely to
occur when an external logical network is attached).

I did see a way to get the network interface, with respect to each host.
like Even though RHV-engine, contains logical network-attached to it, and
its details (like ipv4). There is no primary key present that could help us
identify that a network is gluster related or not. so we cannot actually
get the details, because we won't know if a network is gluster network or
something else.

I just wanted to see, if there is any other way to get the details of the
backend hostname?

Thanks in advance,
Prajith.
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-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/devel@ovirt.org/message/MFNXHNN6QU5UBH5UHHNUW7UZ5LZDTTAT/