similar to: Issue with libguestfs-test-tool on a guest hosted on VMWare ESXi

Thanks. Reading the defect and the associated thread in https://bugs.launchpad.net/qemu/+bug/1661386, I enabled performance counters in VMWare guest settings. Now the kvm assertion `ret == cpu->kvm_msr_buf->nmsrs' is gone. But the qemu/kvm hangs after printing "SeaBIOS (version 1.10.2-1)" I presume this too is a qemu/kvm issue for vmware platforms. Is there any existing issue

Hi all, What are the differences between pc and q35?? By default, virt-manager+libvirt setups kvm guest machine as a pc-i440fx-rhel7.1.0. [hicheck at ckvm015 ~]$ /usr/libexec/qemu-kvm -machine ? Supported machines are: pc RHEL 7.1.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.1.0) pc-i440fx-rhel7.1.0 RHEL 7.1.0 PC (i440FX + PIIX, 1996) (default) pc-i440fx-rhel7.0.0

Yes it works if I use force_tcg env variable On Sat, 24 Mar 2018 at 4:37 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > > On Fri, Mar 23, 2018 at 05:35:38PM +0000, Tanmoy Sinha wrote: > > Thanks. Reading the defect and the associated thread in > > https://bugs.launchpad.net/qemu/+bug/1661386, I enabled performance > > counters in VMWare guest settings. Now the

On Friday, 23 March 2018 07:10:00 CET Tanmoy Sinha wrote: > I am using a debian 9 guest, hosted on a ESXi platform with nested > virtualisation enabled. > > On this debian 9 guest when I run libguesfs-test-tool, it fails with an > error: > > "qemu-system-x86_64: > /build/qemu-DqynNa/qemu-2.8+dfsg/target-i386/kvm.c:1805: kvm_put_msrs: > Assertion `ret ==

Hi, I am having issues with libguestfs; I am unable to mount a disk either from cli or via python bindings. This was working previously, but in order to have access to python3.5 I am trying to upgrade from Debian 8/Jessie to Debian 9/Stretch. Unfortunately the libguestfs error is getting in the way. Output of libguestfs-test-tool is attached as per libguestfs.org help. My current environment:

Thanks will write to VMWare forums. Btw, is there a way I can change the qemu default machine type? I mean when I specify *-machine pc *it picks up pc-i440fx-2.8 by default. Or is it tied to the underlying host hardware? *$> *qemu-system-x86_64* -machine help* Supported machines are: *pc* Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.8) *pc-i440fx-2.8*

Hello I have recently had to reinstall Centos 7.5 to on host computer. I have not be able to set-up qemu to support the q35 chip set. I have several virtual machines that require q35. This is not my first install, I have configured libvirt on many machines in the past, it just worked, it has not required any manual configuration. [root at sj aadmin]# /usr/libexec/qemu-kvm -machine help

On Sat, Mar 24, 2018 at 03:08:16PM +0000, Tanmoy Sinha wrote: > Even though force_tcg works, I intend not to run it on emulation. Is there > way I can run it over kvm? The other observation is, without force_tcg if I > use the machine type as *pc-i440fx-2.**1*,accel=kvm it works fine. The > default machine type for my host *pc-i440fx-2.8, *which seems to crib. I don't know, but

Even though force_tcg works, I intend not to run it on emulation. Is there way I can run it over kvm? The other observation is, without force_tcg if I use the machine type as *pc-i440fx-2.**1*,accel=kvm it works fine. The default machine type for my host *pc-i440fx-2.8, *which seems to crib. On Sat, 24 Mar 2018 at 09:46 Tanmoy Sinha <tanmoy.sinha@gmail.com> wrote: > Yes it works if I

On 08/03/2015 10:47 PM, Martin Kletzander wrote: > On Mon, Aug 03, 2015 at 03:39:30PM -0700, Ryan Barry wrote: >> On 08/03/2015 01:43 PM, Ryan Barry wrote: >>> Using: >>> >>> edk2.git-0-20150803.b1141.ga0973dc.x86_64 >>> edk2.git-ovmf-x64-0-20150802.b1139.gb234418.noarch >>> >>> On Fedora 22. >>> >>> Provisioning

