Bug 1368300

Summary: Sata disk can not be attached to ahci controller device in q35 guest by libvirt automaticly
Product: Red Hat Enterprise Linux 7 Reporter: Jingjing Shao <jishao>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: dyuan, laine, lmen, rbalakri
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-19 14:17:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jingjing Shao 2016-08-19 03:13:07 UTC
Description of problem:
Sata disk can not be attached to ahci controller device in q35 guest by libvirt automaticly

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.6.0-20.el7.x86_64
libvirt-2.0.0-5.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Prepare a guest with q35 machine type and add the xml info as below to the guest xml
   <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/cdrom.img'/>
      <target dev='sdb' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
   </disk>

# virsh edit q35-js
Domain q35-js XML configuration not changed.


2.Start the guest and check the xml

# virsh start q35-js
Domain q35-js started

# virsh dumpxml q35
<domain type='kvm'>
  <name>q35-js</name>
...
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.3.0'>hvm</type>
    <boot dev='hd'/>
  </os>
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/cdrom.img'/>
      <target dev='sdb' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
...
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>


3. Check the qemu commend line
# ps -aux | grep qemu | grep ahci
#
#

4. # ps -aux | grep qemu | grep sata
qemu     12510  0.9  0.6 1898860 49768 ?       Sl   10:57   0:01 /usr/libexec/qemu-kvm -name guest=q35-js,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-q35-js/master-key.aes -machine pc-q35-rhel7.3.0,accel=kvm,usb=off,vmport=off -cpu SandyBridge,+vmx -m 1024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 251e7c62-3df4-4354-9a5b-0c7972035393 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-q35-js/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device intel-iommu -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x1 -drive file=/var/lib/libvirt/images/cdrom.img,format=qcow2,if=none,id=drive-sata0-0-1 -device ide-hd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:5f:97:3d,bus=pci.2,addr=0x2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-q35-js/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -chardev pty,id=charconsole1 -device virtconsole,chardev=charconsole1,id=console1 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,bus=pcie.0,addr=0x2 -device intel-hda,id=sound0,bus=pcie.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pcie.0,addr=0x8 -msg timestamp=on

Actual results:
1. Can not find the corresponding controller device type "ahci" in qemu command line via "sata0"  such as  the following
......
-device ahci,id=sata0,bus=pcie.0,addr=0x8
......

2. Actually sata disk attach to the ide.1 bus
-drive file=/var/lib/libvirt/images/cdrom.img,format=qcow2,if=none,id=drive-sata0-0-1 -device ide-hd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=1
Expected results:

Expected results:
Sata disk can be attached to ahci controller device in q35 guest by libvirt automaticly

Additional info:

Comment 2 Laine Stump 2016-08-19 14:17:36 UTC
This is an invalid test.

The Q35 machinetype in qemu has an integrated ACHI controller in slot 0x1f function 2 of the root complex (bus 0). This controller is there no matter what you do - no commandline argument is necessary in order for it to be there, and it is not possible to remove it.

Additionally, the name of this controller (qemu's "id"), which is defined by qemu and is also not changeable, is inexplicably "ide" (the same as used for the integrated IDE controller on i440fx machinetypes).

Since the commandline syntax for adding a disk device is that the controller id and unit number within the controller are given together as "bus=$id.$unit", the string "bus=ide.1" thus makes sense.

So there is nothing wrong here. The odd naming of the integrated primary ahci controller as "ide" just makes it a bit confusing.

(BTW, the Q35 machinetype doesn't have any integrated IDE controller, and libvirt doesn't support adding additional IDE controllers, so it's not even possible to have a disk connected to an IDE controller on a Q35 virtual machine.)

Comment 3 Jingjing Shao 2016-08-22 08:21:32 UTC
(In reply to Laine Stump from comment #2)
> This is an invalid test.
> 
> The Q35 machinetype in qemu has an integrated ACHI controller in slot 0x1f
> function 2 of the root complex (bus 0). This controller is there no matter
> what you do - no commandline argument is necessary in order for it to be
> there, and it is not possible to remove it.
> 
> Additionally, the name of this controller (qemu's "id"), which is defined by
> qemu and is also not changeable, is inexplicably "ide" (the same as used for
> the integrated IDE controller on i440fx machinetypes).
> 
> Since the commandline syntax for adding a disk device is that the controller
> id and unit number within the controller are given together as
> "bus=$id.$unit", the string "bus=ide.1" thus makes sense.
> 
> So there is nothing wrong here. The odd naming of the integrated primary
> ahci controller as "ide" just makes it a bit confusing.
> 
> (BTW, the Q35 machinetype doesn't have any integrated IDE controller, and
> libvirt doesn't support adding additional IDE controllers, so it's not even
> possible to have a disk connected to an IDE controller on a Q35 virtual
> machine.)

Hi laine,

I want to double check that the controller device "ide.1" attached automaticly is the integrated ACHI controller,just with a confused name, is it right?

If so, should we update this name? I think it is really confused.

Comment 4 Laine Stump 2016-08-22 19:55:21 UTC
Yes, "ide" is the name qemu uses internally for the integrated sata controller ("1" is the unit number on that controller).

We *can't* change this name; it's not up to us, it's qemu's name and they hardcoded it. It's been there for several years with that name, and changing the name would break untold other software (libvirt included).

It's silly, but that's the way it is and we have to live with it. At least libvirt shows the controller for what it is (a sata controller).

Comment 5 Jingjing Shao 2016-08-23 02:27:42 UTC
(In reply to Laine Stump from comment #4)
> Yes, "ide" is the name qemu uses internally for the integrated sata
> controller ("1" is the unit number on that controller).
> 
> We *can't* change this name; it's not up to us, it's qemu's name and they
> hardcoded it. It's been there for several years with that name, and changing
> the name would break untold other software (libvirt included).
> 
> It's silly, but that's the way it is and we have to live with it. At least
> libvirt shows the controller for what it is (a sata controller).

OK,thanks for your detailed explanation