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!) _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
