Search results

I understand that /etc/pve is critical. However mention has been made of /var/lib/pve-cluster. Whilst it appears to store config data, I was under the impression it was part of the running state of PVE and not critical to backup. Is that correct? I have not yet used my backup to restore on top...

Some of these solutions seem over complex to me but I may be missing something. My PVE host backup strategy has been to create simple backup archives that are easy to use should I need to selectively restore config: rsnapshot /etc/ (one_fs=0), /root, /usr/local (where I try to make a point to...

For some foolish reason I was only looking at the headers for a TLD. I found the culprit in the message body.

I've a few emails that score with: KAM_SOMETLD_ARE_BAD_TLD 5 .bar, .beauty, .buzz, .cam, .casa, .cfd, .club, .date, .guru, .link, .live, .online, .press, .pw, .quest, .rest, .sbs, .shop, .stream, .top, .trade, .work, .xyz TLD abuse However I don't see where the emails concerned match this...

Yes, I do. No errors. INFO: HOOK: job-end INFO: HOOK-ENV: dumpdir=/mnt/pve/omv-backup/dump;storeid=omv-backup; INFO: HOOK: storage: nfs /mnt/pve/omv-backup INFO: HOOK: job-end umounted /mnt/pve/omv-backup INFO: Backup job finished successfully

Well I don't think the directory ever gets unmounted. When I run the backup, whilst running another shell in the mounted fs, no errors occur. Ordinarily attempting to umount it under those circumstances should fail. I'm going to keep plugging away and may redo the hook script with bash rather...

pvesm status shows the store as disabled once job completes and I can successfully umount the NFS export (manually using umount directly or running relevant perl snippet from the hookscript). Here are relevant parts of config and journal output as well as mounts before and after job runs: #...

It seems umount, called from the hook script, has no effect. That, or the pve daemon immediately remounts it for some reason. The system call to umount in my hookscript (job-end phase) is successful in so far as it returns success (0). However checking mount and directory listing after the job...

I felt wrong invoking perl via system from within a perl script. Incidentally after posting I just found I could do this my $cfg = PVE::Storage::config(); my $fstype = $cfg->{'ids'}{$storeid}{'type'}; my $mountpoint = $cfg->{'ids'}{$storeid}{'path'}; but haven't tested anything. However I'm...

I just realised that disabling storage does not umount the NFS volume. Now I am attempting something like this in my hookscript: if (($phase eq 'job-end') || ($phase eq 'job-abort')) { my $mountpoint = system ("pvesh get storage/$storeid --noheader 1 --noborder 1 | grep ^path | awk...

Just what I need. I had no idea you could set script on specific jobs. Many thanks!

Thanks. I look forward to it. So once implemented, absence of a shedule will mean we can infer it was run from the web UI or cmdline. This was my first experience with PVE hooks. I wanted to (un)mount remote storage on demand. But not unmount if the script had been invoked via non-scheduled backup.

Within a vzdump hook script, how can I differentiate scheduled backups from those run interactively via the web UI? There doesn't appear to be anything in env I might use to do this.

By the way that is not a kernel bug. It's a BIOS issue. Actually that post mentions a way of disabling specific ACPI methods. There might lie your solution.

In my experience, yes. And if these only appear when you disable devices on the mobo, I'm guessing even more harmless. It seems many of these boards' firmware are written with windows in mind rather than a complete and correct implementation. Usually, all the annoying errors/warnings appear at...

I like your 'fix' ;-) These ACPI method warnings are fairly common IME. More so on older boards and when you disable an onboard device. Most of the time they are harmless and usually down to the board vendor's ACPI implementation. I see them on my PVE host every time i power on a SATA hotplug...

The host/network address determines routing. With a /32 subnet, the host will expect all traffic to go via the gateway. This is fine for hosts that are the other side of the gateway but will/may impact its communications with neighbouring hosts. You have the perfect tool to test all this! Create...

There's nothing wrong with it. I pointed it out because it is less usual and may not have been intentional.

Also note the netmask in your container config: ip=192.168.2.49/32

The container PID 467 (port 3000) is listening on loopback interface.