On 08/06/2015 08:08 AM, Martin Kletzander wrote: > On Tue, Aug 04, 2015 at 07:11:29AM -0700, Ryan Barry wrote: >> On 08/03/2015 10:47 PM, Martin Kletzander wrote: >>> On Mon, Aug 03, 2015 at 03:39:30PM -0700, Ryan Barry wrote: >>>> On 08/03/2015 01:43 PM, Ryan Barry wrote: >>>>> Using: >>>>> >>>>>

On 08/12/2015 02:34 PM, Alex Holst wrote: > I would really appreciate some pointers on what I am doing wrong here. > > I have a need to run multiple virtual guests which have each their own GPU and > some USB controllers passed-through. I am able to run one of the guests like > this (assuming vfio stuff has happened elsewhere), but I would prefer to use > virsh: > > kvm -M

On Tue, Aug 04, 2015 at 07:11:29AM -0700, Ryan Barry wrote: >On 08/03/2015 10:47 PM, Martin Kletzander wrote: >> On Mon, Aug 03, 2015 at 03:39:30PM -0700, Ryan Barry wrote: >>> On 08/03/2015 01:43 PM, Ryan Barry wrote: >>>> Using: >>>> >>>> edk2.git-0-20150803.b1141.ga0973dc.x86_64 >>>>

> Not sure how independent ERST is from ACPI and other specs. It looks > like referencing UEFI spec at least. It is just the format of error records that comes from the UEFI spec (include/linux/cper.h) but you can ignore it, I think. It should be handled by tools on the host side. For you, the error log address range contains a CPER header followed by a binary blob. In practice, you

On Tue, Jun 19, 2018 at 11:37:46AM +0100, Richard W.M. Jones wrote: > QEMU for x86 supports two machine types, "pc" (emulating the ancient > Intel i440FX chipset originally used by the Pentium Pro), and "q35" > (https://wiki.qemu.org/Features/Q35). > > Currently virt-v2v does not set any machine type, so libvirt or the > target hypervisor will choose some

QEMU for x86 supports two machine types, "pc" (emulating the ancient Intel i440FX chipset originally used by the Pentium Pro), and "q35" (https://wiki.qemu.org/Features/Q35). Currently virt-v2v does not set any machine type, so libvirt or the target hypervisor will choose some default, probably i440fx. Newer versions of libvirt and QEMU will probably switch over to defaulting

QEMU for x86 supports two machine types, "pc" (emulating the ancient Intel i440FX chipset originally used by the Pentium Pro), and "q35" (https://wiki.qemu.org/Features/Q35). Currently virt-v2v does not set any machine type, so libvirt or the target hypervisor will choose some default, probably i440fx. The latest advice from the QEMU and libvirt communities is not to rely on

Hi everyone, Using the QEMU hypervisor, when a live disk snapshot is requested through libvirt, the request can fail if the underyling qemu binary lacks the snapshotting support. In python, we have something like libvirtError: Operation not supported: live disk snapshot not supported with this QEMU binary I'd like to detect ahead of time if the underlying QEMU can or cannot do

On Mon, Aug 03, 2015 at 03:39:30PM -0700, Ryan Barry wrote: >On 08/03/2015 01:43 PM, Ryan Barry wrote: >> Using: >> >> edk2.git-0-20150803.b1141.ga0973dc.x86_64 >> edk2.git-ovmf-x64-0-20150802.b1139.gb234418.noarch >> >> On Fedora 22. >> >> Provisioning a i440FX system in virt-manager and attempting to boot >> results in successful EFI

I am trying that out. Debian 9 (stretch) backports still doesn't have 4.16 kernel. So I building the kernel from the source. Will keep you posted. On Mon, 26 Mar 2018 at 13:00 Richard W.M. Jones <rjones@redhat.com> wrote: > [Adding Paolo and Vitaly, but FYI only as the bug seems to have an > upstream fix already.] > > On Mon, Mar 26, 2018 at 09:13:45AM +0300, Roman Kagan