Search results

We're using HP iLO. I cant't find an forward from root to this addresse? Should be in /etc/aliases, or not?

Hi, have you ever tried to setup PVE through a Java emulated KVM from a Linux or Mac system? :-) It can be real pain because you might have no chance to create the "@" sign, but this is required when installing. We currently use as a workaround to copy (!) the "@" sign from the error message...

This solution is also in our agenda, but the handling if these dump is not as convenient as with the VMA files, so you can't import them to another PVE machine without having a running ceph cluster in case of emergency. It's a pity to have a fast ceph cluster with SSD but running these...

Das Command "runlevel" ist deprecated und sollte nicht mehr benutzt werden auf Systemen mit systemd. Die systemd Commands findest du unter https://wiki.archlinux.org/index.php/Systemd#Get_current_targets

Not at the moment, this discussion was also on the mailing list, see http://pve.proxmox.com/pipermail/pve-devel/2016-February/019267.html We're also affected by this issue, backups from ceph are much slower then they could be :( Would be nice to get a solution for this.

Any chance to get network throughput or other netstats in there? :)

Samsung has a good documentation for this: http://www.samsung.com/global/business/semiconductor/minisite/SSD/M2M/download/07_Communicating_With_Your_SSD.pdf

@dietmar we tried to change a cluster back to multicast in this way: deleted the HA groups and removed VMs from them changed corosync config /etc/pve (removed udpu) and increased config version after that, we restarted corosync on all nodes and pvecm told us everything was fine *then all nodes...

Crazy solution ;-) You could use sshfs and mount a SSH endpoint, but maybe this is slow due to the usage of fuse.

Hi, yes, this is really uncool ;-) But also in our enviroment we still have not found a better working alternative for NFS as backup ressource with PVE. I'm wondering why PVE still uses NFS v3 by default, not v4. You can change this in /etc/pve/storage.cfg afaik in "options".

Hi, we had the same issue several times ago. In our case it helped to stop pvestatd, umount the volume and then start pvestatd again after NFS is recovered.

Thats right - but this does not imply the limit to 4 nodes, right?

Hi, just wondering why the PVE Wiki mentions the unicast limit explicitly with "do not use it with more that 4 cluster nodes"? An example in the corosync git repo (see here) has 16 nodes with unicast, can't believe they are wrong there? Is there any proof that this 4 node limit does really...

Yes, we're also running several clusters with 5 or more nodes and UDPU. Just wondering the PVE Wiki mentions this limit explicitly with "do not use it with more that 4 cluster nodes.".

PS: The "official" corosync example uses 16 nodes with UDPU, see https://github.com/fghaas/corosync/blob/master/conf/corosync.conf.example.udpu - do you think they're all wrong there? :)

Can you explain why exactly this is a problem? I could not find anything about these limit in the corosync docs. Thanks!

You could test inotify based tools like lsyncd (https://github.com/axkibe/lsyncd). But this does not work with millions of files very well.

> FSYNCS/SECOND: 44.71 This is more then slow, you'll not have fun running VMs here. Try to disable write barriers or get a better IO stack.

Just use any older kernel for now from the grub menu when booting. The latest kernel is not needed when updating to latest PVE.

Thanks!