Proxmox (Ryzen) GPU (ATI) passthrough to a existing VM with Debian

X

xvegax

Well-Known Member
Aug 12, 2019
38
0
46
43
Hi guys,

I have a Proxmox host with a Ryzen processor and one GPU, an old AMD card (R5 230 with TeraScale 2). I would like to pass the GPU through to a existing guest with Debian (64 bit), although I am not using the desktop there. I just need the card to be active and having a responsive driver for it. I checked several tutorials, but was not successful up to now.

Code: 
~$ pveversion -v
proxmox-ve: 6.4-1 (running kernel: 5.4.140-1-pve)
pve-manager: 6.4-13 (running version: 6.4-13/9f411e79)

Now, I would like to show my procedure and maybe someone can see, where I went wrong:

Code: 
~$ sudo vi /etc/default/grub
    GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt amd_iommu=on pcie_acs_override=downstream,multifunction video=efifb:off"
:wq

~$ sudo upgrade-grub

~$ sudo reboot

Code: 
~$ sudo dmesg | grep -e DMAR -e IOMMU
[    0.652105] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
[    0.653393] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40
[    0.653769] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 counters/bank).

Above seems to have worked.

Code: 
~$ sudo vi /etc/modprobe.d/blacklist.conf
    blacklist radeon
:wq

~$ sudo vi /etc/modules
    vfio
    vfio_iommu_type1
    vfio_pci
    vfio_virqfd
:wq

~$ sudo update-initramfs -u

Code: 
~$ sudo update-pciids

~$ lspci -v
09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos PRO [Radeon HD 7450] (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Caicos PRO [Radeon HD 7450]
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Memory at fcf20000 (64-bit, non-prefetchable) [size=128K]
        I/O ports at f000 [size=256]
        Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: vfio-pci
        Kernel modules: radeon
09:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM / R5 230/235/235X OEM]
        Subsystem: ASUSTeK Computer Inc. Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM / R5 230/235/235X OEM]
        Flags: bus master, fast devsel, latency 0, IRQ 4
        Memory at fcf40000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: vfio-pci
        Kernel modules: snd_hda_intel

~$ sudo lspci -n -s 09:00
09:00.0 0300: 1002:677b
09:00.1 0403: 1002:aa98

~$ sudo vi /etc/modprobe.d/vfio.conf
    options vfio-pci ids=1002:677b,1002:aa98 disable_vga=1
:wq

~$ sudo reboot

After that it should not show the Radeon driver anymore, I think, but it does:

Code: 
~$ lspci -v
09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos PRO [Radeon HD 7450] (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Caicos PRO [Radeon HD 7450]
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Memory at fcf20000 (64-bit, non-prefetchable) [size=128K]
        I/O ports at f000 [size=256]
        Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: vfio-pci
        Kernel modules: radeon
09:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM / R5 230/235/235X OEM]
        Subsystem: ASUSTeK Computer Inc. Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM / R5 230/235/235X OEM]
        Flags: bus master, fast devsel, latency 0, IRQ 4
        Memory at fcf40000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: vfio-pci
        Kernel modules: snd_hda_intel

So, I guess, there is my first problem, because it still shows Radeon.

Then I went to the existing Debian guest settings from Proxmox main menu and checked or changed these settings:

Code: 
Harddisk controller SCSI
CPU HOST
Network VirtIO
System/Machine q35

I rebooted the Debian guest and checked for the GPU, but it is still the generic one:

Code: 
~$ lspci -v | grep VGA
00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) (prog-if 00 [VGA controller])

So, what did I do wrong on the host or is there something still missing on the guest?

Thank you in advance.
 
Last edited:
Kernel driver in use: vfio-pci Kernel modules: radeon This is fine. It just tells you that it detected that radeon is a suitable driver and that the vfio-pci driver is actually used.

