Search results

I can confirm that this is at least part of the problem. See http://openvswitch.org/pipermail/discuss/2015-July/018242.html for more details. So: PVE + OVS + OVSIntPort + cluster communications on that OVSIntPort + multicast + UDP + *running* VM with tap-mode network interface = problems...

I've turned off ALL possible offloading on the NICs, and am still seeing the UDP checksums. Again, based on Proxmox's (Dietmar's) own discoveries with OVS and OVSIntPorts, I'm comfortable blaming OVS+OVSIntPort+Kernel+Driver+Multicast+UDP for the checksum problem. The question then becomes, is...

Really? Intermittent NIC problems on several nodes simultaneously? That all come and go at about the same times? I'd be more inclined to look for problems on the switch. However, based on the OVS multicast thread that Dietmar started last year (linked, above), I'm guessing it's an...

Yes. They're all pointing to a common, local stratum-2 NTP server... oh, wait, they're not. They're still within 0.1sec, since Ceph isn't complaining incessantly, but I'll go fix that now.

I've only found one other possible reference to this problem so far, from http://download.openvz.org/kernel/branches/rhel6-2.6.32-testing/042stab016.1/kernel.spec

Oh, no... this looks like it might be related to http://openvswitch.org/pipermail/discuss/2014-May/013856.html, since I am using OVSIntPorts. root@pve1:/var/log# cat /etc/network/interfaces # network interface settings allow-vmbr0 mgmt158 iface mgmt158 inet static address...

One other possible clue... in /var/log/debug, there's an endless stream of UDP checksum error messages on pve{1,2,3,4,6} but not on the others. The network on each is configured identically. Pve{1,2,3,4} are identical hardware [Dell C6100], pve{5,6} are identical hardware [Dell R710], and pve...

Restarting those services on *all* cluster nodes resulted in: no change at all. The same 3 nodes are ~offline to PVE, but not to pvecm or ceph or anything else.

Done. No visible effect.

I have 9 nodes in a cluster: pve1 through pve9. "pvecm nodes" on all members show all 9 members as "Members". "pvecm status" on all members show the membership as "Cluster-Member". "ceph -s" shows the 9-member CEPH cluster as being healthy. In the GUI and in pvesh, however, I see a different...

I did read that. Several times, today. Ah... on about the 4th or 5th pass through that document, I decided to test "ceph mon remove 3", and that does the trick. Thereafter, I also needed to edit /etc/pve/pve.conf (aka /etc/ceph/ceph.conf) to remove the reference to the missing monitor, and...

See http://forum.proxmox.com/threads/22761-remove-dead-CEPH-monitor-after-removing-cluster-node for my solution.

I removed a PVE cluster node that was also a CEPH monitor (no OSD, just MON). Of course, I forgot to remove the CEPH monitor before removing the node from the cluster. When I attempt to remove the monitor from the PVE GUI, of course it fails because it's trying to cleanly remove it. If I...

I just suddenly encountered the same problem on 2 of 4 Dell C6000 blades, after they OOPS'ed recently (presumably thanks to the leap second). No changes whatsoever to the hardware, just *poof*, kernel OOPS, no automatic reboot, and upon manually resetting them through the (functional!) ILOM...

Enough people have quorum issues, corosync issues, joining issues, etc. that I think these troubleshooting steps should be documented on the wiki. Oh, wait, I have write access to the wiki. Um. Yeah. OK, I'll start writing something up :-(. FWIW, I just discovered that on a 1Gbit/sec...

I've got two 10GB LUNs and a 1.1TB LUN exposed to my server as /dev/sda, /dev/sdb and /dev/sdc. PVE 3.4 was installed to /dev/sda. I want to create a CEPH OSD on /dev/sdc with /dev/sdb as the journal, but I'm unable to do so. Firstly, the GUI only offers to let me use /dev/sda as a journal...

Process tree shows: The OVS logfiles show this: I'm a little unclear on what OVS is doing, since I don't have any OVS running on my system - althoug it is installed. I stopped the openvswitch-switch service: and that gave me this on the apt-get upgrade session: ...and now it's stuck...

(continued in next message)

Starting from a PVE 3.3 server with no updates, I enabled no-subscription repo, disabled the enterprise repo, and ran an upgrade from an SSH session. It's been stuck at this point for several hours: (continued in next message)

What about having a 5th server that is the master, that stays put in the head office, using Proxmox 3.4 with ZFS, and having all 4 roaming demo units configured to replicate ZFS from the master?