[Bug 1853200] Re: cpu features hle and rtm disabled for security are present in /usr/share/libvirt/cpu_map.xml

A small addendum to what Corey said: Upstream QEMU will mostly providing new named CPU models with 'hle' and 'rtm' CPU flags turned off. Keep an eye on the upstream 'qemu-devel' list :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1836859] Re: RFE: Ship the firmware "descriptor files" as part of the 'ovmf' package

Yeah, I gave a heads up to 'dannf' on #debian-qemu on OFTC as well :-) No, I haven't filed for other BIOSes. (But, reading the QEMU firmware spec[1], it the other BIOSes are possible, too.) My immediate motivation to file these for EDK2/OVMF is to facilitate the Secure Boot feature KVM/QEMU

[Bug 1836859] Re: RFE: Ship the firmware "descriptor files" as part of the 'ovmf' package

** Description changed: From version 4.1 (due in August 2019) onwards, QEMU ships the so-called firmware "descriptor files". These are small JSON files that describe details about UEFI firmware binaries — such as the fimware binary path, its architecture, supported machine type, NVRAM

[Bug 1836859] [NEW] RFE: Ship the firmware "descriptor files" as part of the 'ovmf' package

Public bug reported: >From version 4.1 (due in August 2019) onwards, QEMU ships the so-called firmware "descriptor files". These are small JSON files that describe details about UEFI firmware binaries — such as the fimware binary path, its architecture, supported machine type, NVRAM template and

[Bug 1673467] Re: [ocata] unsupported configuration: CPU mode 'host-model' for aarch64 kvm domain on aarch64 host is not supported by hypervisor

Speaking to a libvirt CPU modelling infrastructure developer: Apparently the "reason" for 'host-model' not being supported or AArch64 is: neither libvirt / QEMU can tell what the host CPU model is. And there's no CPU description code for ARM at this point. -- You received this bug notification

[Bug 1643911] Re: libvirt randomly crashes on xenial nodes with "*** Error in `/usr/sbin/libvirtd': malloc(): memory corruption:"

@Matt Booth: This is not the same bug 1673483 that DanB debugged the other day and identified fixes, as the Nova stacktraces are different for both. For bug 1673483, the Nova crash directly relates to the libvirt commits mentioned in its comment #5 (of bug 1673483). In this memory corruption

[Bug 1673483] Re: libvirt: test_attach_volume_shelved_or_offload_server times out waiting for device detach (which fails)

** Also affects: libvirt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1673483 Title: libvirt: test_attach_volume_shelved_or_offload_server

[Bug 1643911] Re: libvirt randomly crashes on xenial nodes with "*** Error in `/usr/sbin/libvirtd': malloc(): memory corruption:"

Now, we seem to be stuck in a limbo here, unable to diagnose this to get to the root cause. So I asked upstream libvirt maintainers on IRC. And Dan Berrange responds [text formatted a little bit for readability here]: "Running libvirt under Valgrind will likely point to a root cause. However,

[Bug 1449062] Re: qemu-img calls need to be restricted by ulimit (CVE-2015-5162)

Jeremy: Hemanth (in comment#72) seems to have mixed up this bug (which sets limits for memory / CPU usage for `qemu-img` calls) with *another* bug[x] that is about disk image format guessing. So, the Nova patches that fix this bug (1449062) are sufficient for the problem it is solving (setting a

[Bug 1439280] Re: Libvirt CPU affinity error

@Matt: Since you're farily certain that this is specific to Ubuntu, then I hope Ubuntu's Nova package maintainers will take a look. . . -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1439280 Title:

[Bug 1439280] Re: Libvirt CPU affinity error

@Matt: Since you're farily certain that this is specific to Ubuntu, then I hope Ubuntu's Nova package maintainers will take a look. . . -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu.

[Bug 1439280] Re: Libvirt CPU affinity error

Matt, you're right, allow me to correct myself below. Short: I still cannot reproduce it. I just tested it below in a Single node DevStack with today's Nova git with the Nova instance being QEMU emulated, but I cannot reproduce the said failure in this bug description. Test environment

[Bug 1439280] Re: Libvirt CPU affinity error

Yes, to test CPU pinning/NUMA with libvirt you ought to use Nested KVM. Please report results after testing with that. That said, some notes below. Quoting Dan Berrange from a different review with a complete response on *why*: It is fundamentally impossible to test CPU pinning with TCG (aka

[Bug 1439280] Re: Libvirt CPU affinity error

Matt, you're right, allow me to correct myself below. Short: I still cannot reproduce it. I just tested it below in a Single node DevStack with today's Nova git with the Nova instance being QEMU emulated, but I cannot reproduce the said failure in this bug description. Test environment

[Bug 1439280] Re: Libvirt CPU affinity error

Yes, to test CPU pinning/NUMA with libvirt you ought to use Nested KVM. Please report results after testing with that. That said, some notes below. Quoting Dan Berrange from a different review with a complete response on *why*: It is fundamentally impossible to test CPU pinning with TCG (aka

[Bug 1295876] Re: libvirtError: internal error unable to add domain xxx to cgroup: No space left on device

@sean: For cgroups, below are the specific filter variables to log debug level messages: LIBVIRT_LOG_FILTERS=1:cgroup LIBVIRT_LOG_OUTPUTS=1:file:/var//tmp/libvirt.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.