Search results

for the Debian security repository, changelogs used to not be published on the metadata server until they were imported into the next stable point release. it seems to have been improved, but there might still be some delay between package upload and metadata import, since security uploads are...

there's a bugzilla entry referenced earlier in this thread: https://bugzilla.proxmox.com/show_bug.cgi?id=5267 you can add yourself to the CC list of that bug, then you'll get an email when its status changes (like a proposed patch being applied, or it being included in a released package).

not necessarily - `ntfs` and `ntfs3` are totally different drivers kernel side..

I wonder if the FS in question is somehow unclean and the ENOENT is just a badly bubbled up error..

is there anything in dmesg after you try mounting on the host with ntfs3? which kernel version are you running there?

no, the locking is on our side, and it is currently a global lock per shared storage for certain tasks - the linked issue is about improving that by reducing the scope of the lock. there are basically two (related) causes/issues: - lock contention/failure to acquire the lock at all (too many...

I'm aware of that one, but I don't think anybody started working on implementing that enhancement yet.

no, it sounds like there is some issue with the performance of your ceph storage..

you seem to have fixed or worked around your issue, but for future reference: switching to proper PCI mappings avoids this issue (since you can point the entry on the target system to match the hardware, and don't have to encode PCI slots/.. in the VM config).

simply use `proxmox-backup-client` on the remote system to prune the sync source, just like PVE does when it is managing the pruning client side.

preallocation only has an effect for directory based storages (dir, nfs, cifs, ..)

you are trying to start a VM configured to use a CPU type that requires features (AESNI) that your physical CPU doesn't have. change the CPU type, then it should start.

also, it's fairly easy to work around this if you have raw access to the datastore - create a new namespace, sync all snapshots into that (already existing ones are basically free, since only the snapshot metadata will be synced), then merge back the vm/XXX dirs into the original namespace (just...

it follows the same principle as doing backups - it's dangerous to allow filling in slots between already existing backups by default, since that would allow stuffing the backup group with invalid snapshots in a way that the next prune would remove all valid ones.. a new sync mode that allows...

could you post the full log file and the VM config from the backup?

please subscribe to the BZ entry -> you'll get notified on status changes then.

no, we still want to get rid of SSH for internal usage (or split it off from the default instance), without further complicating the setup using certificates.

missing chunks are possible if your manual sync processes files in the wrong order.. that's why we have a built-in sync that ensures indices and chunks are processed in a logical fashion ;)

yeah, you can try with criu, lxc-checkpoint or pct suspend (in order from low to high level, but pct suspend is basically just combining locking and calling lxc-checkpoint) and you will pretty much find out that any regular container is not working.. note how the example in the wiki is using a...

literally 9 out of the first 10 open issues (from the last 2 months!) are about checkpoint or restore crashing or failing. it has (admittedly) been a while since I personally tested it, but the issue is not so much with the implementation, but the general concept - there is no abstraction layer...