Please show the VM configuratiion file from the /etc/pve/qemu-server/ directory, so we can check the actual settings.
Don't use x-vga=1 (Primagy GPU in Promxox GUI) for AMD GPUs and set vga: none (Display to none in Promxox GUI) or use a virtual serial console for boot menu and messages. I don't expect a rebranded HD 7450 to show any output before the guest desktop is loaded.

Did you run update-initramfs -u after making changes to files in /etc/modprobe.d/ and reboot? Otherwise, they have no effect.
Did you make sure to stop the VM completely before restarting? Because a reboot from inside the VM won't update the VM configuration. Sometimes a passthrough will only work only once after the host is started. Try rebooting Proxmox before starting the VM.

EDIT: Some clarifications
 
Last edited:
Thank you for your reply. Alright, I just changed the disable_vga=1 to vga=none and rebooted the host.

Code: 
~$ sudo cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=1002:677b,1002:aa98 vga=none

Also, yes, after update-initramfs -u I rebooted the host (and with it the guests then), yesterday.

Here is the guest configuration:

Code: 
~$ sudo cat /etc/pve/qemu-server/103.conf
boot: order=scsi0;ide2;net0
cores: 8
ide2: local:iso/debian-10.0.0-amd64-DVD-1.iso,media=cdrom
machine: q35
memory: 4096
name: Exp
net0: virtio=02:07:EE:E6:45:EB,bridge=vmbr1,firewall=1,tag=167
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-103-disk-0,size=64G
scsihw: virtio-scsi-pci
smbios1: uuid=2aa2563f-ffb4-4143-9393-9c1142135770
sockets: 1
vmgenid: fc0d5a06-db00-419a-814d-a076a44af7ac

But still on the guest:

Code: 
~$ lspci -v
00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Red Hat, Inc. Device 1100
        Flags: bus master, fast devsel, latency 0
        Memory at fb000000 (32-bit, prefetchable) [size=16M]
        Memory at fea14000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at 000c0000 [disabled] [size=128K]
        Kernel driver in use: bochs-drm
        Kernel modules: bochs_drm
 
Last edited:
Sorry, I meant vga: none in the VM configuration or do it in the Proxmox web GUI. Keep the disable_vga=1 in /etc/modprobe.d/vfio.conf.
There is no hostpci entry in the VM configuration, which means no PCI passthrough. Maybe this explains why you don't see the GPU inside the VM? Are you sure this is the whole configuration file?
 
Okay, I changed vfio.conf back to disable_vga=1 and restarted the host.

Code: 
~$ sudo cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=1002:677b,1002:aa98 disable_vga=1

Also, I changed in the Proxmox webgui the vga/display setting to display: none for the guest.

Yes, this is the complete configuration of the Debian guest:

Code: 
~$ sudo cat /etc/pve/qemu-server/103.conf
boot: order=scsi0;ide2;net0
cores: 8
ide2: local:iso/debian-10.0.0-amd64-DVD-1.iso,media=cdrom
machine: q35
memory: 4096
name: Exp
net0: virtio=02:07:EE:E6:45:EB,bridge=vmbr1,firewall=1,tag=167
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-103-disk-0,size=64G
scsihw: virtio-scsi-pci
smbios1: uuid=2aa2563f-ffb4-4143-9393-9c1142135770
sockets: 1
vga: none
vmgenid: fc0d5a06-db00-419a-814d-a076a44af7ac

So, there is something missing there or on the host, that has to be added?
 
Last edited:
That explains why you do not see the GPU inside the VM: you did not add the device to the VM yet. You have prepared the system for passthrough, but not actually configured this VM to use passthrough. Add hostpci0: 09:00 to the VM configuration file (and have a look in the Promox GUI to see the PCI Device added to the Hardware tab of the VM).

You might also want to add:
serial0: socket vga: serial0 , instead of vga: none.
So you have a virtual serial terminal that you can access from the Proxmox GUI using the xterm,js console, and see the boot menu if the GPU does not display it on the connected physical display.
 
  • Like
