similar to: machine='pc-q35-2.1' and sata controller

On 02/23/2015 02:26 PM, Thomas Stein wrote: > Hello. > > I'm not able to disable the sata controller on a machine='pc-q35-2.1' type VM. > Whenever i delete: > > <controller type='sata' index='0'> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' > function='0x2'/> >

What's the status of the SATA controller migration bug? Are the patches for it expected to be in 2.4? Looks like they didn't make it into 2.3. Since you last wrote, if the SATA controller patches aren't in yet, is there any new way to avoid the SATA controller device, if you have no SATA devices? Thank you. === REPLYING TO === On 02/23/2015 02:26 PM, Thomas Stein wrote: >

On Mon, 23 Mar 2015 10:36:33 -0400 John Snow <jsnow@redhat.com> wrote: > > Are the needed patches in 2.3.0-rc0? > > Is it possible to backport AHCI migration to RHEL 7.1 qemu or will it be too much work? > > The patches that improve the stability of AHCI migration are in 2.3-rc0. > We still have not /enabled/ migration upstream, but editing to code to > allow it

On Thu, 12 Mar 2015 14:56:08 -0400 Laine Stump <laine@laine.org> wrote: > Here is the info straight from the author (I've also Cc'ed him to this > mail): > > =============== > The AHCI migration series is here: > > http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg05200.html > These are all just tests, at any rate -- the actual patch that enables

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 q35 -m 8192 -cpu host,kvm=off \ -smp 4,sockets=1,cores=4,threads=1 \ -bios

On 03/23/2015 08:05 PM, Nerijus Baliunas wrote: > On Mon, 23 Mar 2015 10:36:33 -0400 John Snow <jsnow@redhat.com> wrote: > >>> Are the needed patches in 2.3.0-rc0? >>> Is it possible to backport AHCI migration to RHEL 7.1 qemu or will it be too much work? >> >> The patches that improve the stability of AHCI migration are in 2.3-rc0. >> We still have

On 08/10/2015 12:41 AM, Michael Darling wrote: > What's the status of the SATA controller migration bug? Are the patches for it expected to be in 2.4? > Looks like they didn't make it into 2.3. That's a question better suited for the qemu developers than us. I'm Cc'ing John Snow, who authored the qemu patches. John? > Since you last wrote, if the SATA controller

On 03/11/2015 08:20 PM, Nerijus Baliunas wrote: > Laine Stump <laine@...> writes: > >> And it is also true that any machine with a SATA controller can't be >> migrated because of problems with the driver. I just talked to the >> person responsible for fixing these bugs in qemu, and he said that the >> patches will go upstream "soon", and that he

On 03/22/2015 08:23 PM, Nerijus Baliunas wrote: > On Thu, 12 Mar 2015 14:56:08 -0400 Laine Stump <laine@laine.org> wrote: > >> Here is the info straight from the author (I've also Cc'ed him to this >> mail): >> >> =============== >> The AHCI migration series is here: >> >>

Laine Stump <laine@...> writes: > And it is also true that any machine with a SATA controller can't be > migrated because of problems with the driver. I just talked to the > person responsible for fixing these bugs in qemu, and he said that the > patches will go upstream "soon", and that he hopes they will be in qemu > 2.3. Are these patches available yet?

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

Hi all I have a very weird case of pci passthrough. I have a machine with 7 network interfaces, all of them intel. Four of them are on one quad giga ethernet device. If I manually unbind the devices and allow qemu to use them, with intel IOMMU working, everything works like a charm. Here's how I do it manually: root@kybrat (x86_64) ~]$ lspci -nn | grep net 00:19.0 Ethernet controller

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

Hi, i was trying to install CentOS 5.1 on new machine based on Intel Q35 desktop board, witch 2 SATA disks (configured as RAID 1) , 8GB RAM and Intel Core2 QUADCORE. The first problem was with install - it hangs before installer startup at ACPI messages. So i installed it with ACPI=off switch. The first problem is : Dec 7 09:54:01 vmhost1 kernel: BIOS bug, no explicit IRQ entries, using default

Xen 3.4 xen-unstable.hg from yesterday with debian etch on 64bit arch Intel/Lenovo Q35 Mainboard with VT-d enabled Bootoptions iommu=1 vtd=1 pci.backhide for a PCI-E nvidia graphiccard xm dmesg Error messages includes: [VT-D] iommu.c: 1694:d32767 iommu: mapping reserved region failed [VT-D] iommu.c: 1542:d0 intel_iommu_add_device: context mapping failed If i try to start my HVM by xm create

Hello, I'm trying to migrate a working qemu command line configuration to libvirt. The part I'm currently failing on is: $ qemu-system-x86_64 -M Q35 ... -device vfio-pci,host=05:00.0,bus=pcie.0 The right way to translate this into libvirt XML seems to be using <hostdev>, but I seem to be unable to plug it into the pcie-root port This is how the interesting part looks like when

Am 19.11.2013 11:36, schrieb Laine Stump: > On 11/15/2013 03:35 PM, Thomas Kuther wrote: >> Hello, >> >> I'm trying to migrate a working qemu command line configuration to >> libvirt. >> The part I'm currently failing on is: >> >> $ qemu-system-x86_64 -M Q35 ... -device >> vfio-pci,host=05:00.0,bus=pcie.0 >> >> The right

I am happy to announce that I have successfully (and finally!) been able to pass a PCIe graphics card via VT-d to a Windows XP HVM DomU. About time! Config: -Intel Q6600 Core 2 Quad-Core, G0 stepping (I think) -Intel DQ35JO Motherboard, Q35 Chipset, BIOS v.991 (1/9/09), VT and VT-d enabled -nVidia 9500GT (for VT-d passthrough - DomU) -nVidia GeForce2 MX200 (Dom0 console) -Xen (build:

I am happy to announce that I have successfully (and finally!) been able to pass a PCIe graphics card via VT-d to a Windows XP HVM DomU. About time! Config: -Intel Q6600 Core 2 Quad-Core, G0 stepping (I think) -Intel DQ35JO Motherboard, Q35 Chipset, BIOS v.991 (1/9/09), VT and VT-d enabled -nVidia 9500GT (for VT-d passthrough - DomU) -nVidia GeForce2 MX200 (Dom0 console) -Xen (build:

Quoting Laine Stump (laine@laine.org): > 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