Search results

Update for the folks who are watching. The latest proxmox seems to work with the latest 3.8 and 3.9 glustefs. I'm not sure what changed, no updates to the bug reference on proxmox/qemu, so it's a mystery how it broke and how it was fixed.

Another take away, using libgfapi appears to be less common than just using CEPH. Our fallback option to this workaround was moving storage types away from GlusterFS entirely. As it stands, there's nothing in Proxmox as a product/build to stop you from running into this apart from running into...

@proxtom, After working through this with support, we have a definite bug in the QEMU side of things. When on the latest 2.7 QEMU package, the images are created with a bad offset. QEMU Defect: gluster partial reads refusal conflicts with qcow https://bugs.launchpad.net/qemu/+bug/1644754 As...

@proxtom - I was working on some repro images for support and found that proxmox released pve-qemu-kvm 2.7.0-8. After applying this latest update, linked clones started working again for me. I would suggest trying this while I work out the root cause with support. For now we're holding all...

To illustrate the same problem using the repo version of gluster with the latest 4.3, which should be supported/tested. root@prox01:~# /usr/bin/kvm -id 101 -chardev 'socket,id=qmp,path=/var/run/qemu-server/101.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -pidfile...

I've done some more debugging here and it seems more likely to me that this is actually a proxmox issue. Today I've moved an external glusterfs server to the latest 3.8, while keeping the client libs at the 3.7.15-1 release. This works as expected. As soon as proxmox-ve, or...

Just an FYI to close this loop for the community. Dominik from support was able to help me solve this- THANK YOU! The issue is that the VNC ticket handoff happens over SSH. In our configuration of SSH via chef, we accidentally removed a default setting that came from the default proxmox SSH...

I ran the experiment of pegging glusterfs at 3.7.15-1. As soon as you move the glusterfs-client package to anything greater (including 3.8), you start running into the locking issues. As long as you don't move this package, the following pve packages continue to work, including QEMU 2.7.0...

Sorry you are correct, 3.8 is considered stable as well. That transition happened between the last review.

Exactly the same result. Due to the dependencies, it's forcing an update to qemu 2.7 where the issue probably lies. Glusterfs works fine for the FUSE interface, just not the libgfapi. kvm: -drive...

Yes but stable is 3.7. I will try since it's a dev lab, but this wouldn't be a good option normally. In the past 3.8 was incompatible with the version of KVM that was used previously.

Sure. [root@dev-proxmox] /home/scott $ pveversion -v proxmox-ve: 4.3-71 (running kernel: 4.4.21-1-pve) pve-manager: 4.3-9 (running version: 4.3-9/f7c6f0cd) pve-kernel-4.4.6-1-pve: 4.4.6-48 pve-kernel-4.4.21-1-pve: 4.4.21-71 pve-kernel-4.4.19-1-pve: 4.4.19-66 lvm2: 2.02.116-pve3 corosync-pve...

Quick question for the glusterfs users out there. Recently we updated a dev cluster running 4.3 to the latest stable glusterfs. After the update it seems KVM using glusterfs is unable to perform any operations on the glusterfs cluster. Everything works fine on the fuse mount, but when KVM...

SSH works flawlessly, no prompts for signatures nothing. As mentioned, the SSL certs are the standard pre-generated certificates, so if there's an issue with them it's coming straight out of the installer. I'll try generating new ones. [scott@sfo-proxmox01] ~ $ openssl s_client -connect...

No solution yet. I'm starting to wonder if there's a fundamental issue in pveproxy security between machines. It isn't the SSH layer since the keys + known hosts are all in order.

All of the systems are subsequent IPs in the same 10.12.0.0/24 network connected to the same switch. I can reach *any* system just by using SSH to the hostname as root. No key signature problems nothing. There's no iptables rules defined on host, and I reverted all sshd_config changes to the...

I've removed fail2ban, and verified there were no remaining iptables rules. I also reverted to the default sshd config and still have the same behavior. Outside this, we're on a completely standard proxmox install.

I'll review it's settings and try disabling it to make sure it's not the culprit. However, i'm still wondering if something else could cause this. Fail2ban only kicks in if someone is brute forcing causing auth failures. By itself there won't be any action, the default rules are allow until it...

SSH is an interesting point. Is there a specific user that's used or is it the root user cluster channel? We do implement fail2ban and some additional users with SSH keys via chef, but it's never affected the cluster. For example, all SSH communication works fine with the SSH keys...

Do you have any hints on connection process. I.E. is it passing an auth cookie via the browser, or is it doing some kind of handshake at the network level. The cluster works fine, and there's full connectivity via SSH. The only thing that I do think that could be related is the REST API...