libvirt users - Feb 2015 - machine='pc-q35-2.1' and sata controller

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.

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'/>
>     </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?
>
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!)

Thanks Laine for taking the time to clarify this.

cheers
t. 

On Monday 23 February 2015 16:51:26 Laine Stump wrote:
> 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'/>
> > 
> >     </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?
> 
> 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!)

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?

Regards,
Nerijus