Search results

Nope, it is because PVE is trying to access the share "forever".

In some cases the restart of "pvestatd" did help us in this case.

Looks interesting. Wondering how the merging could work ;)

Hallo, warum lässt du den "-password" Parameter denn nicht weg?

Ok, it's definitly the IOPS limit, without the backup is fast. As mentioned here this seems to be "normal": We found an explanation here: https://forum.proxmox.com/threads/disk-throttling-effects-backup-speed.23895/ Is there any way to prevent this? Would be nice to have backup with full speed...

Hi, is disk throttling (kvm) also throttling the backup speed (mode: snapshot)? We're seeing extremely slow backups from VMs where iops_rd and iops_wr is set to 100 each and we have no other explanation for this behavior. Example: The whole backups takes almot 24hours. Other lager VMs only...

Thanks!!! Works, we're using the Qemu monitoring socket and its instant there with the informations we want: echo -e '{"execute":"qmp_capabilities"}\n{"execute":"query-blockstats"}' | socat - UNIX-CONNECT:/var/run/qemu-server/663.qmp

That looks good, thank you! But it is really slow for hundreds of VMs (we've tested it a loop). Any way to have this in /etc/pve/.rrd in an upcoming release? Or can you explain where you gather these informations? Cgroups?

Hi, we're using "pvesh" to gather different metrics from our VMs (for monitoring purposes) and it works really good. One important thing whats missing and would be very useful is IOPS from each VM here or in any other way? Because we're able to limit IOPS within the panel it seems the value of...

Thanks, we'll try that next time.

Hi, we just updated a node with "apt-get dist-upgrade" from a 3 node cluster as usual and it did reboot here: How to avoid that? After reboot with "dpkg --configure -a" all packages were proper installed.

Wie sehen denn die SMART Werte der SSDs aus? Sind diese vielleicht am Ende? Evtl. zudem mal TRIM laufen lassen, evtl. wurden durch Locky auch VM-Images (nutzt Ihr QCOW?) komplett ausgerollt und sind nun deutlich größer auf den SSDs (Verifikation via qemu-image info image.qcow). Hier hilft...

Hallo, klar, geht ohne Probleme mit der API. Siehe http://pve.proxmox.com/pve2-api-doc/ Alternativ einfach den Usern Zugriff auf das PVE Panel geben mit Rechten für seine VM.

Nein, wir haben immer dedizierte NICs für Storage mit Bonding (802.3ad) für bessere Performance und Ausfallsicherheit.

Wir haben diverse PVE Cluster laufen, sowohl mit 10 Gbps also auch mit 1 Gbps - je nach Storagetyp. Maximal jedoch mit 5 Nodes, da ist Unicast kein Problem.

Wir haben ausschließlich Unicast im Einsatz, keine Probleme damit. Naja, für HA brauchst du halt Shared-Storage und mindestens 3 Nodes ;)

Nein, man kann auch Unicast nutzen ("transport: udpu" setzen in der /etc/pve/corosync.conf). Generell hat das Clustering mit HA aber nichts zu tun.

With this slow HDDs Ceph will have a really bad read performance (writes will also be slow, escpecially when flushing from the journal to the HDDs). It depends on your workload, but with many VMs this can become a problem.

We use separate bridges on host-level for this and it works. In Proxmox you can then configure the VM to use the specified bridge (i.e. vmbr0 for your normal traffic und vmbr1 for the trunk configured).

Danke, wir sind dabei :-)