ghost82

I would use an utility such as gparted, you can download free a boot live iso. Create a new vm with the vdisk as a secondary disk, booting the gparted live iso. Then, partition the additional space and merge it to the actual 30G partition. Yes, you need to extend partition.

If you want to restore an image to a hd/sd card (bare metal): I would restore the image to the hard disk/sd card with dd. I would operate on the same pc booting from a live linux usb with the hard disk containing the vdisk and the empty hard disk/sd card. The empty hard disk/sd card must be grater or equal in size than the size of the vdisk. I would restore a raw image to the hard disk/sd card; if the image is in qcow2 format I would convert it to raw with qemu-img (you can do it in unraid): qemu-img convert -f qcow2 -O raw /path/to/vdisk.qcow2 /path/to/save/vdisk.img Then, use dd to restore the image: sudo dd if=/path/to/vdisk.img of=/dev/sdX bs=10M where sdX is the empty hard disk/sd card: this will restore all the partitions inside the vdisk image. -- On the other hand, if you want to run the vdisk on another box in a vm, simply copy the vdisk image, create a new vm pointing to that vdisk.

InjectAMD is a boot-arg you can add into the config.plist, but it's deprecated. Not all 7770 work in mac os, enable logging to file in opencore config.plist and maybe you will find where/why it hangs. Check that your gpu has uefi rom, or if you are using a vbios file check that the rom file has the uefi part. Apply multifunction for gpu in the xml.

As far as I know qemu isn't able to manage splitted vmdk files, but you can merge them into one vmdk. There should be tools available in internet.

see here: default menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label Unraid OS menu default kernel /bzimage append initrd=/bzroot video=efifb:off label Unraid OS GUI Mode kernel /bzimage append initrd=/bzroot,/bzroot-gui label Unraid OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode label Unraid OS GUI Safe Mode (no plugins) kernel /bzimage append initrd=/bzroot,/bzroot-gui unraidsafemode label Memtest86+ kernel /memtest Start "Unraid OS" (no gui) and that argument will be applied. If it doesn't work attach diagnostics I suggest to modify it from the unraid gui not the file: Main - Boot Device - Flash - Syslinux Configuration Modify the append line (all in the same line) of label "Unraid OS" like this: append initrd=/bzroot video=efifb:off and save and reboot.

Not much to say here...the xml seems ok. If I were you I would switch from i440fx to q35: fastest way is to create a new vm pointing existing disks; keep rotation rate and multifunction for gpu. If the vm hard crashes memory dumps should be created on the local disk (vm); in the past I used the WhoCrashed application to analyze these dumps, which was very useful to identify what was the issue.

gpu is in use by something else even if attached to vfio, most probably efifb, add this to your syslinux configuration: video=efifb:off

Not with the actual docker as it is. Mac os ventura can run in vm with updated opencore and kexts (you can set custom opencore image in the docker) and proper hardware (avx2 physical cpu).

agdpmod=pikera as a boot arg in opencore config.plist

video=efifb:off in syslinux configuration

Honestly I don't think any of the 6000 series card suffers from the amd reset bug, it could be most probably a user configuration error. Anyway we have the option to force load a different vbios in vms, so even if a 6000 series card suffers the reset bug we can force load a vbios that doesn't present the issue. For example, with my sapphire nitro+ se 6900 xt Ican load without any issue the vbios of a 6900xt reference card.

I have no idea but, you should set gpu as multifunction, as said: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x83' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/disk1/isos/vbios/m6000vbios.rom'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x83' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> Check bios settings, maybe you have some bios options that throttles pcie devices, like it happened here: https://forums.unraid.net/topic/129030-gpu-throttling-while-in-game-low-fps-low-gpu-usage/?do=findComment&comment=1175669 This is particularly true for hp servers, but I don't exclude that it happens with other builds. Check irq sharing issues with msi utility, there are relevant posts and the utility in this forum. @hot22shot suggests a change to the xml for large memory gpus, to expand the mmio address space to 64Gb, by adding this at the bottom of the xml before the domain closing tag: <qemu:commandline> <qemu:arg value='-fw_cfg'/> <qemu:arg value='opt/ovmf/X-PciMmio64Mb,string=65536'/> </qemu:commandline> </domain> Ref: https://forums.unraid.net/topic/129879-issue-with-windows-11-vm-rtx-3090-ti-passthrough/?do=findComment&comment=1182846

you missed multifunction for gpu. Then for proper gpu initialization you need agdpmod=pikera as a boot-arg in opencore config.plist.

Or just add to your existing vm the attached vdisk. - unzip the attachment, save it somewhere - add vdiskcert.img as a vidisk to your windows vm (raw) - step 6 of this post: https://forums.unraid.net/topic/128595-secure-boot-off-in-ovmf-tpm-bios-windows-11/?do=findComment&comment=1173154 - do step 7 - do step 8: for the selection "of the HD corresponding to vdisk.img" the disk will show up with label CERT, see following picture; inside there will be all the needed files. vdiskcert.zip

Post the original xml and the modified one; doubple check with the terminal that the paths to ovmf files are correct; press esc when running the vm to enter ovmf bios setup and rearrenge boot order, or boot from the ovmf setup page directly. The vars file contains only the micorsoft certificates, so any boot order saved in there is gone and needs to be rewritten (it's like you did a nvram/cmos reset).

I think this was what fixed things, now the embed gpu is primary, assigned as boot vga from the os. And efifb is assigned to the internal gpu 1:00.1 (it seems efifb is still used despite the boot arg and I don't know why..), so 84:00.x is really free: Nov 21 10:36:00 Tower kernel: pci 0000:01:00.1: BAR 0: assigned to efifb I think you can remove also boot arg video=simplefb:off Still remain a mistery for me why with only one gpu and video=efifb:off as boot arg, efifb attaches the same to the gpu...

First switch to xml view, copy all and save a backup copy somewhere so you can restore all things. Then download OVMF-2022-05-TPM-SECBOOT-ENABLED.zip, extract the archive and you will have 2 files: OVMF_CODE_SECBOOT.fd OVMF_VARS_SECBOOT.fd Save these files where you want, it doesn't matter the location, let's call '/path/to/' In the xml you have the os section with ovmf code and ovmf vars, change it to: <os> ..... <loader readonly='yes' type='pflash'>/path/to/OVMF_CODE_SECBOOT.fd</loader> <nvram>/path/to/OVMF_VARS_SECBOOT.fd</nvram> ..... </os> Save and start the vm.

Well...it depends, I don't find it too much complicated; if you want just to test if fifa 23 needs secure boot enabled to run (it seems a bit strange that a game requires secure boot....why??), download and use the OVMF-2022-..... files attached in my post above and point the vars/code files to these files in the xml. About security concern of the private key, well, unless you are not the cia or some sort of secrecy agency with secrets of billion of dollars in your pc, you could stay safe.. With the private key I can build uefi malware injected in the bios and I can install this modified bios and since the certificates are still valid the malware will be injected. But....I need local access to your pc, or I need to send you the modified bios and you install it: you can understand that both options are a no go I could have already modified the attached files with malware, well.. I did not I'd try to find a tool to be able to inject certificates into the vars file without having to use a vm to start the ovmf setup, but my searches found nothing. If there was a tool like this, all could be easier since I think that the certificate can be created on unraid itself. However I think that a docker could be created quite easily even if a basic vm is needed to be run for certificates injection.

Yes, unfortunately this was expected. Now it tries to passthrough the device but when the rom is force loaded the mess begins...good choice, sell that card.

None of them!! you need to dump it in some way from your card.. But you should not need it, just use rom bar=on

maybe...but for it to be passed through you need to force load the rom in one of the 2 ways I described, since the blacklist is still hardcoded into qemu.

In my opinion, yes, quoting from the launchpad link of my first reply:

It's a problem of incompatibility between your network card and qemu, which unraid includes for virtualization (but the issue is in the rom/firmware of that broadcom device). So even if you switch to any other linux distro, like manjaro, arch or whatever you want, and you use qemu for virtualization you will get the same error.

You have the audio part of the gpu on irq 22 (same as network controller), put a checkmark on high definition audio controller, apply and restart. Not sure it will solve the issue, worth a try, and anyway it's the proper setting to avoid any conflict and audio lags.

By IRQ I mean interrupt requests. I'm talking about things happening inside the same virtual machine. Inside a bare metal pc, as in a virtual machine, devices talk to the cpu (real or emulated) through irq. IRQs have a number assigned. Some devices may share the same IRQ, there's nothing wrong most of the time, but if 2 devices like a gpu and a network controller share the same irq there will be too much traffic and you may experience lags. If the device and drivers support it, luckily you can switch from irq to msi (message signalled interrupts); this will give a negative and unique number for the irq. Extract the attached file and run it as administrator. As an example, this is my device list: Let's say your network controller is my Red Hat Virtio ethernet adapter. What you need to check: 1. Check if there is a checkmark for the network controller, under msi; if there is, stop here the issue is elsewhere 2. If there isn't a checkmark check in the irq column that the number is not shared with anything else, if it's not shared stop here the issue is elsewhere 3. If the irq is shared and there isn't a checkmark in the msi column, under msi, put it, click apply, restart the vm, and see if things are better. -- In general check for other irq shares and apply msi on devices that support it (msi is supported if it is in the "support modes" column) to avoid irq sharing. As you can see I applied msi to several devices to avoid irq sharing. All usb controllers, emulated and passed through do not support msi, but luckily they have independent irqs: 22, 21, 20, 23. Please note that enabling msi on non supported devices or on devices with bugged drivers may cause the vm to not boot...I would think twice before applying msi to a passed through sata controller to which the boot disk is attached... MSI_util_v3.zip