subject:"\[ovirt\-users\] centos 7.1 and up \& ixgbe"

Re: [ovirt-users] centos 7.1 and up & ixgbe

2016-07-18 Thread Douglas Schilling Landgraf

Hi Johan,

On 07/18/2016 09:53 AM, Johan Kooijman wrote:

Hi Jeff,

was the issue ever resolved? Don't have permissions to view the bugzilla.

There are proposal patches in the bugzilla, I have requested more 
information about upstream status.

As soon I have updates, I will reply here.

For now, if you have the hardware and want to give a test against our 
latest upstream build jobs, links below:

ovirt-node 3.6:
http://jenkins.ovirt.org/job/ovirt-node_ovirt-3.6_create-iso-el7_merged/

ovirt-node 4.0 (next):
http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0-snapshot_build-artifacts-fc23-x86_64/

Thanks!

On Thu, Mar 17, 2016 at 4:34 PM, Jeff Spahr > wrote:

I had the same issue, and I also have a support case open.  They
referenced https://bugzilla.redhat.com/show_bug.cgi?id=1288237
which is private.  I didn't have any success getting that bugzilla
changed to public.  We couldn't keep waiting for the issue to be
fixed so we replaced the NICs with Broadcom/Qlogic that we knew
had no issues in other hosts.

On Thu, Mar 17, 2016 at 11:27 AM, Sigbjorn Lie
> wrote:

Hi,

Is this on CentOS/RHEL 7.2?

Log in as root as see if you can see any messages from ixgbe
about "tx queue hung" in dmesg. I
currently have an open support case for RHEL7.2 and the ixgbe
driver, where there is a driver
issue causing the network adapter to reset continuously when
there are network traffic.

Regards,
Siggi

On Thu, March 17, 2016 12:52, Nir Soffer wrote:
> On Thu, Mar 17, 2016 at 10:49 AM, Johan Kooijman
> wrote:
>
>> Hi all,
>>
>>
>> Since we upgraded to the latest ovirt node running 7.2,
we're seeing that
>> nodes become unavailable after a while. It's running fine,
with a couple of VM's on it, untill it
>> becomes non responsive. At that moment it doesn't even
respond to ICMP. It'll come back by
>> itself after a while, but oVirt fences the machine before
that time and restarts VM's elsewhere.
>>
>>
>> Engine tells me this message:
>>
>>
>> VDSM host09 command failed: Message timeout which can be
caused by
>> communication issues
>>
>> Is anyone else experiencing these issues with ixgbe
drivers? I'm running on
>> Intel X540-AT2 cards.
>>
>
> We will need engine and vdsm logs to understand this issue.
>
>
> Can you file a bug and attach ful logs?
>
>
> Nir
> ___
> Users mailing list
> Users@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/users
>
>

___
Users mailing list
Users@ovirt.org 
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org 
http://lists.ovirt.org/mailman/listinfo/users

--
Met vriendelijke groeten / With kind regards,
Johan Kooijman

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] centos 7.1 and up & ixgbe

2016-07-18 Thread Johan Kooijman

Hi Jeff,

was the issue ever resolved? Don't have permissions to view the bugzilla.

On Thu, Mar 17, 2016 at 4:34 PM, Jeff Spahr  wrote:

> I had the same issue, and I also have a support case open.  They
> referenced https://bugzilla.redhat.com/show_bug.cgi?id=1288237 which is
> private.  I didn't have any success getting that bugzilla changed to
> public.  We couldn't keep waiting for the issue to be fixed so we replaced
> the NICs with Broadcom/Qlogic that we knew had no issues in other hosts.
>
> On Thu, Mar 17, 2016 at 11:27 AM, Sigbjorn Lie 
> wrote:
>
>> Hi,
>>
>> Is this on CentOS/RHEL 7.2?
>>
>> Log in as root as see if you can see any messages from ixgbe about "tx
>> queue hung" in dmesg. I
>> currently have an open support case for RHEL7.2 and the ixgbe driver,
>> where there is a driver
>> issue causing the network adapter to reset continuously when there are
>> network traffic.
>>
>>
>> Regards,
>> Siggi
>>
>>
>>
>> On Thu, March 17, 2016 12:52, Nir Soffer wrote:
>> > On Thu, Mar 17, 2016 at 10:49 AM, Johan Kooijman <
>> m...@johankooijman.com> wrote:
>> >
>> >> Hi all,
>> >>
>> >>
>> >> Since we upgraded to the latest ovirt node running 7.2, we're seeing
>> that
>> >> nodes become unavailable after a while. It's running fine, with a
>> couple of VM's on it, untill it
>> >> becomes non responsive. At that moment it doesn't even respond to
>> ICMP. It'll come back by
>> >> itself after a while, but oVirt fences the machine before that time
>> and restarts VM's elsewhere.
>> >>
>> >>
>> >> Engine tells me this message:
>> >>
>> >>
>> >> VDSM host09 command failed: Message timeout which can be caused by
>> >> communication issues
>> >>
>> >> Is anyone else experiencing these issues with ixgbe drivers? I'm
>> running on
>> >> Intel X540-AT2 cards.
>> >>
>> >
>> > We will need engine and vdsm logs to understand this issue.
>> >
>> >
>> > Can you file a bug and attach ful logs?
>> >
>> >
>> > Nir
>> > ___
>> > Users mailing list
>> > Users@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/users
>> >
>> >
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>


-- 
Met vriendelijke groeten / With kind regards,
Johan Kooijman
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] centos 7.1 and up & ixgbe

2016-04-04 Thread Johan Kooijman

Hi Jurrien,

I don't see anything in logs on the nodes itself. The only thing we see in
logs are in engine log - it looses connectivity to the host.
Definitely CentOS 7.1/7.2 related. Downgraded the hosts to ovirt-iso 3.5,
this resolves the issue.

On Fri, Mar 18, 2016 at 9:01 AM, Bloemen, Jurriën <
jurrien.bloe...@dmc.amcnetworks.com> wrote:

> Hi Johan,
>
> Could you check if you see the following in you dmesg or message log file?
>
> [1123306.014288] [ cut here ]
> [1123306.014302] WARNING: at net/core/dev.c:2189
> skb_warn_bad_offload+0xcd/0xda()
> [1123306.014306] : caps=(0x00024849, 0x) len=330
> data_len=276 gso_size=276 gso_type=1 ip_summed=1
> [1123306.014308] Modules linked in: vhost_net macvtap macvlan
> ip6table_filter ip6_tables iptable_filter ip_tables ebt_arp ebtable_nat
> ebtables tun scsi_transport_iscsi iTCO_wdt iTCO_vendor_support
> dm_service_time intel_powerclamp coretemp intel_rapl kvm_intel kvm
> crct10dif_pclmul crc32_pclmul ghash_clmulni_intel cryptd pcspkr sb_edac
> edac_core i2c_i801 lpc_ich mfd_core mei_me mei wmi ioatdma shpchp
> ipmi_devintf ipmi_si ipmi_msghandler acpi_power_meter acpi_pad 8021q garp
> mrp bridge stp llc bonding dm_multipath xfs libcrc32c sd_mod crc_t10dif
> crct10dif_common ast syscopyarea sysfillrect sysimgblt drm_kms_helper ttm
> crc32c_intel igb drm ahci ixgbe i2c_algo_bit libahci libata mdio i2c_core
> ptp megaraid_sas pps_core dca dm_mirror dm_region_hash dm_log dm_mod
> [1123306.014360] CPU: 30 PID: 0 Comm: swapper/30 Tainted: GW
> --   3.10.0-229.1.2.el7.x86_64 #1
> [1123306.014362] Hardware name: Supermicro SYS-2028TP-HC1TR/X10DRT-PT,
> BIOS 1.1 08/03/2015
> [1123306.014364]  881fffc439a8 5326fb90ad1041ea 881fffc43960
> 81604afa
> [1123306.014371]  881fffc43998 8106e34b 881fcebb0500
> 881fce88c000
> [1123306.014376]  0001 0001 881fcebb0500
> 881fffc43a00
> [1123306.014381] Call Trace:
> [1123306.014383][] dump_stack+0x19/0x1b
> [1123306.014396]  [] warn_slowpath_common+0x6b/0xb0
> [1123306.014399]  [] warn_slowpath_fmt+0x5c/0x80
> [1123306.014405]  [] ? ___ratelimit+0x93/0x100
> [1123306.014409]  [] skb_warn_bad_offload+0xcd/0xda
> [1123306.014425]  [] __skb_gso_segment+0x79/0xb0
> [1123306.014429]  [] dev_hard_start_xmit+0x1a2/0x580
> [1123306.014438]  [] ? deliver_clone+0x50/0x50 [bridge]
> [1123306.014443]  [] sch_direct_xmit+0xee/0x1c0
> [1123306.014447]  [] dev_queue_xmit+0x1f8/0x4a0
> [1123306.014453]  [] br_dev_queue_push_xmit+0x7b/0xc0
> [bridge]
> [1123306.014458]  [] br_forward_finish+0x22/0x60 [bridge]
> [1123306.014464]  [] __br_forward+0x80/0xf0 [bridge]
> [1123306.014469]  [] br_forward+0x8b/0xa0 [bridge]
> [1123306.014476]  [] br_handle_frame_finish+0x175/0x410
> [bridge]
> [1123306.014481]  [] br_handle_frame+0x175/0x260 [bridge]
> [1123306.014485]  [] __netif_receive_skb_core+0x282/0x870
> [1123306.014490]  [] ? read_tsc+0x9/0x10
> [1123306.014493]  [] __netif_receive_skb+0x18/0x60
> [1123306.014497]  [] netif_receive_skb+0x40/0xd0
> [1123306.014500]  [] napi_gro_receive+0x80/0xb0
> [1123306.014512]  [] ixgbe_clean_rx_irq+0x7ac/0xb30
> [ixgbe]
> [1123306.014519]  [] ixgbe_poll+0x4bb/0x930 [ixgbe]
> [1123306.014524]  [] net_rx_action+0x152/0x240
> [1123306.014528]  [] __do_softirq+0xf7/0x290
> [1123306.014533]  [] call_softirq+0x1c/0x30
> [1123306.014539]  [] do_softirq+0x55/0x90
> [1123306.014543]  [] irq_exit+0x115/0x120
> [1123306.014546]  [] do_IRQ+0x58/0xf0
> [1123306.014551]  [] common_interrupt+0x6d/0x6d
> [1123306.014553][] ?
> cpuidle_enter_state+0x52/0xc0
> [1123306.014561]  [] ? cpuidle_enter_state+0x48/0xc0
> [1123306.014565]  [] cpuidle_idle_call+0xc5/0x200
> [1123306.014569]  [] arch_cpu_idle+0xe/0x30
> [1123306.014574]  [] cpu_startup_entry+0xf5/0x290
> [1123306.014580]  [] start_secondary+0x1ba/0x230
> [1123306.014582] ---[ end trace 4d5a1bc838e1fcc0 ]---
>
> If so, then could you try the following:
>
> ethtool -K  lro off
>
> Do this for all the 10G intel nics and check if the problems still exists
>
>
> *Kind regards,*
>
>
>
> *Jurriën Bloemen*
>
> On 17-03-16 09:49, Johan Kooijman wrote:
>
> Hi all,
>
> Since we upgraded to the latest ovirt node running 7.2, we're seeing that
> nodes become unavailable after a while. It's running fine, with a couple of
> VM's on it, untill it becomes non responsive. At that moment it doesn't
> even respond to ICMP. It'll come back by itself after a while, but oVirt
> fences the machine before that time and restarts VM's elsewhere.
>
> Engine tells me this message:
>
> VDSM host09 command failed: Message timeout which can be caused by
> communication issues
>
> Is anyone else experiencing these issues with ixgbe drivers? I'm running
> on Intel X540-AT2 cards.
>
> --
> Met vriendelijke groeten / With kind regards,
> Johan Kooijman
>
>
> ___
> Users mailing

Re: [ovirt-users] centos 7.1 and up & ixgbe

2016-03-19 Thread Piotr Kliczewski

Johan,

It there is temporary networking issue and you still want engine not to
fence the host you can
increase heartbeat interval in the engine configuration. It would tell
engine to wait longer
before assuming that the host is not responding.

Please provide the logs so we can understand why there is communication
issue in the first
place.

Thanks,
Piotr

On Thu, Mar 17, 2016 at 12:52 PM, Nir Soffer  wrote:

> On Thu, Mar 17, 2016 at 10:49 AM, Johan Kooijman 
> wrote:
> > Hi all,
> >
> > Since we upgraded to the latest ovirt node running 7.2, we're seeing that
> > nodes become unavailable after a while. It's running fine, with a couple
> of
> > VM's on it, untill it becomes non responsive. At that moment it doesn't
> even
> > respond to ICMP. It'll come back by itself after a while, but oVirt
> fences
> > the machine before that time and restarts VM's elsewhere.
> >
> > Engine tells me this message:
> >
> > VDSM host09 command failed: Message timeout which can be caused by
> > communication issues
> >
> > Is anyone else experiencing these issues with ixgbe drivers? I'm running
> on
> > Intel X540-AT2 cards.
>
> We will need engine and vdsm logs to understand this issue.
>
> Can you file a bug and attach ful logs?
>
> Nir
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] centos 7.1 and up & ixgbe

2016-03-19 Thread Bloemen , Jurriën

Hi Johan,

Could you check if you see the following in you dmesg or message log file?

[1123306.014288] [ cut here ]
[1123306.014302] WARNING: at net/core/dev.c:2189 
skb_warn_bad_offload+0xcd/0xda()
[1123306.014306] : caps=(0x00024849, 0x) len=330 
data_len=276 gso_size=276 gso_type=1 ip_summed=1
[1123306.014308] Modules linked in: vhost_net macvtap macvlan ip6table_filter 
ip6_tables iptable_filter ip_tables ebt_arp ebtable_nat ebtables tun 
scsi_transport_iscsi iTCO_wdt iTCO_vendor_support dm_service_time 
intel_powerclamp coretemp intel_rapl kvm_intel kvm crct10dif_pclmul 
crc32_pclmul ghash_clmulni_intel cryptd pcspkr sb_edac edac_core i2c_i801 
lpc_ich mfd_core mei_me mei wmi ioatdma shpchp ipmi_devintf ipmi_si 
ipmi_msghandler acpi_power_meter acpi_pad 8021q garp mrp bridge stp llc bonding 
dm_multipath xfs libcrc32c sd_mod crc_t10dif crct10dif_common ast syscopyarea 
sysfillrect sysimgblt drm_kms_helper ttm crc32c_intel igb drm ahci ixgbe 
i2c_algo_bit libahci libata mdio i2c_core ptp megaraid_sas pps_core dca 
dm_mirror dm_region_hash dm_log dm_mod
[1123306.014360] CPU: 30 PID: 0 Comm: swapper/30 Tainted: GW   
--   3.10.0-229.1.2.el7.x86_64 #1
[1123306.014362] Hardware name: Supermicro SYS-2028TP-HC1TR/X10DRT-PT, BIOS 1.1 
08/03/2015
[1123306.014364]  881fffc439a8 5326fb90ad1041ea 881fffc43960 
81604afa
[1123306.014371]  881fffc43998 8106e34b 881fcebb0500 
881fce88c000
[1123306.014376]  0001 0001 881fcebb0500 
881fffc43a00
[1123306.014381] Call Trace:
[1123306.014383][] dump_stack+0x19/0x1b
[1123306.014396]  [] warn_slowpath_common+0x6b/0xb0
[1123306.014399]  [] warn_slowpath_fmt+0x5c/0x80
[1123306.014405]  [] ? ___ratelimit+0x93/0x100
[1123306.014409]  [] skb_warn_bad_offload+0xcd/0xda
[1123306.014425]  [] __skb_gso_segment+0x79/0xb0
[1123306.014429]  [] dev_hard_start_xmit+0x1a2/0x580
[1123306.014438]  [] ? deliver_clone+0x50/0x50 [bridge]
[1123306.014443]  [] sch_direct_xmit+0xee/0x1c0
[1123306.014447]  [] dev_queue_xmit+0x1f8/0x4a0
[1123306.014453]  [] br_dev_queue_push_xmit+0x7b/0xc0 [bridge]
[1123306.014458]  [] br_forward_finish+0x22/0x60 [bridge]
[1123306.014464]  [] __br_forward+0x80/0xf0 [bridge]
[1123306.014469]  [] br_forward+0x8b/0xa0 [bridge]
[1123306.014476]  [] br_handle_frame_finish+0x175/0x410 
[bridge]
[1123306.014481]  [] br_handle_frame+0x175/0x260 [bridge]
[1123306.014485]  [] __netif_receive_skb_core+0x282/0x870
[1123306.014490]  [] ? read_tsc+0x9/0x10
[1123306.014493]  [] __netif_receive_skb+0x18/0x60
[1123306.014497]  [] netif_receive_skb+0x40/0xd0
[1123306.014500]  [] napi_gro_receive+0x80/0xb0
[1123306.014512]  [] ixgbe_clean_rx_irq+0x7ac/0xb30 [ixgbe]
[1123306.014519]  [] ixgbe_poll+0x4bb/0x930 [ixgbe]
[1123306.014524]  [] net_rx_action+0x152/0x240
[1123306.014528]  [] __do_softirq+0xf7/0x290
[1123306.014533]  [] call_softirq+0x1c/0x30
[1123306.014539]  [] do_softirq+0x55/0x90
[1123306.014543]  [] irq_exit+0x115/0x120
[1123306.014546]  [] do_IRQ+0x58/0xf0
[1123306.014551]  [] common_interrupt+0x6d/0x6d
[1123306.014553][] ? cpuidle_enter_state+0x52/0xc0
[1123306.014561]  [] ? cpuidle_enter_state+0x48/0xc0
[1123306.014565]  [] cpuidle_idle_call+0xc5/0x200
[1123306.014569]  [] arch_cpu_idle+0xe/0x30
[1123306.014574]  [] cpu_startup_entry+0xf5/0x290
[1123306.014580]  [] start_secondary+0x1ba/0x230
[1123306.014582] ---[ end trace 4d5a1bc838e1fcc0 ]---