Reactions: xvegax
Oh, thank you, I understand. So, I added what you mentioned, but somehow I cannot reach the guest remotely (using SSH) anymore. This is weird. It looks, as if the VM is not booting properly.

These are the settings from within Proxmox webgui:

1638025566561.png

The Proxmox webgui console shows this:

1638025638056.png
 
DId you reboot Proxmox just before starting this VM? That might help if the GPU does not (always) reset properly.
Did you run update-initramfs -u before rebooting the Proxmox host?
Can you try rebooting the Proxmox host and then start the VM (once)?
Is there any relevant information in the Proxmox Syslog (or journalctl -b 0 on the command line)?

PS: I forgot that you need to configure something inside the VM for the serial terminal as well: add console=tty0 console=ttyS0 to the GRUB_CMDLINE_LINUX_DEFAULT and add GRUB_TERMINAL=serial in /etc/default/grub and run update-grub. This can explain the empty terminal, but this is separate for the VM boot issue because of PCI passthrough you are having now. You'll need to make sure the VM boots normally, before you can make those changes.

EDIT: I doubt the R7 230 supports EFI and if it is the only GPU in the system, you'll need video=vesafb:off on the host (and run update-grub before rebooting). Note that you do not need amd_iommu=on because it is always on. I don't like pcie_acs_override but if your Proxmox host is not crashing or rebooting, I think this can stay until we have your PCI passthrough working.
EDIT2: Maybe it does support EFI and you'll might need to have both: video=efifb:off video=vesafb:off.
EDIT3: You'll might need to reinstall Debian, but try OVMF instead of SeaBIOS. This works for my older AMD GPUs.
 
Last edited:
Alright, I removed the hostpci0 entry on the guest in the Proxmox webgui and then I was able to reboot the VM and reach it again.

I changed this:

Code: 
~$ sudo vi /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet radeon.cik_support=0 amdgpu.cik_support=1 console=tty0 console=ttyS0"
GRUB_CMDLINE_LINUX=""
GRUB_TERMINAL=serial
:wq

sudo update-grub

I will change the next steps on the host in the next minutes.
 
Okay, changes on host are active now, too:

Code: 
~$ sudo cat /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Proxmox Virtual Environment"
GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt amd_iommu=on video=vesafb:off video=efifb:off"
GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/pve-1 boot=zfs"
:wq

sudo update-grub
sudo reboot

After a reboot the host is back and fine, but the guest will not come up until I remove the hostpic0: 09:00 entry from the guest configuration file. When I remove entry, I can reboot the guest and it is working.

radeon.cik_support=0 amdgpu.cik_support=1 on the guest was from my first attempts to get it running, as I did not know about the correct driver support. I have removed it now.

When I start the guest with the hostpic entry, I see this again:

1638030319794.png
 
Last edited:
On my system, all kernel parameters are in GRUB_CMDLINE_LINUX and only quiet is in GRUB_CMDLINE_LINUX_DEFAULT. Maybe that is needed to get the parameters actually applied?
You can check if your kernel parameters are applied by looking at cat /proc/cmdline.
If you installed Proxmox on ZFS, it could be that your system is using systemd-boot instead of GRUB. The manual describes how to check. Then you should make your changes in /etc/kernel/cmdline.

Is there any relevant information in the Syslog tab in the Proxmox GUI when you start the VM (and it fails)?

