Search results

I was trying to figure out how to delay the startup of VMs & containers and happened upon this little script (used by the pve-guests.service): /usr/share/pve-manager/helpers/pve-startall-delay #!/usr/bin/perl use strict; use warnings; use PVE::INotify; use PVE::NodeConfig; my $local_node =...

Also interested in what @Lioh uncovers, as we have a similar situation at work with users sourced from Active Directory, and most day-to-day operations can be achieved via non-root users. Root via local ssh is always a fallback for any advanced configuration changes or diagnostics. Seems like...

According to the APC manual, apcupsd is looking for nodes in /dev/usb/hiddev*. So, you may want to try passing that through instead of /dev/bus/usb/xxx/yyy. I finally got this working for my APC Back-UPS XS 1500G after doing the following: On the host: chown root:100000 /dev/usb/hiddev0 chmod...

Nevermind, I found an example of how to determine VM/LXC type in API2/BackupInfo.pm: my $vmlist = PVE::Cluster::get_vmlist(); my $type = $vmlist->{ids}->{$vmid}->{type}; my $node = $vmlist->{ids}->{$vmid}->{node}; my $conf; my $name = ""; if ($type eq 'qemu') { $conf =...

Thanks for that, works great! How would I adapt the script to handle both LXC and VMs? I have used this script on both. I see the equivalent perl module under /usr/share/perl5/PVE/LXC/Config.pm, but not sure how to check which one to use based on $vmid.

I have a VM that has a snippet configured with pre-start and post-stop actions. The VM is currently stopped. When my backup job runs (which includes all VMs & containers), the pre-start action in the snippet is executed. Is this intentional? How do I distinguish between pre-start due to...

Did you edit /etc/subuid and /etc/subgid on the host to include the mapped user id you want to use? By default, only user ids 100000-165535 can be mapped. I think this is what the wiki indicates to do, but it wasn't clear to me at first. I thought it was saying to edit subuid & subgid...

Good to know there are others doing PBS in a container. I arrived at the conclusion that I needed to do this after banging my head against how to get better throughput on a host-guest shared folder. 9p, NFS, and SMB all proved vastly inferior to bare-metal and LXC bind-mount performance.

I would hope that verifying multiple snapshots that have few incremental changes in succession would result in only marginal increases in verification time (we are verifying the chunks themselves, no?). If this is true, then it seems it would be better to run verifications in batches rather...

Thanks, this is the approach I took with my own 100% full backup drive. Seems to work just fine, although I'm still running the verify job after garbage collecting & moving chunks back.

API token is a good alternative to using root for backups. You can limit permissions that way.

My LXC is hosted on a local ZFS dataset.

No, I'm not using an encrypted ZFS dataset. I only have the same issue with regard to not starting up the container after reboot, with the same error message, "Permission denied - Failed to create "/dev" directory". I think the issue I had could also present itself with encrypted datasets.

Thanks for the confirmation. I ended up hosting ISOs, templates, snippets inside a container.

Thinking back to how this might have happened in the first place, I vaguely recall creating a Directory storage on top of a ZFS file system, so that I could store backups, snippets and ISOs on a ZFS-backed file system. However, I think this can result in the creation of the requisite paths if...

Figured it out - my zpool mountpoint path existed on the root file system, preventing the pool from mounting at all. To solve this once and for all, I issued this command (after stopping all containers/VMs): zpool export tank && rm -rf /tank This cleared out any existing directory structure on...

After trying yet another workaround for this, I found simply mounting the ZFS subvolume allowed me to start the container: zfs mount tank/vm-dev/subvol-100-disk-1 pct start 100

I am also experiencing this issue, using pve-container 3.2-2. In my case, I do not even see a "/dev" directory in the mounting path. I am able to use the workaround described above (delete mounting path and use "zfs mount XXX"), but this is not a good long-term solution. Here are the relevant...

I just encountered this issue as well. What worked for me was the following: Delete the (empty) subvol mount point: rmdir /tank/vmdata/subvol-100-disk-0 Mount the ZFS filesystem: zfs mount tank/vmdata/subvol-100-disk-0 This seems like a workaround, and I'm still not sure what the root issue...

I do not run a custom shell, as far as I know. I think I found the issue. I had zed.rc configured with this option: ZED_EMAIL_PROG="/usr/bin/pvemailforward" Another server I have set up uses this: ZED_EMAIL_PROG="mail" Not sure why I changed that setting, but using mail as the email program...