Search results

Do you mean that it appears as an unused disk? Maybe some element of the restore failed. Have you tried restoring again and ensuring that all disks that are required to boot are enabled? Especially pay attention to any systems that require multiple disks to boot? Please also note that this...

Do you notice any strange lines in the system log ('/var/log/syslog')? In particular any error or warning messages which repeat continuously? Are you able to SSH into the machine? Could you post the output of (when the GUI is offline): pveversion -v systemctl status pveproxy systemctl status...

Have you checked the "Boot order" option in the VM's "Options" panel to see if the primary drive is enabled and appears first on the list?

Yeah, a host reboot would also be an option (perhaps a better one). I just suggested restarting pveproxy, as some users are reluctant to reboot their system unless absolutely necessary. Let me know how it goes!

My second guess is that it's probably due to the authentication cookies having different formats, so the tool is trying to access the Proxmox Backup Server API with a cookie in the form "PVEAuthCookie=<cookie>" while it should be passing it in the form "PBSAuthCookie=<cookie>". Also note that...

The steps you mentioned here should work without any issues. Did you remove the 'local-lvm' storage from Proxmox VE too?

Have you tried restarting 'pveproxy'? systemctl restart pveproxy.service Are you sure that the IP address isn't in use anywhere else in your network?

I'm not at all familiar with node-red-contrib-proxmox or how it works, but a possible reason for the issue could be that the Proxmox VE API runs over port 8006 while the Proxmox Backup Server API runs over port 8007.

I'm assuming by PM 6 you mean Proxmox VE 6? In which case, Proxmox VE 6 generally works with PBS 2, however there are certain features that only work with Proxmox VE 7 such as single file-restore for VMs using ZFS or LVM on one or more of their disks. You won't lose any features by upgrading anyway.

Translated to: "I still don't understand the function of Prume, could someone explain it to me?" Pruning allows you to retain backups in a flexible and organised manner. Generally, as time goes on, the required interval between each backup grows. For example, let's say you have a VM that...

Okay, I understand why you want the ability, but yeah, the mapping needs to be 1:1 for the same reason the host system can't have a single user that operates under multiple usernames. Yeah, creating two users would be a good approach here. Alternatively, you could add both users to the same...

Have you tried any other means of connection other than just pinging it? I think that Windows ignores pings by default.

Hi, I don't believe this is possible, as acting as two users at the same time would have all kinds of strange implications. What are you trying to achieve with this configuration? Perhaps there's a better answer in another approach.

Happy to hear that you got it working in any case!

Great to hear it, and thanks for adding the guide! I should have thought to mention the 'group-filters' [1] in my answer, but good that you found it :) Note that you can also create a new sync job with the group filter enabled, rather than altering an existing one: proxmox-backup-manager...

Could you post the output of (from the readded node): pvecm status? mount | grep /etc/pve ls -l /etc/pve pveversion -v Could you try to run pvecm updatecerts --force on the readded node?

Hi Stefan, You can add a remote [1] with 'localhost' as the host name, then pull specific backups from one datatstore to another on a local machine. [1] https://pbs.proxmox.com/docs/managing-remotes.html

You could first create the ZFS at /mnt/datastore/vm-backups/pvecolo and create the datastore on top of this. Then configure a remote [1] using 'localhost' as the host and a user with with appropriate permissions, and pull the contents from the vm-backups datastore to pvecolo. Then after testing...

This seems like a pve-kernel-5.13.19-2 issue that we have seen with Window's VMs that have SATA disks attached. It has been fixed [1] in 5.13.19-3, so please do a full upgrade and reboot of your host system, to see if it resolves the issue. [1]...

Hi Jorge, What runs in the VM? Were there any tasks carried out on the VM (e.g., a backup) which triggered the error message? Did the VM go into a hung state or did it recover?