Search results

true, this is definitely improvable ;) also true. It's on my todo list for a while now to improve this situation, but I did not have enough time yet to think about possible solutions

That is currently not implemented, but a good idea! would you mind opening a feature request here? https://bugzilla.proxmox.com

see the docs here: https://pbs.proxmox.com/docs/tape-backup.html#tape-drives e.g. if you have a changer with 4 drives, we need to uniquely identify the drives inside, and we do that by the numbering the changer gives the drive theoretically we could try to identify them by their serial...

Hi, not sure if that was intended when we introduced removable datastores. Best to open a bug/feature request on https://bugzilla.proxmox.com Either we should make it configurable (per job maybe?) or we should not throw an error in that case.

no i meant, we'd have to have a consistent way of changing the ids of our existing devices to other slots, for example, when using the default vga setting we add a vga device at 0x2: -device 'VGA,id=vga,bus=pci.0,addr=0x2 so let's say you want to use this address in the config for e.g. a usb...

Hi, AFAIR this was done because the experience with virgl + spice is vastly better than with novnc i guess what would be better is a per vm console option instead of a global one? not sure about that though....

no problem! yes that should work, note that the changes will be overwritten when you install new versions of the packages. i'll update the bug report when the patches are applied and when they're packages also the change should be included in the changelog of the packages

it's not applied yet, so first a colleage of mine has to review the patches, then they have to be applied to our git repository. then when the package is bumped the next time will it started to be rolled out through our repositories i'll see that i can accelerate it a bit, but i can make no...

it's probably due to some nodes not on the most current version? the api to query the models recently gained the ability to use a mapping in addition to give a pciid directly, so my guess is that when you get the error those nodes are not on that version yet you can verify that by comparing the...

actually after thinking a few seconds more about it, i have a theory: It may be the case that the api daemons are started with '/' as their current working directory, so every command they execute have also that as their cwd. In that case, the 'sys/bus....' relative path can be resolved if you...

mhmm i doubt it would simply work over the gui, since that does the same thing as starting the guest via the cli, but who knows what exactly happened there... well, it's absolutely no bad thing to follow the documentation, in this case there was simply more documentation you didn't know ;) the...

can you post the full vm config and resource config in text format? qm config ID cat /etc/pve/mapping/pci.cfg also I need the full output of a failed task log please maybe also a journal output since boot, otherwise it's hard to diagnose what actually happens

well the most correct way would be to checkout the two repositories with git, then use `git am <path-to-patch-file>` to apply them and use `make deb` to build the packages. if you want to go that route, i'd recommend reading the developer docs...

ok, how long would you say takes a vm start until it's booted? two things you could try here: enable hugepages in the config, this could help if the limiting factor is main memory allocation, this can be slow if the memory on the server is very fragmented or there is little memory free load a...

first, please in the future, post text as text and not as images (it becomes much harder to see, especially since the images are so large ;) ) also can you post your resource mappings + vm configs and the full output of `lspci -nnk` (as text please) as far as i can see it tries to use the...

interesting, can you post the whole vm config and the task start log ? also is there a reason why you pass the card through with the 'args' parameter instead of using the builtin method? you should be able to create a pci resource mapping for all virtual functions, and then use that in the vm...

Hi, sorry yes. It seems the way we parse does not match the output you posted, which is very probably related to this version would you mind opening a bug on https://bugzilla.proxmox.com/ with the smarctl output posted from above and additionally the output of smartctl -H -A -f brief...

Just fyi: i just sent a patch to silence those (informational) perl warnings: https://lore.proxmox.com/pve-devel/20250519144357.3515197-1-d.csapak@proxmox.com/T/#u as for your migration speed problem, even if you have much free memory, it might be heavily fragmented which can impact allocating...

please don't simply bump without new information, this will not make answering any faster... that said, what kernel version do you currently use? this sounds like an issue that more recent bios+efi versions brought in and should be mostly fixed in current kernels, so a current 'pveversion -v'...

as I said, proxmox ve does not modify the disk contents. If the guest os changed some config after migration, you have to investigate inside the guest to find out why the config is not carried over