Search results

No, it's the drives

replace with CMR drives? Hendrik's rules of computing: 1) Make a backup 2) Make *ANOTHER* backup 2b) At least one backup *off* provider (ie. a totally different DC/owner/etc.) 3) *CHECK* those backups Sorry, but it looks like those drives aren't in a good state w.r.t. ZFS.

Anybody arund here doing actual backups of the MinIO storage? I've contemplated using PVE->PBS backups of the nodes (currently I deploy using LXCs) but I'm concerned w.r.t. the sequential nature of the node backups. Which then brings me to the rclone mount type backups, ie. mount the bucket...

I've found the namespaces... not that "great" (though, I am using them in some cases), and have opted to rather do separate datastores for my "DCs"/clusters, even when on the same ZFS pool, at least I get better indications on the storage usage for each DC (which you won't see "Easily" in PBS...

seems like that might be the clue that you are using SMR and not CMR drives.

1) check the disk models whether they are CMR or shingled(sp?)/SMR - the Shingle drives (typically those with like 128MB-256MB or more RAM/cache) are known to break horribly with ZFS 2) personally, I'd rather setup a DRAID2 or a RaidZ3 given your number of disks *AND* have SSD/NVMe SLOG and...

That is what I am aiming for, ie. Layer3 evpn/vxlan and remove the switching network, but the FortiGateVM being the gateway, not the PVE hypervisors

Thank you! Having those entries added in, is a good starting point to check/do things. What I am getting/doing, just... might not work in the SDN setup, as I don't "want" the PVEs to be the router/gateways, but a dedicated VM (FortiGate/etc.) , but still thank you for the pointers to consider

the emphatic word there that *I* want from S3: like tape does now

Good day, is there perhaps a template/documentation/examples for implementing a custom IPAM for the ProxMox SDN side? I'm looking at https://spritelink.github.io/NIPAP/ for IPAM as we roll out the next steps of our network, so obviously the question comes in w.r.t. PVE not (yet) supporting...

The last time *I* used pfSense/OPNsense, the reason you disabled the hardware acceleration and did not want to use the virtIO nics, was that DHCP/UDP had troubles with the lack of checksums added to the packets, and then certain parts would drop the packets, so the need was to stick with E1000...

The case where I used that verification, was when I needed to bootstrap a remote ('cross atlantic) PBS, and the single connection synchronizations was just.... plain molasses on a freezinglingly cold winters day... The easiest was to spin up multiple rsync sessions of each of the directories...

Okay, seems to find the "culprit": This is the values that is set inside the Devuan 4.0 container: /proc/1/task/1/mounts:devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0 And for a Debian container: devpts /dev/ptmx devpts...

Good day, I've been deploying Devuan 4.0 images (pve 7.4) the past 4 months, and had noticed `byobu` strangeness, but only this week it caused me problems that I had to get to the bottom of it. I've tried all the settings in the GUI panel for UNprivileged containers, and eventually...

that, when you look at the replied posts, using the PVE 7.4 GUI, to configure the CloudInit for Debian 12 cloudinit images, it doesn't configure the needed and the vm doesn't boot right

similar troubles using the ProxMox 7.4 GUI interface with the debian-12-genericcloud-amd64.qcow2

I'm in need of executing a script to allow traffic through firewall and open port 80 inbound to the PVE (and next PBS), and then once done, close the ports etc. Is there a current way to do it in PVE 7.x ?

hmmm... seems to also botch the authorized_keys when I do find a "valid" multiple keys pub file: ==> subvol-999996-disk-0/root/.ssh/authorized_keys <== # --- BEGIN PVE --- ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKrogu2+b8HXlhr+M7LuCRdPKwpXSYx0ZJeMDrB7E50M ssh-ed25519...

I'm bumping my head against this problem where I need to add several keys for containers at creation time, but keep getting the above error on PVE 7.4 when doing it via the WebUI/GUI interface. What is the expression/criteria to match or make it work? Is it acctually supported? as it seems to...

There just isn't anything for ProxMox to respond about: LXCs doesn't and isn't expecting the get live migrations, it'll only be the Qemu/KVM VMs. PS: Does K8s supply live migrations? using which container tech?