Search results

I would try again with "Enterprise Class SSDs" with PLP / "Power-Loss-Protection". ...and with mirrors, not a RaidZ2 - as this gives you only the IOPS of a single device. Of course SATA is massively slower than PCIe --> if possibly switch technology... Disclaimer: just random thoughts...

Unfortunately I am not aware of built-in dropbear support in PVE. How did you install that? May be it helps to re-read that documentation...? (I mean it - you are outside of the usual PVE context and we just cannot know what you did!)

At the top right, in your user menu, check "My Settings - Webinterface Settings - Dashboard Storages". Possibly the same storage is summed up more than once. Just guessing..., I am not using Ceph currently.

I would ask that question (with as many details as in a compact way possible) via https://shop.proxmox.com/submitticket.php

I believe this is not implemented in the Gui (yet?). On commandline it works as intended. man zpool-attach tells you the syntax. This is a manipulation on the lowest level and failures may be fatal. Personally I do set a global checkpoint to have a way back to the previous state. See man...

Buy some USB-to-SATA adapters to use them temporarily for this task. They are cheap, five to ten Dollars/Euros each... Edit: that is probably not going to work for 3.5 inch harddisks, because of the required power...

PDM enters beta - it may possibly help migrating between non-clustered systems. (I did not test PDM yet...) https://pve.proxmox.com/wiki/Category:Proxmox_Datacenter_Manager Announcement 30 minutes ago: https://forum.proxmox.com/threads/proxmox-datacenter-manager-0-9-beta-released.171742/

That's of course the problem here. When I steal that computer I get the key for free. What attacking vector is it you are securing with this approach? The only situation I see is if the devices die so hard, that the build-in "erase"-function can not get triggered anymore and you want to send...

Check and restart -if it is not "active (running)"- pveproxy: ~# systemctl status pveproxy.service ~# systemctl restart pveproxy.service ~# systemctl status pveproxy.service

Yes, you are (or course) correct. Note that I do admit that although I am using ZFS exclusively - the few clusters I have are small. With that number of nodes ZFS-replication (over all nodes) would be a bad choice. And partial replication -let's say in two groups of four nodes- introduces...

Each tool has it own benefits. But yes, I am using cv4pve for exactly that reason. While I am absolutely able to handle Desaster recovery with naked replicated snapshots the integration in the PVE logic and in the GUI is really convenient! The other important aspect is that it works...

It is (first) calculated on PVE. Then this checksum is transmitted to PBS - only the checksum, no data. If a chunk with that checksum already exists on PBS then some references are updated to reflect this new backup. Only if that checksum is not already present on PBS then the data is...

Things like this can simply be tested: when I disable the debian sources and query the policy of a random (but known to be installed) package I get: ~# apt policy bash bash: Installed: 5.2.37-2+b5 Candidate: 5.2.37-2+b5 Version table: *** 5.2.37-2+b5 100 100 /var/lib/dpkg/status...

I am not @fabian ;-) but I can show you this: My system is using non-subscription, everything updated. ~# pveversion pve-manager/9.0.6/49c767b70aeb6648 (running kernel: 6.14.11-1-pve) The swtpm binary comes from the corresponding package: ~# dpkg -S /usr/bin/swtpm swtpm: /usr/bin/swtpm...

Yeah, that the one instance I have with PVE + PBS installed in parallel. I will try to not take that node as an example-generator anymore, as I could not exclude extraordinary behavior. Glad you spotted it. That's why I usually copy-n-paste the actual command and the output :-) For the...

Just for completeness (it does not matter, "exit 0" is the relevant command), the "no-subscription" version is different: ~# dpkg -S /etc/initramfs/post-update.d/systemd-boot systemd-boot: /etc/initramfs/post-update.d/systemd-boot ~# apt policy systemd-boot systemd-boot: Installed...

No! "samba" is a meta package - it also includes the server part. Try to install the package "cifs-utils", it should deliver the command "mount.cifs"...

Thanks for the hint; no I am in Germany. I looked at my large clock at the wall, it shows the right date. I read it wrong, for an unknown reason... And -of course- if you type wrong things willingly you can look at them as often as you want - it stays correct.

Verbatim copy of https://bugzilla.proxmox.com/show_bug.cgi?id=6773 Short: a SUSPENDED ZFS pool is not recognized although all VMs stall and services are practically down. Long: after upgrade to Trixie 13.1 (pve-manager/9.0.6/49c767b70aeb6648 (running kernel: 6.14.11-1-pve)) on 08 Sept. 2025...

Try to follow https://pve.proxmox.com/wiki/Upgrade_from_8_to_9 carefully. As long as your specific system is not heavily modified it should lead to success. In your sources.list I can see at least one bookworm (should be trixie) and the fundamental "main" Debian source is... missing?