If so, then could you try the following:

ethtool -K  lro off

Do this for all the 10G intel nics and check if the problems still exists


Kind regards,

Jurriën Bloemen

On 17-03-16 09:49, Johan Kooijman wrote:
Hi all,

Since we upgraded to the latest ovirt node running 7.2, we're seeing that nodes 
become unavailable after a while. It's running fine, with a couple of VM's on 
it, untill it becomes non responsive. At that moment it doesn't even respond to 
ICMP. It'll come back by itself after a while, but oVirt fences the machine 
before that time and restarts VM's elsewhere.

Engine tells me this message:

VDSM host09 command failed: Message timeout which can be caused by 
communication issues

Is anyone else experiencing these issues with ixgbe drivers? I'm running on 
Intel X540-AT2 cards.

--
Met vriendelijke groeten / With kind regards,
Johan Kooijman



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


This message (including any attachments) may contain information that is 
privileged or confidential. If you are not the intended recipient, please 
notify the sender and delete this email immediately from your systems and 
destroy all copies of it. You may not, directly or indirectly, use, disclose, 
distribute, print or copy this email or any part of it if you are not the 
intended recipient
___
Users mailing list
Users@ovirt.org

Re: [ovirt-users] centos 7.1 and up & ixgbe

2016-03-19 Thread Nir Soffer

On Thu, Mar 17, 2016 at 10:49 AM, Johan Kooijman  wrote:
> Hi all,
>
> Since we upgraded to the latest ovirt node running 7.2, we're seeing that
> nodes become unavailable after a while. It's running fine, with a couple of
> VM's on it, untill it becomes non responsive. At that moment it doesn't even
> respond to ICMP. It'll come back by itself after a while, but oVirt fences
> the machine before that time and restarts VM's elsewhere.
>
> Engine tells me this message:
>
> VDSM host09 command failed: Message timeout which can be caused by
> communication issues
>
> Is anyone else experiencing these issues with ixgbe drivers? I'm running on
> Intel X540-AT2 cards.

We will need engine and vdsm logs to understand this issue.

Can you file a bug and attach ful logs?

Nir
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] centos 7.1 and up & ixgbe

2016-03-19 Thread Jeff Spahr

I had the same issue, and I also have a support case open.  They referenced
https://bugzilla.redhat.com/show_bug.cgi?id=1288237 which is private.  I
didn't have any success getting that bugzilla changed to public.  We
couldn't keep waiting for the issue to be fixed so we replaced the NICs
with Broadcom/Qlogic that we knew had no issues in other hosts.

On Thu, Mar 17, 2016 at 11:27 AM, Sigbjorn Lie  wrote:

> Hi,
>
> Is this on CentOS/RHEL 7.2?
>
> Log in as root as see if you can see any messages from ixgbe about "tx
> queue hung" in dmesg. I
> currently have an open support case for RHEL7.2 and the ixgbe driver,
> where there is a driver
> issue causing the network adapter to reset continuously when there are
> network traffic.
>
>
> Regards,
> Siggi
>
>
>
> On Thu, March 17, 2016 12:52, Nir Soffer wrote:
> > On Thu, Mar 17, 2016 at 10:49 AM, Johan Kooijman 
> wrote:
> >
> >> Hi all,
> >>
> >>
> >> Since we upgraded to the latest ovirt node running 7.2, we're seeing
> that
> >> nodes become unavailable after a while. It's running fine, with a
> couple of VM's on it, untill it
> >> becomes non responsive. At that moment it doesn't even respond to ICMP.
> It'll come back by
> >> itself after a while, but oVirt fences the machine before that time and
> restarts VM's elsewhere.
> >>
> >>
> >> Engine tells me this message:
> >>
> >>
> >> VDSM host09 command failed: Message timeout which can be caused by
> >> communication issues
> >>
> >> Is anyone else experiencing these issues with ixgbe drivers? I'm
> running on
> >> Intel X540-AT2 cards.
> >>
> >
> > We will need engine and vdsm logs to understand this issue.
> >
> >
> > Can you file a bug and attach ful logs?
> >
> >
> > Nir
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
> >
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] centos 7.1 and up & ixgbe

2016-03-19 Thread Johan Kooijman

Hi all,

Since we upgraded to the latest ovirt node running 7.2, we're seeing that
nodes become unavailable after a while. It's running fine, with a couple of
VM's on it, untill it becomes non responsive. At that moment it doesn't
even respond to ICMP. It'll come back by itself after a while, but oVirt
fences the machine before that time and restarts VM's elsewhere.

Engine tells me this message:

VDSM host09 command failed: Message timeout which can be caused by
communication issues

Is anyone else experiencing these issues with ixgbe drivers? I'm running on
Intel X540-AT2 cards.

-- 
Met vriendelijke groeten / With kind regards,
Johan Kooijman
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] centos 7.1 and up & ixgbe

2016-03-19 Thread Sigbjorn Lie

Hi,

Is this on CentOS/RHEL 7.2?

Log in as root as see if you can see any messages from ixgbe about "tx queue 
hung" in dmesg. I
currently have an open support case for RHEL7.2 and the ixgbe driver, where 
there is a driver
issue causing the network adapter to reset continuously when there are network 
traffic.


Regards,
Siggi



On Thu, March 17, 2016 12:52, Nir Soffer wrote:
> On Thu, Mar 17, 2016 at 10:49 AM, Johan Kooijman  
> wrote:
>
>> Hi all,
>>
>>
>> Since we upgraded to the latest ovirt node running 7.2, we're seeing that
>> nodes become unavailable after a while. It's running fine, with a couple of 
>> VM's on it, untill it
>> becomes non responsive. At that moment it doesn't even respond to ICMP. 
>> It'll come back by
>> itself after a while, but oVirt fences the machine before that time and 
>> restarts VM's elsewhere.
>>
>>
>> Engine tells me this message:
>>
>>
>> VDSM host09 command failed: Message timeout which can be caused by
>> communication issues
>>
>> Is anyone else experiencing these issues with ixgbe drivers? I'm running on
>> Intel X540-AT2 cards.
>>
>
> We will need engine and vdsm logs to understand this issue.
>
>
> Can you file a bug and attach ful logs?
>
>
> Nir
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] centos 7.1 and up & ixgbe

Re: [ovirt-users] centos 7.1 and up & ixgbe

Re: [ovirt-users] centos 7.1 and up & ixgbe

Re: [ovirt-users] centos 7.1 and up & ixgbe

Re: [ovirt-users] centos 7.1 and up & ixgbe

Re: [ovirt-users] centos 7.1 and up & ixgbe

Re: [ovirt-users] centos 7.1 and up & ixgbe

[ovirt-users] centos 7.1 and up & ixgbe

Re: [ovirt-users] centos 7.1 and up & ixgbe

9 matches

Site Navigation

Mail list logo

Footer information