Search results

fixing a full datastore...oops!

I've run into this before and moving chunks off the datastore, running garbage collect, and restoring them afterwards is what resolved it for me. Currently doing this again, as I accidentally doubled-up on an encrypted backup set. Note: You will see a bunch of warnings related to missing...

Thanks for the prompt response! I've attached the requested files, zipped up. There are many ZFS operations resulting in failed: got timeout, mostly if not exclusively occurring during backup jobs.

I routinely get replication job failures between the hosts in my 2-node Proxmox cluster. I have grown accustomed to ignoring them as they always recover on the next run. Is there a way to avoid these failures? I'm thinking of staggering the replication schedule between the two hosts, as they...

List active tasks: root@host:~# cat /var/log/pve/tasks/active UPID:host:12345678:90ABCDEF:FEDCBA09:vzclone:133:root@pam: 0 UPID:host:DEADBEEF:FEEDBAC4:09876543:vzsnapshot:133:root@pam: 1 12345678 OK ... Identify task's "sorting character" - the last digit of the task's unique reference string...

My Traefik container now runs much faster and makes Nextcloud more bearable! Thank you

I think I figured this out, thanks to some more searching and finding these posts: https://www.reddit.com/r/Proxmox/comments/i9xfoj/hotplugging_passthrough_usb_devices_to_lxc/ https://monach.us/automation/connecting-zwave-stick-under-lxc/...

This would modify permissions only for the endpoint that matches the rule spec (SUBSYSTEMS, KERNEL, PID, VID). The Bus/device IDs can change based on where the device is plugged in (or even after a reboot? Not sure), so I'd avoid depending on them. The way I understand the hierarchy is that...

I have two systems with a UPS connected via USB, which I pass-through to an LXC container with the corresponding management software (apcupsd, pwrstatd). However, on both systems, I have a problem if the USB connection is ever disconnected - the LXC container can no longer read the USB...

I think the more typical way to do this is to use udev rules. Or at least that's what I do for my UPS management container. I created the following file: /etc/udev/rules.d/50-apcups.rules SUBSYSTEMS=="usb", KERNEL=="hiddev*", ATTRS{idVendor}=="051d", ATTRS{idProduct}=="0002", GROUP="100000"...

I ran into this issue on a backup with multiple disks, which each had the @vzdump snapshot. I was able to delete all of them using: zfs destroy -r tank@vzdump Maybe there could be an option to automatically destroy any existing @vzdump snapshot prior to backup. I've had this happen several times.

Got it to work with pve-guests.service, but I did have to add a delay (using ExecStartPre) to give the mail server time to start up. Here's my final config (which successfully delivers mail for both start & shutdown): [Unit] Description=Send email at system Start and Stop Wants=postfix.service...

Another wrench in this is that my mail server may be running in a container on the host, so I would also want to start this systemd service after VMs & containers have started. Which service is that? lxc.service, pve-guests.service?

Looks like in @Stoiko Ivanov 's patch here, pve-cluster is modified to start before the MTA. So, my example above could be changed to only depend on the MTA (postfix)?

Piggy-backing off this thread: https://forum.proxmox.com/threads/pvemailforward-loses-emails-if-mail-server-is-not-available.108893/post-495825 How should I set up the dependencies for a systemd service to ensure mail delivery during startup & shutdown of the system? From the thread linked...

Glad you were able to reproduce! I'm going to piggy back off this discussion in another thread to answer my other question about how to configure a systemd service to guarantee mail delivery during startup/shutdown (as far as the system dependencies are concerned).

Interesting. So you're saying that if the cluster file system is not available when postfix is started, pvemailforward doesn't know where to forward the mail? That makes sense to me. Can this be fixed simply by returning an error code to postfix? I've attached the boot log from the journal...

I've run into this issue as well, trying to send an email at startup & shutdown. pvemailforward fails with the same "Connection refused", even though the mail server is up. This occurs during system boot-up; it's picking up an email sent when the server shutdown (need to figure out how to send...

Thanks! I was unaware of the pvenode command.

Figured it out (easy to test - just run the script!). For a delay of 10 seconds, I added the following line: /etc/pve/nodes/<node>/config startall-onboot-delay: 10