Have you tried using (the recommended, but don't use x-vga for AMD GPUs) OVMF (UEFI) for the VM instead of SeaBIOS? It probably wants you to add a EFI Disk as well. And maybe boot the VM from the Debian installer DVD, just to test.
 
Code: 
~$ sudo cat /proc/cmdline
BOOT_IMAGE=/ROOT/pve-1@/boot/vmlinuz-5.4.140-1-pve root=ZFS=rpool/ROOT/pve-1 ro root=ZFS=rpool/ROOT/pve-1 boot=zfs quiet iommu=pt amd_iommu=on video=vesafb:off video=efifb:off

It seems, the parameters were applied.

Code: 
~$ sudo efibootmgr -v
EFI variables are not supported on this system.

Grub is used on the host.

To be honest, I do not think a graphics card from 2013 is UEFI compatible, but let me ask you: Can I change an existing Debian guest from SeaBios to OVMF without an issue?
 
I use a HD 7750, which does not support UEFI, and it works fine with OVMF. Only no boot menu/messages but that's what the virtual serial console is for.

I do think AMD GPU's work better with OVMF but you might need to reinstall Debian. It needs an EFI Disk and a GPT partition table instead of MBR. If you know what you are doing, you might be able to convert an existing Debian, but it can be a lot of work and you'll need GParted Live for example.

Maybe you can boot the VM from the Debian installer DVD that is still in your VM configuration. Change the boot order of the VM and then you won't have to make changes to the VM disk. Then you can test whether you get an image on the physical display attached to the GPU.
 
Code: 
~$ sudo journalctl -f
-- Logs begin at Sat 2021-11-27 16:59:16 CET. --
Nov 27 18:10:20 rakete pvedaemon[17845]: start VM 103: UPID:rakete:000045B5:000683CA:61A2667C:qmstart:103:root@pam:
Nov 27 18:10:20 rakete pvedaemon[3056]: <root@pam> starting task UPID:rakete:000045B5:000683CA:61A2667C:qmstart:103:root@pam:
Nov 27 18:10:20 rakete systemd[1]: Started 103.scope.
Nov 27 18:10:20 rakete systemd-udevd[17851]: Using default interface naming scheme 'v240'.
Nov 27 18:10:20 rakete systemd-udevd[17851]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 27 18:10:20 rakete systemd-udevd[17851]: Could not generate persistent MAC address for tap103i0: No such file or directory
Nov 27 18:10:20 rakete kernel: device tap103i0 entered promiscuous mode
Nov 27 18:10:20 rakete systemd-udevd[17851]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 27 18:10:20 rakete systemd-udevd[17851]: Could not generate persistent MAC address for fwbr103i0: No such file or directory
Nov 27 18:10:20 rakete systemd-udevd[17852]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 27 18:10:20 rakete systemd-udevd[17852]: Using default interface naming scheme 'v240'.
Nov 27 18:10:20 rakete systemd-udevd[17852]: Could not generate persistent MAC address for fwpr103p0: No such file or directory
Nov 27 18:10:20 rakete systemd-udevd[17854]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 27 18:10:20 rakete systemd-udevd[17854]: Using default interface naming scheme 'v240'.
Nov 27 18:10:20 rakete systemd-udevd[17854]: Could not generate persistent MAC address for fwln103i0: No such file or directory
Nov 27 18:10:20 rakete kernel: fwbr103i0: port 1(fwln103i0) entered blocking state
Nov 27 18:10:20 rakete kernel: fwbr103i0: port 1(fwln103i0) entered disabled state
Nov 27 18:10:20 rakete kernel: device fwln103i0 entered promiscuous mode
Nov 27 18:10:20 rakete kernel: fwbr103i0: port 1(fwln103i0) entered blocking state
Nov 27 18:10:20 rakete kernel: fwbr103i0: port 1(fwln103i0) entered forwarding state
Nov 27 18:10:20 rakete kernel: vmbr1v167: port 5(fwpr103p0) entered blocking state
Nov 27 18:10:20 rakete kernel: vmbr1v167: port 5(fwpr103p0) entered disabled state
Nov 27 18:10:20 rakete kernel: device fwpr103p0 entered promiscuous mode
Nov 27 18:10:20 rakete kernel: vmbr1v167: port 5(fwpr103p0) entered blocking state
Nov 27 18:10:20 rakete kernel: vmbr1v167: port 5(fwpr103p0) entered forwarding state
Nov 27 18:10:20 rakete kernel: fwbr103i0: port 2(tap103i0) entered blocking state
Nov 27 18:10:20 rakete kernel: fwbr103i0: port 2(tap103i0) entered disabled state
Nov 27 18:10:20 rakete kernel: fwbr103i0: port 2(tap103i0) entered blocking state
Nov 27 18:10:20 rakete kernel: fwbr103i0: port 2(tap103i0) entered forwarding state
Nov 27 18:10:22 rakete pvedaemon[3056]: <root@pam> end task UPID:rakete:000045B5:000683CA:61A2667C:qmstart:103:root@pam: OK
Nov 27 18:10:22 rakete kernel: vfio-pci 0000:09:00.0: No more image in the PCI ROM
Nov 27 18:10:22 rakete kernel: vfio-pci 0000:09:00.0: No more image in the PCI ROM

It does not tell me much to start with, to be honest.
 
Reboot the Proxmox host and (try to) start the VM once with OVMF. Do you still get the vfio-pci 0000:09:00.0: No more image in the PCI ROM message?

EDIT:
Is the R5 230 the only GPU in the system? Can you use another GPU for the Proxmox host and make the system BIOS use that one?
Can your dump the ROM of the GPU (or find a compatible one on the internet) and specify that ROM-file in the hostpci configuration setting? See Step 4a (Optional): ROM File Issues here on hwo to do that (make sure to use your own PCI iD: 09:00.0).
 
Last edited:
Yes, the server has only this one GPU, unfortunately.

Also, yes, the vfio-pci 0000:09:00.0: No more image in the PCI ROM message came again, even when starting with OMFV BIOS and IDE2 (DVD-ROM/Image) chosen as first startup device.
 
xvegax said:
Yes, the server has only this one GPU, unfortunately.

Also, yes, the vfio-pci 0000:09:00.0: No more image in the PCI ROM message came again, even when starting with OMFV BIOS and IDE2 (DVD-ROM/Image) chosen as first startup device.
Click to expand...
Sound like you need a copy of the GPU's ROM from before it is initialized. See if you can get one via the link of my previous post.
 
Alright, this is it where it is now:

Code: 
vega@rakete:/$ sudo journalctl -f
-- Logs begin at Sat 2021-11-27 18:23:33 CET. --
Nov 28 01:33:51 rakete pvedaemon[7923]: start VM 103: UPID:rakete:00001EF3:00276797:61A2CE6F:qmstart:103:root@pam:
Nov 28 01:33:51 rakete pvedaemon[3190]: <root@pam> starting task UPID:rakete:00001EF3:00276797:61A2CE6F:qmstart:103:root@pam:
Nov 28 01:33:52 rakete systemd[1]: Started 103.scope.
Nov 28 01:33:52 rakete systemd-udevd[7932]: Using default interface naming scheme 'v240'.
Nov 28 01:33:52 rakete systemd-udevd[7932]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 28 01:33:52 rakete systemd-udevd[7932]: Could not generate persistent MAC address for tap103i0: No such file or directory
Nov 28 01:33:52 rakete kernel: device tap103i0 entered promiscuous mode
Nov 28 01:33:52 rakete systemd-udevd[7932]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 28 01:33:52 rakete systemd-udevd[7932]: Could not generate persistent MAC address for fwbr103i0: No such file or directory
Nov 28 01:33:52 rakete systemd-udevd[7929]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 28 01:33:52 rakete systemd-udevd[7931]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 28 01:33:52 rakete systemd-udevd[7929]: Using default interface naming scheme 'v240'.
Nov 28 01:33:52 rakete systemd-udevd[7929]: Could not generate persistent MAC address for fwpr103p0: No such file or directory
Nov 28 01:33:52 rakete systemd-udevd[7931]: Using default interface naming scheme 'v240'.
Nov 28 01:33:52 rakete systemd-udevd[7931]: Could not generate persistent MAC address for fwln103i0: No such file or directory
Nov 28 01:33:52 rakete kernel: fwbr103i0: port 1(fwln103i0) entered blocking state
Nov 28 01:33:52 rakete kernel: fwbr103i0: port 1(fwln103i0) entered disabled state
Nov 28 01:33:52 rakete kernel: device fwln103i0 entered promiscuous mode
Nov 28 01:33:52 rakete kernel: fwbr103i0: port 1(fwln103i0) entered blocking state
Nov 28 01:33:52 rakete kernel: fwbr103i0: port 1(fwln103i0) entered forwarding state
Nov 28 01:33:52 rakete kernel: vmbr1v167: port 5(fwpr103p0) entered blocking state
Nov 28 01:33:52 rakete kernel: vmbr1v167: port 5(fwpr103p0) entered disabled state
Nov 28 01:33:52 rakete kernel: device fwpr103p0 entered promiscuous mode
Nov 28 01:33:52 rakete kernel: vmbr1v167: port 5(fwpr103p0) entered blocking state
Nov 28 01:33:52 rakete kernel: vmbr1v167: port 5(fwpr103p0) entered forwarding state
Nov 28 01:33:52 rakete kernel: fwbr103i0: port 2(tap103i0) entered blocking state
Nov 28 01:33:52 rakete kernel: fwbr103i0: port 2(tap103i0) entered disabled state
Nov 28 01:33:52 rakete kernel: fwbr103i0: port 2(tap103i0) entered blocking state
Nov 28 01:33:52 rakete kernel: fwbr103i0: port 2(tap103i0) entered forwarding state
Nov 28 01:33:54 rakete pvedaemon[3190]: <root@pam> end task UPID:rakete:00001EF3:00276797:61A2CE6F:qmstart:103:root@pam: OK
Nov 28 01:34:07 rakete pvedaemon[8371]: starting vnc proxy UPID:rakete:000020B3:00276D8E:61A2CE7F:vncproxy:103:root@pam:
Nov 28 01:34:07 rakete pvedaemon[6651]: <root@pam> starting task UPID:rakete:000020B3:00276D8E:61A2CE7F:vncproxy:103:root@pam:

This is what I did:

Code: 
/$ cd /sys/bus/pci/devices/0000\:09\:00.0/
/$ sudo echo 1 > rom
/$ sudo cat rom > /usr/share/kvm/vgabios-asus-r5-230.bin
/$ sudo echo 0 > rom

/$ sudo mv /usr/share/kvm/vgabios-asus-r5-230.bin /usr/share/kvm/vgabios-asus-r5-230.rom

/$ sudo vi /etc/pve/qemu-server/103.conf
    hostpci0: 0000:09:00.0,romfile=vgabios-asus-r5-230.rom
    hostpci1: 0000:09:00.1,romfile=vgabios-asus-r5-230.rom (tried it with the second, too, as I read somewhere, the audio device should be used/taken with as well)
:wq

Also, I changed the boot order to the DVD image first and the BIOS to OVMF. It looks like the ROM not found message is gone, but still the guest is not booting up (or into the installation routine from the DVD image) without any special message in the logs, see above.
 
Don't do hostpci1: 0000:09:00.1,romfile=vgabios-asus-r5-230.rom. Instead use only one hostpci0: 0000:09:00,romfile=vgabios-asus-r5-230.rom (note the missing .0 or .1) which passes all functions (see the Promox GUI, PCI device, Advanced) of the device (with the ROM) toghether.

If sudo echo 1 > rom did not give an error message, then you were already root and don't need sudo (it only applies to echo 1 but you need it for the redirect > rom. Can you please check the size of the file to make sure?
I think getting the ROM from the GPU when it is used to boot the machine might be unreliable. I think you temporary need a second GPU or download a correct VGA BIOS.

The xterm.js console probably never shows anything when booting from the DVD. The R5 320 might not give a singal to the physical monitor until the radeon driver is loaded inside the VM. Also, you have no way to input any keys or clicks for the Debian installer. So it is unclear whether the VM freezes or if it is waiting on input. Maybe set vga: std instead of none, so you can watch the VM via the noVNC console (and give input).
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom