Jump to content

ghost82

Members
 View Profile  See their activity

  • Posts

    2,726

  • Joined

  • Last visited

  • Days Won

    19

 Content Type 

Posts posted by ghost82

    Virtual machine log alarm

    in VM Engine (KVM)

    Posted · Edited by ghost82

    Basically, it means that qemu detected a device that it wont work when passed through to a vm (vfio) and automatically notify you and disabled it for the virtual machine.

     

    --

    Looking at the qemu source code, it seems your device has broadcom BCM 57810, or a device with vendor 0x14e4, id 0x168e: 

        if (vfio_opt_rom_in_denylist(vdev)) {
        if (dev->opts && qdict_haskey(dev->opts, "rombar")) {
            warn_report("Device at %s is known to cause system instability"
                        " issues during option rom execution",
                        vdev->vbasedev.name);
            error_printf("Proceeding anyway since user specified"
                         " non zero value for rombar\n");
        } else {
            warn_report("Rom loading for device at %s has been disabled"
                        " due to system instability issues",
                        vdev->vbasedev.name);
            error_printf("Specify rombar=1 or romfile to force\n");
            return;
        }
    }

     

    Your case is inside the else block.

     

    The "deny list" is specified here, together with the explanation of why they included that device: 

    /*
 * List of device ids/vendor ids for which to disable
 * option rom loading. This avoids the guest hangs during rom
 * execution as noticed with the BCM 57810 card for lack of a
 * more better way to handle such issues.
 * The  user can still override by specifying a romfile or
 * rombar=1.
 * Please see https://bugs.launchpad.net/qemu/+bug/1284874
 * for an analysis of the 57810 card hang. When adding
 * a new vendor id/device id combination below, please also add
 * your card/environment details and information that could
 * help in debugging to the bug tracking this issue
 */
static const struct {
    uint32_t vendor;
    uint32_t device;
} rom_denylist[] = {
    { 0x14e4, 0x168e }, /* Broadcom BCM 57810 */
};

     

    To force loading loading the rom you need to specify romfile in the xml of the vm, like you do with a vbios for a gpu passthrough: 

    <rom file='/path/to/romfile.rom'/>

    inside the hostdev block.

     

    Or, (I think), force loading rom with: 

    <rom bar='on'/>

    inside the hostdev block.

     

    but are you sure you want to pass it even knowing it could cause issues?If the blacklist is hardcoded into qemu I would not modify it...

    Can't get GPU pass through to work as I need!

    in VM Engine (KVM)

    Posted · Edited by ghost82

    If you can't fix it by changing some options in bios, what about buying a hdmi dummy plug and attaching it to the igpu?

    If you have a second monitor, or you have a friend with a monitor, you can try to attach one to igpu and one to the gpu passed to the vm, if it will work, it will work with the dummy plug too.

    GPU Passthrough not working after updating to 6.11.5

    in VM Engine (KVM)

    Posted 

    Nov 24 16:04:25 Tower kernel: pci 0000:11:00.0: vgaarb: setting as boot VGA device

    you need vbios passed

      

    Nov 24 16:04:25 Tower kernel: pci 0000:11:00.0: BAR 0: assigned to efifb

    you need video=efifb:off in syslinux

     

    54 minutes ago, Dismes said: 
        <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x11' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x11' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x11' slot='0x00' function='0x2'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x11' slot='0x00' function='0x3'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/>
    </hostdev>

    Multifunction should be setup for gpu passthrough

     

    55 minutes ago, Dismes said: 
    machine='pc-i440fx-6.2'

    q35 should be preferred instead of i440fx.

    Why pflash rather than rom?

    in VM Engine (KVM)

    Posted

    Hi, this is a reply from Laszlo, one of the most important maintainers of the edk2 firmware.

    Question:

    >> My question is, what happens from a firmware initialisation perspective if >> edk2 is passed as a bios rom instead of as pflash?

     

    Reply:

    Quote

    Sure.

    The OvmfPkg/README file has a section called "OVMF Flash Layout". It
    explains where / how the unified (OVMF.fd) image is mapped just under
    4GB in guest-phys address space.

    (1) If you map the unified image with -bios, all of that becomes ROM --
    read-only memory.

    (2) If you map the unified image with -pflash, all of that becomes
    read-write MMIO.

    (3) If you use the split images (OVMF_CODE.fd and a copy of
    OVMF_VARS.fd), and map then as flash chips, then the top part
    (OVMF_CODE.fd, consisting of SECFV and FVMAIN_COMPACT) becomes read-only
    flash (MMIO), and the bottom part (copy of OVMF_VARS.fd, consisting of
    FTW Spare, FTW Work, Event log, and NV store) becomes read-write flash
    (MMIO).

    (4) If you use -bios with OVMF_CODE.fd only, then the top part will be
    ROM, and the bottom part will be "black hole" MMIO.

    Option (4) is totally invalid.

    Option (3) is the best solution and it is what everybody should use (the
    virt stack / libvirt already uses that).

    Option (2) is acceptable, but it's suboptimal from a firmware binary
    update POV -- you cannot replace your binary without losing your variables.

    Option (1) is the ancient relic that once (before qemu-1.6) used to be
    the only option. When you use Xen, this is the only option still today.

    OVMF contains detection code that tells apart case (1) from the set {
    case (2), case (3) }. (Cases (2) and (3) in the latter set look
    indistinguishable to the firmware, by design.) If pflash is detected,
    then you get a UEFI variable service implementation that conforms to the
    UEFI spec, and everything will work fine. If, however, case (1) is
    detected, then OVMF switches to a kind of variable store "emulation", where:
    - variables (even non-volatile variables) primarily live in RAM only,
    - a file called \NvVars on the EFI System Partition (a FAT filesystem)
      contains a serialized image of the variables,
    - when booting the VM, \NvVars is de-serialized into RAM,
    - until the OS is launched, variable changes (initiated from the
      firmware), are synched out to \NvVars at once,
    - after the OS is launched, variable changes remain only in memory,
    - if you gracefully reboot the VM into the firmware, then OS-initiated
      variable changes are synched out to \NvVars,
    - if you power down the VM from within the OS, you'll lose any
      OS-initiated variable changes
    - Another limitation is that some kinds of variables cannot be
      serialized and de-serialized like this; in particular variables
      related to Secure Boot.

    Unfortunately this detection logic is extremely prone to mis-use (and
    esp. it was never meant to deal with case (4)) and to causing confusion.
    For this reason, I have had patches for a long time now that allow the
    user to compile "-bios" support out of OVMF, with a build flag
    (-DMEM_VARSTORE_EMU_ENABLE=FALSE). Then you will simply become unable to
    boot with "-bios" -- the firmware will just hang with a black screen.
    (If you capture the debug log (see OvmfPkg/README), you'll know what's
    up though.) Note that this would not be the default -- the default build
    wouldn't change.

    Firmware built like this is much better to use on QEMU (much less room
    for error, and there are some firmware features that become possible --
    the UEFI memmap will be de-fragmented over time, and the foundation for
    S4 support, i.e., suspend to disk, is laid).

    In particular if you build OVMF with -DSMM_REQUIRE, then "-bios" support
    is *already* compiled out. (If you use OVMF on Xen, then your only
    choice is option (1) (because Xen does not implement flash), so OVMF
    binaries built with either -DSMM_REQUIRE, or my (proposed)
    -DMEM_VARSTORE_EMU_ENABLE=FALSE flag, will not run on Xen.)

    My work related to -DMEM_VARSTORE_EMU_ENABLE=FALSE can be seen in
    <https://bugzilla.tianocore.org/show_bug.cgi?id=386>.

    You might be curious why these patches aren't upstream (despite me
    having run them on my end for more than a year now). Well, both times I
    posted them, they were blocked for non-technical reasons that make zero
    sense to me. They boil down to, "we shouldn't enable the user to build
    an OVMF binary that cannot run on Xen; instead we should implement a
    fake PEI-phase r/o variable service for Xen too, *even though* that
    service could *never* report valid variable contents". Thus, I'm not
    allowed to improve the situation on QEMU, even conditionally, without
    working a bunch more on a shim for Xen that *would not work* anyway,
    functionally speaking.

    So there you have it. Just be sure to use flash, or -- even better --
    use libvirt to start QEMU for you. That's what I do anyway (beyond using
    my patches for TianoCore BZ#386, obviously).

    We could perhaps ask Gerd to incorporate my patches, for TianoCore
    BZ#386, into a new firmware image at kraxel.org/repos; then users
    interested in this feature -- deterministic failure to boot with -bios,
    and a defragmented UEFI memmap -- could switch to that new image.

    Thanks
    Laszlo

     

    In particular, I think this is the reason:

    If pflash is detected, then you get a UEFI variable service implementation that conforms to the UEFI spec, and everything will work fine. If, however, case (1) is detected, then OVMF switches to a kind of variable store "emulation"

     

    So, just a matter of compatibility to be in conformity with uefi specifications.

    • Like 2

    Check compatibility before buy licence

    in Pre-Sales Support

    Posted

    10 hours ago, Cyrilphoenix said:

    I already understand that but before to migrate I search to know if someones can tell me if motherboard, processor and other stuff will be well recognize and support.

    It's nearly impossible to tell this, because this could depend not only from the generic hardware, but also from the software, bios, firmware, hardware revisions, etc.

    Just install unraid on usb and try it directly with the free trial, that's the only way to see if it will work, it's just like booting a live linux distro.

    Do this only to check if the hardware is well recognized; unraid needs an array, so you should need to format a disk to be the array, use a spare disk for the array, or if you don't have it, simply do not format anything and use unraid to check only the hardware.

    • Like 1

    Windows 10 VM crashes/breaks during Nvidia driver install for GPU passthrough.

    in VM Engine (KVM)

    Posted · Edited by ghost82

    Hi, I had a look at your setup, and I can say for what I saw that you setup all correctly, you are one of few users that set the things right.

    Unfortunately I haven't a solution for your use case, but I can say the following:

    1. the fwcfg device is not an issue, I have that too (invalid data, code 10) and it isn't causing any issue; you don't need it, that device is used by qemu when you pass kernel parameters or files into the guest (you set additional block in the xml for this, and this isn't the case); maybe if libvirt xml is set with fwcfg parameters data wont be anymore incorrect and the device will stop reporting invalid data

    2. make sure ASUSGK208edited3.rom is dumped for your card, and if dumped with gpuz, make sure to remove the nvflash header (I think you already did it); vbios must start with 55 AA (hex)

    3. shared interrupts should not be a stopper: if the gpu is using irqs and these irqs are shared with other devices, all you should see is lag in digital audio or video output, that's why you switch to msi, but this isn't causing issue with installing drivers

    4. 

    Quote

    Once this driver is installed, I now get this error in Device Manager: "Windows has stopped this device because it has reported problems (Code 43)"

    Error 43 usually stands for "nvidia found that you are passing through a gpu to a vm, this is not allowed"; this was the case with old nvidia drivers and consumer gpus, nvidia drivers installed from windows software update may use a old version, so use the newest nvidia drivers from nvidia website. Nvidia is now allowing user to passthrough consumer gpus, so no more error 43

    5. despite you are correctly using video=efifb:off as a kernel parameter to prevent the host to attach efifb to the gpu, if you check your syslog you can read: 

    Nov 15 14:30:11 Tower kernel: pci 0000:84:00.0: BAR 1: assigned to efifb

    I read about a few cases and I think the issue comes from here.

    Unfortunately I don't have a solution for this, could be a kernel bug, a bios bug, or who knows....

    You can try to manually detach the gpu from efiframebuffer before starting the vm, with these commands: 

    echo 0 > /sys/class/vtconsole/vtcon0/bind
echo 0 > /sys/class/vtconsole/vtcon1/bind
echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind

    But I'm not sure it will work....because if you run 'cat /proc/iomem' efifb should not be reported...

     

    Or...you can try to boot unraid in legacy mode instead of uefi: by this way you exclude at all efifb. I would definetly try this..

    Note that running unraid in legacy mode doesn't prevent you from running vms in uefi mode, so your vm setup is still correct.

    Can't boot Windows 11 more than once... strange problem unRAID 611.12 & 6.11.3

    in VM Engine (KVM)

    Posted

    1 hour ago, SimonF said:

    Where do you get the images from?

    I compile them from official edk github source, I usually compile stable branches, the attached is the latest stable available (august 2022 if I remember well).

    1 hour ago, ChadTaljaardt said:

    Getting inconsistent results

    Please provide additional info and provide the vars file after booting or trying to boot the vm.

    Enable the new Core isolation option in Windows Security makes VM extremely slow

    in VM Engine (KVM)

    Posted

    Sometimes setting cpu pinning could bring to worse performance than not setting it.

    When you use cpu pinning you should consider:

    1. to not pin core 0 and its hyperthread, core 0 and its hyperthread is preferred to be used for the host and not in the vm;

    2. to set emulatorpin cpuset to core 0/hyperthread (that in use in the host)

    3. to use lstopo to map your cpu topology, so you can assign correctly vcpupin, emulatorpin and iothreadpin

    4. to use lstopo to define a topology in your xml

     

    About lstopo, here is a tutorial from 2018, but still valid:

    https://forums.unraid.net/topic/74207-video-guide-how-to-use-lstopo-for-better-vm-performance-on-multi-cpu-and-threadripper-systems/

     

     

    Fail to passthrough GPU to VM

    in VM Engine (KVM)

    Posted · Edited by ghost82

    The p400 should work without any issue, I think there are some reports here of users running it successfully.

    The issue in this post was that gpu was in use by efifb on the host side (at least, the syslog was reporting this) even with the kernel parameter video=efifb:off.

    The issue could be:

    1. a kernel bug, which could have been resolved in recent kernels

    2. a bios issue: I read about a  similar report (BAR 3 assigned to efifb with video=efifb:off); that user had a x79 motherboard with ami bios and he was booting the host in uefi mode, and he had to force expose uefi on pcie lanes to fix this, i.e. enable cms in bios with "uefi only" options set in all subfields.

    • Like 1

    Hassio / Duckdns / Nginx Proxy Manager

    in VM Engine (KVM)

    Posted · Edited by ghost82

    14 hours ago, eoun46055 said:

    I think ther is some problem with the lte connection

    me too...but it seems even the lte carrier cannot give to you proper info..I read that even if you have a public ip you could be in some sort of cgnat..or it could be the lte carrier firewall blocking all inbound connections.

    I didn't understand if you tried an identical router or you moved the router too: to better identify the issue I would try to decreasing at minimum the variables and if possible I would try to use the same hardware with changing only the internet carrier (lte to wired); if it works with wired the issue is for sure the lte.

    If you aren't able to solve this, you can look at wireguard, it should bypass cgnat.

    Can't boot Windows 11 more than once... strange problem unRAID 611.12 & 6.11.3

    in VM Engine (KVM)

    Posted

    Can you please try the attached ovmf?

    Just decompress the zip, backup your original files:

    /usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi-tpm.fd

    /etc/libvirt/qemu/nvram/1a8fdacb-aad4-4bbb-71ea-732b0ea1051a_VARS-pure-efi-tpm.fd

     

    move these files in a secure place

    rename the extracted files to OVMF_CODE-pure-efi-tpm.fd and 1a8fdacb-aad4-4bbb-71ea-732b0ea1051a_VARS-pure-efi-tpm.fd

    move these renamed files to:
    /usr/share/qemu/ovmf-x64/

    /etc/libvirt/qemu/nvram/

     

    Once done, modify the vm template, deleting <boot dev='hd'/> and adding <boot order='1'/> to the nvme block (let's try the traditional way first).

    If it doesn't boot, shutdown the vm, compress 1a8fdacb-aad4-4bbb-71ea-732b0ea1051a_VARS-pure-efi-tpm.fd and share it here

    Before shutting down the vm check if you have the double entry 'Windows boot manager'

     

    OVMF-secboot.zip

    虚拟机突发无法操作

    in Chinese / 简体中文

    Posted

    You have no vm saved with that uuid.

    You can:

    1. Open the vm in xml mode, replace this line: 

    <uuid>xxxxxxxxxxxxxxxxxxxxxxxx</uuid>

    with: 

    <uuid>7c611489-4ea2-11ed-9e19-52540070811c</uuid>

     

    Or, delete the vm from the gui without deleting vdisk(s) and create a new vm pointing at existing vdisk(s)

    • Thanks 1

    Convert VMware VM to KVM

    in VM Engine (KVM)

    Posted · Edited by ghost82

    If it's not changed from the xml in your diagnostics, I cannot explain, the address is there, and also it was e1000 and now it's virtio.

    Anyway, 04:00.0 or 02:01.0, e1000 or virtio, doesn't make any difference, you have the virtio network inside the vm, the issue is inside the vm, not related to qemu or libvirt, maybe you just need to configure the connection inside the vm (networkmanager?)

×
×
  • Create New...