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

Thomas Stein himbeere at meine-oma.de
Mon Feb 23 22:19:34 UTC 2015


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!)




More information about the libvirt-users mailing list