Search results

Link to pastebin output of : journalctl -u pve-cluster -u corosync

There should not be, but although latency is normally well under 1ms, it's possible there are occasional spikes. I would have expected the upper layers to recover automatically once quorum was reestablished, though...? Manually restarting one daemon from time to time isn't a big deal, just a...

Pretty sure it's not an IGMP problem since, as I said, I'm running in UDPU mode because I have no multicast capability whatsoever between the nodes.

Firstly: output is too long to paste here, so http://pastebin.com/Bam4YURH Secondly: when I try "service pve-cluster restart" on pve3, I get these additional log entries: Apr 20 07:22:54 pve3 systemd[1]: Stopping The Proxmox VE cluster filesystem... Apr 20 07:22:54 pve3 pmxcfs[1519]: [main]...

I've got a 3-node PVE 4.1 cluster running using UDPU. "pvecm status" and "pvecm nodes" indicate all is well. I can SSH back and forth between all three nodes at will. After a fresh boot, I can manage all three hosts from any of the three hosts. But after about a week or so, each host can only...

<smacks forehead> You got it in one! I had flagged "local" as shared for some reason. Oh, I do remember why - I'm also exporting each node's /var/lib/vz directory to the others via NFS so they can back up to each other and restore each other's backups if/when necessary - OVH/SyS doesn't...

I've got a 3-node PVE 4.1 cluster running with UDPU at OVH (on their SoYouStart brand, experience has been OK so far). Using UDPU, the cluster seems (well, seemed) to operate quite happily once I got corosync to be 100% happy with UDPU. I'm now seeing a strange behaviour, when I try to migrate...

Would you please share what you did to get past the CMAP initialization problem?

Oh, OK... I thought that was equivalent to what using "virtio" in the first place did? If not, can you point me to something that explains the difference? Edit: did some more reading; is "virtio" equivalent to "virtio-blk"?

Never mind. From the slightly newer CEPH documentation at http://docs.ceph.com/docs/master/rbd/qemu-rbd/#enabling-discard-trim, I also see: So is there no way to get discard support without downgrading to the IDE driver? Even in a VM, that provides noticeably poor performance for me...

I'm reading in various other threads that Discard (TRIM) support actually works in CEPH-backed VMs, but that's not my experience: [root@fs1 ~]# fstrim / fstrim: /: FITRIM ioctl failed: Operation not supported For that particular VM: root@pve4:~# qm config 135-bash: warning: setlocale: LC_ALL...

Nope. It's a bug in OVS, based on both my own testing and Dietmar's testing. Switched from OVS to Linux Bridging and the problem vanishes completely. Dietmar previously reported (in various places including this forum) that it only affects certain combinations of kernel versions, NICs and...

Well, that bites... I switched management to vmbr0 itself instead of an OVSIntPort, and the problems continue. Thus my results contradict Dietmar's original problem report, in that it's not tied to an OVSIntPort. It *is* still tied to having a running tap interface attached to vmbr0, however...

Doesn't work so well when you use Amanda, unfortunately... no tape agent per se exists. I could run Amanda directly on the node, but then I may as well just reinstall a non-PVE OS and dedicate the hardware to Amanda. Which it looks like I'll have to do :-(.

Trying to pass a tape-changer through to a RHEL6 VM isn't working, not sure why. 1) I had to write custom udev rules to ensure I was always passing through the correct SCSI devices, enumeration doesn't seem to be entirely stable or deterministic on my system. 2) I had to forcibly disable the st...

Well, actually, um, er... this node is a PowerEdge 2970 with the battery-backed PERC/5i RAID controller. I'm actually running OSDs on three RAID1 volumes to take advantage of the enhanced BBWC performance, since I've got it. (If I didn't have the battery module, I would have just disabled RAID...

I booted sysresccd, mounted (to replay the XFS journal), unmounted, and ran xfs_repair on each of the 3 OSDs on that host. xfs_repair didn't appear to complain about anything in particular, which worries me - if the kernel panicked in xfs_metadata updates, there should have been *something*...

The problem with not using OVSIntPort for proxmox management is when you have VMs that run in the same VLAN/subnet as the proxmox hosts themselves... then you have to keep track of which VLAN is the untagged VLAN. I'm scared to use that VLAN Tag port on the vmbr0 interface, because I have no...

I'm getting repeated kernel panics on one of my nodes (see picture, below). I'm guessing that one of the CEPH OSDs on this system got broken somehow, and XFS is now really unhappy. So this produces two problems for me... 1) should I even try to fix the XFS filesystem? 2) CEPH isn't...

It looks like, based on Dietmar's original OVS bugreport, that having the management port on the UNTAGGED bridge itself, rather than on an OVSIntPort, might work fine. I'll be testing that here soon, but not today!