Search results

Dann bist du aber auch schon wieder an einem Punkt wo du fast kein Live Patching mehr brauchst. Dann könntest du noch für 10+€ einen SBC/Thin-Client als QDevice dazupacken und hättest ein Cluster, damit du mit Live Migration einen Node für einen Reboot freiräumen könntest. ;)

Das Zitat sagt doch genau das. Du musst die VM migrieren oder neustarten (und das über PVE was dann ein Shutdown + Start macht damit die VM einmal wirklich stoppt...Reboot innerhalb der VM reicht nicht). Sonst läuft die VM mit der veralteten QEMU Version weiter selbst wenn auf dem Host bereit...

Stand-alone PVE node or cluster? Usually it is full root filesystem, storage problems or quorum lost.

USB passthrough isn't great for devices that need low latency or high bandwidth like an USB disk. So for an USB disk I would recommend using disk passthrough via virtio SCSI: https://pve.proxmox.com/wiki/Passthrough_Physical_Disk_to_Virtual_Machine_(VM)

Aber natürlich auch nur, wenn PBS nicht ständig darauf zugreift. Bei einer 14TB HDD wird die aber sehr viel zu tun haben. Nicht vergessen: PBS braucht IOPS-Performance und daher am besten SSDs für die Backups. HDDs kann man nutzen, dann muss man sich aber nicht wundern, wenn so ein Maintainance...

Denke die meisten umgehen das einfach über einen Cluster und Live Migration. Da flog sogar ein Script (glaube von Tuxis?) rum was dir automatisch einen Node von Gästen freiräumt, dann kannst du den Node neustarten, ohne das irgendein Gast Downtime hätte und dann werden die Gäste wieder...

Wenn du oft auf deine Downloads von Windows zugreifen willst, dann würde ich lieber eine NAS VM/LXC laufen lassen die einen SMB-Share bereit stellt. Wenn dein Metube in einem privilegierten LXC oder in einer VM laufen würde, dann könnte man diesen SMB-Share dort einbinden, dass dir Metube die...

The keyword here is the "up to". 6.6 GB/s is when writing to DRAM-cache for some seconds. Once the DRAM-cache is full performance will drop to SLC-cache performance. Once the SLC-cache is full it will drop to TLC-NAND performance. And then its not unusual that such an SSD can't handle more than...

8MB/s is a lot of writes for a system disk that isn't storing any guests. 177 IOPS shouldn't be a problem for consumer SSDs even if those would be sync writes. Yes, so basically what I wrote above about cache filling up and disks can't keep up writing it to disk. With caching set to "none" ZFS...

Here, yes. All you have to do to steal my server is to break a window. No tools or ladder are required. You don't even have to enter the building, you could grab it from outside and pull it through the window. You just need some muscles because those servers are fully populated 4U chassis. ;)...

Checking the "shared" checkbox won't share that directory. You have to share it on your own by setting up a NFS server via CLI or similar. That checkbox is only to tell PVE that it is working with a shared filesystem. Jep, makes much more sense. If all the second node should do is backup your...

You should explain a bit more with infos like what guestOS, what exact error message and so on. If you are that unspecific no one could help.

I don't think ZFS is the problem. Most stuff the system disks are writing are logs, metrics and updates of the cluster DB. HDDs could handle this, then consumer SSD shouldn't have a problem either. You could use tools like iotop or iostat to narrow down whats causing the io delay. zpool iostat...

Ich würde mich an deiner Stelle per SSH mit dem LXC verbinden und dann dort mal mit etwas wie du -a / 2>/dev/null | sort -n -r | head -n 20 nach den größten Ordnern suchen. pct config <VmidDeinesLXCs> würde auch helfen zu wissen, ob es da irgendwelche Bind-Mounts oder ähnliches gibt. Aber am...

You know why "unsafe" is called like it? It will do all important sync writes (that shouldn't be lost, no matter what) as unsafe volatile async writes so a failing PSU, kernel crash, power outage or other hardware failure might for example kill a whole filesystem or DB. My guess would also be...

Then make sure to use LUKS/SED with unencrypted ZFS on top and not ZFS native encryption as with ZFS native encryption you won't be able to use replication nor to migrate VMs.

Das ist doch aber normal. Hast du IO die stattfindet und freien RAM, dann wird das OS den freien RAM für das Read-Caching der IO benutzen, damit diese Daten schneller aus dem RAM geladen werden können, falls man nochmal darauf zugreifen will. Erst wenn ein Prozess mehr RAM braucht, als was...

That section is about backing up multiple clusters to a single PBS. Backup groups get mixed up if you got multiple VMs with the same VMID and will result in pruning of stuff you don't want to prune. With a single cluster this isn't a problem as then you can't use a VMID twice. For protection...

You could also schedule the second backup job one minute after the first one. Here, PVE will only do one backup task per node at a time, so the second job should wait until the first one finished showing a "INFO: trying to get global lock - waiting..."

All file management is done via CLI. You could use the "mount" and "cp" or "mv" commands to copy files. Same as with every linux.