[libvirt-users] machine='pc-q35-2.1' and sata controller

[Thomas Stein]

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'/>
</controller>

it gets added again when i close the editor.

The reason i would like to delete the sata controller is this error while
trying to migrate the machine:

2015-02-23 19:04:11.181+0000: 1972: error : qemuMonitorJSONCheckError:381 :
internal error: unable to execute QEMU command 'migrate': State blocked by
non-migratable device '0000:00:1f.2/ich9_ahci'

Someone has an idea to solve this?

thanks and cheers
t.

[Laine Stump]

Post by Thomas Stein
Hello.
I'm not able to disable the sata controller on a machine='pc-q35-2.1' type VM.
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f'
function='0x2'/>
</controller>
it gets added again when i close the editor.
The reason i would like to delete the sata controller is this error while
internal error: unable to execute QEMU command 'migrate': State blocked by
non-migratable device '0000:00:1f.2/ich9_ahci'
Someone has an idea to solve this?

Yep. You have described the situation perfectly. Here are my notes from
libvirt commit c27b0bb171d9bdac10a93492a2a99eaa22746694, which fixed the
handling of "default" devices in the Q35 machinetype:

sata - a q35 machine always has a sata controller implicitly
added at slot 0x1F, function 2. There is no way to avoid this
controller, so we always add it. Note that the xml2xml tests
for the pcie-root and q35 cases were changed to use
DO_TEST_DIFFERENT() so that we can check for the sata
controller being automatically added. This is especially
important because we can't check for it in the xml2argv output
(it has no effect on that output since it's an implicit device).

So basically when you specify a q35 machinetype, you get a SATA
controller at 00:1f.2 even though you have added no commandline args to
ask for it. And unlike the default network device (which libvirt can
eliminate by adding "-net none" to the qemu commandline), there is no
way to avoid this device.

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. In the meantime, the only way to avoid this problem is to switch to
an i440fx-based machinetype (this will require removing all the pci
controllers from your config as well as removing all <address type='pci'
.../> elements within all devices in the domain; libvirt will then
reassign PCI addresses in the guest appropriate to the new machine type.
IMPORTANT: If the guest is running MS Windows, this may require a new
"activation"; best to keep a copy of the old config and an image of the
disk just in case there are problems!)

[Thomas Stein]

Thanks Laine for taking the time to clarify this.

cheers
t.

Post by Laine Stump

Post by Thomas Stein
Hello.
I'm not able to disable the sata controller on a machine='pc-q35-2.1' type
VM.>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f'
function='0x2'/>
</controller>
it gets added again when i close the editor.
The reason i would like to delete the sata controller is this error while
internal error: unable to execute QEMU command 'migrate': State blocked by
non-migratable device '0000:00:1f.2/ich9_ahci'
Someone has an idea to solve this?

Yep. You have described the situation perfectly. Here are my notes from
libvirt commit c27b0bb171d9bdac10a93492a2a99eaa22746694, which fixed the
sata - a q35 machine always has a sata controller implicitly
added at slot 0x1F, function 2. There is no way to avoid this
controller, so we always add it. Note that the xml2xml tests
for the pcie-root and q35 cases were changed to use
DO_TEST_DIFFERENT() so that we can check for the sata
controller being automatically added. This is especially
important because we can't check for it in the xml2argv output
(it has no effect on that output since it's an implicit device).
So basically when you specify a q35 machinetype, you get a SATA
controller at 00:1f.2 even though you have added no commandline args to
ask for it. And unlike the default network device (which libvirt can
eliminate by adding "-net none" to the qemu commandline), there is no
way to avoid this device.
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. In the meantime, the only way to avoid this problem is to switch to
an i440fx-based machinetype (this will require removing all the pci
controllers from your config as well as removing all <address type='pci'
.../> elements within all devices in the domain; libvirt will then
reassign PCI addresses in the guest appropriate to the new machine type.
IMPORTANT: If the guest is running MS Windows, this may require a new
"activation"; best to keep a copy of the old config and an image of the
disk just in case there are problems!)

[Nerijus Baliunas]

Post by Laine Stump
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?

Regards,
Nerijus

[Laine Stump]

Post by Nerijus Baliunas

Post by Laine Stump
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?

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

The tests in that series depend upon some other upstream tests, so the
order on top of current origin/master would be something like:

http://lists.gnu.org/archive/html/qemu-devel/2015-03/msg02094.html
http://lists.gnu.org/archive/html/qemu-devel/2015-03/msg02151.html
http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg05200.html

There's a minor pathing issue with how a test in the first series there
locates the qemu-img binary (It uses the system's qemu-img instead of
the local build copy), but otherwise that gives you all the framework
for the ahci tests.

These are all just tests, at any rate -- the actual patch that enables
the migration is small and trivial and can be applied directly to
current upstream:

http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg05202.html

All of the requisites that make AHCI safe to migrate are already
upstream now.
===========

As I understand it, all except the last patch will be in qemu 2.3. Also,
he is actively soliciting people to test it, so if you've been wanting
to learn how to build qemu from source, now is your opportunity to
figure it out!

[Nerijus Baliunas]

Post by Laine Stump
Here is the info straight from the author (I've also Cc'ed him to this
===============
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
the migration is small and trivial and can be applied directly to
http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg05202.html
All of the requisites that make AHCI safe to migrate are already
upstream now.
===========
As I understand it, all except the last patch will be in qemu 2.3. Also,
he is actively soliciting people to test it, so if you've been wanting
to learn how to build qemu from source, now is your opportunity to
figure it out!

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?

Regards,
Nerijus

[John Snow]

Post by Nerijus Baliunas

Post by Laine Stump
Here is the info straight from the author (I've also Cc'ed him to this
===============
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
the migration is small and trivial and can be applied directly to
http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg05202.html
All of the requisites that make AHCI safe to migrate are already
upstream now.
===========
As I understand it, all except the last patch will be in qemu 2.3. Also,
he is actively soliciting people to test it, so if you've been wanting
to learn how to build qemu from source, now is your opportunity to
figure it out!

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?
Regards,
Nerijus

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 is fairly trivial -- it's just a true/false value in the code.

My words of caution:

(1) We still have some bugs in the AHCI device which may necessitate
changing the migration format of the device. Since we have not
officially enabled migration, these format changes may leave you unable
to migrate to later versions, because we are not currently being careful
to maintain backwards compatibility with this "unreleased" device.

[If you are wondering what the probability of being unable to migrate to
an official build where AHCI migration is supported is: Nearly 100%.]

(2) Because we have not enabled migration of AHCI officially, [And this
is not enabled or supported in RHEL!] you may run into bugs. I wouldn't
do this on a production system.

That said, if you do want to try it out on non-essential systems; for
testing, development &c: I'd appreciate any bug reports.

See http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg05202.html
as mentioned above for the patch that simply enables migration.

--js

[Nerijus Baliunas]

Post by John Snow

Post by Nerijus Baliunas
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 is fairly trivial -- it's just a true/false value in the code.

I built 2.3.0-rc0 but also added RH patches which applied (mainly for
pc-q35-rhel7.1.0 machine type support) from
http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/qemu-kvm-rhev-2.1.2-23.el7_1.1.src.rpm

After suspending and restoring VM prints the following and hangs:

[root localhost ~]# [ 43.595571 irq 23: nobody cared (try booting with the "irqpoll" option)
[ 43.596004] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.3-200.fc20.x86_64 #1
[ 43.596004] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) . BIOS seabios-1.7.5-8.el7 04/01/2014
[ 43.596004] 0000000000000000 be8ae26f5ae0021d ffff88007fc03d18 ffffffff81728acc
[ 43.596004] ffff88007a88a800 ffff88O07fc03d40 ffffffff810ea4e2_

Any idea why? I will try with a pure qemu w/o RH patches later.

Regards,
Nerijus

[John Snow]

Post by Nerijus Baliunas

Post by John Snow

Post by Nerijus Baliunas
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 is fairly trivial -- it's just a true/false value in the code.

I built 2.3.0-rc0 but also added RH patches which applied (mainly for
pc-q35-rhel7.1.0 machine type support) from
http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/qemu-kvm-rhev-2.1.2-23.el7_1.1.src.rpm
[root localhost ~]# [ 43.595571 irq 23: nobody cared (try booting with the "irqpoll" option)
[ 43.596004] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.3-200.fc20.x86_64 #1
[ 43.596004] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) . BIOS seabios-1.7.5-8.el7 04/01/2014
[ 43.596004] 0000000000000000 be8ae26f5ae0021d ffff88007fc03d18 ffffffff81728acc
[ 43.596004] ffff88007a88a800 ffff88O07fc03d40 ffffffff810ea4e2_
Any idea why? I will try with a pure qemu w/o RH patches later.
Regards,
Nerijus

I do not know, sorry.

[Nerijus Baliunas]

Post by John Snow

Post by Nerijus Baliunas
I built 2.3.0-rc0 but also added RH patches which applied (mainly for
pc-q35-rhel7.1.0 machine type support) from
http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/qemu-kvm-rhev-2.1.2-23.el7_1.1.src.rpm
[root localhost ~]# [ 43.595571 irq 23: nobody cared (try booting with the "irqpoll" option)
[ 43.596004] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.3-200.fc20.x86_64 #1
[ 43.596004] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) . BIOS seabios-1.7.5-8.el7 04/01/2014
[ 43.596004] 0000000000000000 be8ae26f5ae0021d ffff88007fc03d18 ffffffff81728acc
[ 43.596004] ffff88007a88a800 ffff88O07fc03d40 ffffffff810ea4e2_
Any idea why? I will try with a pure qemu w/o RH patches later.

I do not know, sorry.

Can anyone confirm that you can succesfully suspend and restore Q35 Linux VM
(in my case with virtio disk) with 2.3.0-rc1?

Regards,
Nerijus