Search results

I woke up today with an odd cascade of events. First, one node of a cluster showed gray question marks for all objects. Interestingly enough the node showing all gray was also the one whose web console I was connected to. I rebooted the node and this issue resolved itself. Next, one LXC...

I think I have the same issue. For whatever reason after working perfectly for months, I am having this same issue. I have Docker in an LXC. There are two bind mounts into the LXC and then those are bind mounted into Docker containers. For whatever reason one bind mount causes this error and the...

You would want

Got it. So if I set to warn or error, successful jobs should not have output.

Are there descriptions as to how each log level behaves? Ideally in my case there would only be output for errors so would I use “error”? I don’t want to suppress all output with > /dev/null 2>&1 as I want an alert if a job fails.

It appears somewhere between 2.2.1-1 and 2.2.4-1 the output formatting changed. Specifically previously running a cron with proxmox-backup-client> /dev/null gave no output to cron. Now cron is picking up the output of proxmox-backup-client as it appears it shows as an error and/or not going to...

That's the ticket, thank you!

That is what I am using currently and it does snapshot the bind mount unfortunately. Also, when I restore the rootfs it appears to clobber the exiting bind mount with a new one based on the definition in the lxc.conf. Avoiding backup is easy as that is a check box in the GUI or by omitting...

I have an LXC container where I want to decouple the rootfs and a bind mount. I want to be able to backup, restore, and snapshot the rootfs completely separate from the bind mount. The bind mount I will then manage separately. The reasons being * The bind mount is huge. Backups via PBS take...

I figured with was more of a container issue as it was mapping. And indeed, chown 100034 worked a peach... though I will be waiting forever for .chunks to finish. Thanks!

Ah, I think I understand better and perhaps a better option is to chown 100034.100034 the dataset on the host?

I am trying to map a ZFS dataset into an LXC. The dataset is a PBS data set I am migrating from bare metal to LXC if that matters. I have read the docs here and there are a few assumptions that I am not understanding. In that article it talks about user ID 1005. Is that a real user? Like I...

Aha! Yes, indeed. That explains it. Thank you!

Strange. It ran a read job for every host that had a backup. There were no restores or the like happening at the time and it started at exactly 13:00... followed by many multiple read jobs - one per backed up host. See screen shots...

My PBS server is a running a huge number of "reader" jobs. They started at 13:00 today and I don't really have any idea what they are. Verification jobs are run hours earlier and all jobs show as OK. Any ideas what these jobs are? Example: 2022-03-29T13:39:22-04:00: starting new backup reader...

Ok, I have this figured out and the result is largely why I started this thread - every procedure I have found is incomplete or has major assumptions that may not be obvious. So, future Googlers, here is the deal. Do this is in this order on the respective nodes. NODE = the node that is getting...

I tried again and this is what I am getting in the syslog on a node in the cluster: Mar 18 13:31:29 pve-firewall2 pmxcfs[924]: [dcdb] notice: wrote new corosync config '/etc/corosync/corosync.conf' (version = 28) Mar 18 13:31:29 pve-firewall2 corosync[1044]: [CFG ] Config reload requested...

So run 'pvecm expected 1' on the node with the new IP? It will then get its new corosync.conf from the main cluster? And when you say HA, are you meaning if shared storage is used for VM failover? In this case, I don't have shared storage.

I ended up reinstalling to get the node back so the logs were lost. Let me be super sure I understand the process as it sounds like it *should* be easy. 1. On the node to have a new IP - Edit /etc/network/interfaces and /etc/hosts to reflect the new IP. /etc/hosts should ONLY have the new IP...

I have a situation where a "test" cluster moved to production out from under me and I need to get a few of the nodes proper IPs. I have a read a few threads here that seem to make it sound easy, but I am getting close to making a big mess. The one thread (this one) said to edit...