dcsapak's latest activity
-
dcsapak replied to the thread virglrenderer for 3d support.ah ok, the latest version of the patches are here: https://mail.gnu.org/archive/html/qemu-devel/2025-06/msg00011.html and they are not yet applied in qemu, so maybe in a later qemu 10.x release -
dcsapak replied to the thread virglrenderer for 3d support.that property (context_init) does not exist here, i'll have to look if there is some compile flag that has to be activated...
-
dcsapak replied to the thread virglrenderer for 3d support.i tested on the pve9 beta with kvm version:
-
dcsapak replied to the thread virglrenderer for 3d support.Hi, AFAIK one must add multiple new options for venus to work, according to the docs: `virtio-gpu-gl,hostmem=8G,blob=true,venus=true` (the 8G are just as an example) but i tried here on a test machine (with an radeon RX560 on the host and i...
-
dcsapak replied to the thread Regression. Cannot start VMs with kernel 6.8.12-12-pve and 6.14.8-1-bpo12-pve and pci-passthrough sr-iov X710 VF.note that a new package for the 6.8 kernel is already on pvetest, so no need to compile the kernel yourself
-
dcsapak replied to the thread Abysmally slow restore from backup.fyi, i'll probably look into doing similar changes to other parts of the code. e.g. i already sent a patch to try to improve verify speed: https://lore.proxmox.com/pbs-devel/20250707132706.2854973-1-d.csapak@proxmox.com/ it's not configurable...
-
dcsapak replied to the thread [SOLVED] Backup to Tape Warnings.hi, wenn das wirklich der einzige unterschied ist, ist es wahrscheinlich der grund. kritisch ist es nicht, daher nur die warnung Die fehlermeldung selbst sagt dass der changer/das drive gerade nicht 'ready' ist ist während dem backup job...
-
dcsapak replied to the thread Kernel 6.8.12-12-pve Update results in VFIO PCI passthrough issues.it's already applied in our git, so you could clone that repository, change to the appropriate branch and build it otherwise the patch could be applied with something like 'git am <path-to-file>' but since it's already applied, bumped and is...
-
dcsapak replied to the thread Kernel 6.8.12-12-pve Update results in VFIO PCI passthrough issues.just fyi, 6.8.12-13 (with the fix) should be up soon on the pvetest repository
-
dcsapak replied to the thread Regression. Cannot start VMs with kernel 6.8.12-12-pve and 6.14.8-1-bpo12-pve and pci-passthrough sr-iov X710 VF.just fyi, i sent a patch for this: https://lore.proxmox.com/pve-devel/20250722095659.79468-1-d.csapak@proxmox.com/T/#t
-
dcsapak replied to the thread NVIDIA vGPU Input/output error.just fyi, i sent a patch for this: https://lore.proxmox.com/pve-devel/20250722095659.79468-1-d.csapak@proxmox.com/T/#t
-
dcsapak replied to the thread Kernel 6.8.12-12-pve Update results in VFIO PCI passthrough issues.i sent a patch on the list that worked for me here: https://lore.proxmox.com/pve-devel/20250722095659.79468-1-d.csapak@proxmox.com/T/#t
-
dcsapak replied to the thread Kernel 6.8.12-12-pve Update results in VFIO PCI passthrough issues.just fyi: we're currently looking into this, and believe we have identified a commit (+possible fix) that's responsible, i'll send a patch later if it turns out that it fixes the issue
-
dcsapak replied to the thread NVIDIA vGPU Input/output error.hi, i can reproduce here with our current 6.14.8 kernel too. we're looking into this
-
dcsapak replied to the thread Cluster Tasks vs. node's Tasks History.ah ok i guess i see what's happening you connect to *-VPSLAB01 but the vm is on *-VPSLAB02 the console task is actually started on the node where you connect to, not the one where the vm is (the latter part of the connection is then tunneled to...
-
dcsapak replied to the thread Cluster Tasks vs. node's Tasks History.regarding the screenshot, that's interesting indeed. Does it show the task on the vm task history itself? Was the vm moved between hosts? (the task won't migrate with the vm, but stays on the host where it was started) can you open the status...
-
dcsapak replied to the thread Cluster Tasks vs. node's Tasks History.The cluster task list is distributed over the cluster file system, and to keep the load small, only a certain amount (i think 32k bytes, but i'm not sure, don't quote me on that ;) ) is retained there (otherwise it could grow quite quickly...