RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1414734 - q35 chipset - hotplugged devices do not show up in VM
Summary: q35 chipset - hotplugged devices do not show up in VM
Keywords:
Status: CLOSED DUPLICATE of bug 1330024
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: 7.4
Assignee: Marcel Apfelbaum
QA Contact: jingzhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-19 10:49 UTC by Martin Tessun
Modified: 2017-06-28 07:48 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-10 14:39:04 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Martin Tessun 2017-01-19 10:49:55 UTC 
Description of problem:
If you hotplug a device to a VM running q35 chipset the new device does not show up in the guest OS (RHEL 7.2 in this case) unless rebooted

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.8.0-2.el7.x86_64
libvirt-2.0.0-10.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. Start a RHEL 7.2 VM with q35 chipset.
2. Hotplug a network device (virtio-net)
3. Check if the device shows up in the VM
4. Reboot the VM. Check for the network device again. (Note no shutdown. Just reboot, so that the qemu process does not get terminated)

Actual results:
Device only shows up after reboot


Expected results:
Device should show up without reboot

Additional info:
Config of my VM:
<domain type='kvm'>
  <name>rhel72-q35</name>
  <uuid>8186e9b0-6ce5-420c-8409-da5712c8390c</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.3.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Skylake-Client</model>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/mtessun/VirtualMachines/rhel72-q35.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x2'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='dmi-to-pci-bridge'>
      <model name='i82801b11-bridge'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>
    </controller>
    <controller type='pci' index='2' model='pci-bridge'>
      <model name='pci-bridge'/>
      <target chassisNr='2'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:fe:38:23'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/>
    </sound>
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Commands issued:
virsh # attach-interface --domain rhel72-q35 --type network --source default --model virtio --live
Interface attached successfully

virsh # domiflist rhel72-q35
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet0      network    default    virtio      52:54:00:fe:38:23
vnet1      network    default    virtio      52:54:00:70:6d:e5

virsh # 

In the guest:
[root@rhel72 ~]# nmcli device status
DEVICE  TYPE      STATE      CONNECTION 
eth0    ethernet  connected  eth0       
lo      loopback  unmanaged  --         
[root@rhel72 ~]# 

Note: The newly attached interface is missing.
Next reboot the VM:

[root@rhel72 ~]# reboot

Check devices again:
[root@rhel72 ~]# nmcli device status
DEVICE  TYPE      STATE         CONNECTION 
eth0    ethernet  connected     eth0       
eth1    ethernet  disconnected  --         
lo      loopback  unmanaged     --         
[root@rhel72 ~]#
Comment 1 Marcel Apfelbaum 2017-01-25 15:23:17 UTC 
Hi Laine,

Can you please have a look on virsh usage to see if there are any issues?

Specifically:
  "attach-interface --domain rhel72-q35 --type network --source default --model virtio --live"

Is this the "right way" to do it?
It seems to be a 'simple' hotplug operation, how libvirt will do it?

Thanks,
Marcel
Comment 2 Laine Stump 2017-01-26 18:11:45 UTC 
The libvirt you're using is too old to have the code that properly places devices on a pcie-root-port rather than on a pci-bridge slot. RHEL 7.3 doesn't have any of that. See Bug 1330024.

Without those patches, in order to properly do hotplug on Q35, you'll need to take a couple of extra steps:

1) add at least one unused pcie-root-port to the domain config while the guest is shutdown. You can do this with "virsh edit", adding something like this inside the <devices> element:


    <controller type='pci' model='pci-root-port'/>

Add as many root-ports as the number of devices you think you will want to hot-plug.

2) run "virsh dumpxml" on the domain, and note the value of the "index" attribute that was assigned to the new pcie-root-ports you added.

3) start the guest

4) create an XML file for the device you want to hotplug, e.g.:

    <interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' bus='N'/>
    </interface>

where "N" is the index value from one of the newly added pcie-root-ports.

5) instead of "virsh attach-interface ..." use "virsh attach-device"

NB: if you specify "--live" but not "--config" on the commandline, the device will be attached to the current running guest instance, but won't be added to the persistent domain config, so the next time you start the guest the new device will be gone. Additionally, since this is an interface device, a new random MAC address will be generated for the device each time this is done, and the guest OS's config will get cluttered with lots of netdev config (since it will think that it's a completely new device each time).

If the above works, then we should either close this as NOTABUG, or as a duplicate of Bug 1330024
Comment 4 Martin Tessun 2017-02-10 14:39:04 UTC 
(In reply to Laine Stump from comment #2)
> The libvirt you're using is too old to have the code that properly places
> devices on a pcie-root-port rather than on a pci-bridge slot. RHEL 7.3
> doesn't have any of that. See Bug 1330024.
> 
> Without those patches, in order to properly do hotplug on Q35, you'll need
> to take a couple of extra steps:
> 
> 1) add at least one unused pcie-root-port to the domain config while the
> guest is shutdown. You can do this with "virsh edit", adding something like
> this inside the <devices> element:
> 
> 
>     <controller type='pci' model='pci-root-port'/>
> 
> Add as many root-ports as the number of devices you think you will want to
> hot-plug.

Ok. This must be pcie-root-port. So I added one controller via:

        <controller type='pci' model='pcie-root-port'/>

This one got index='3' at startup.

> 
> 2) run "virsh dumpxml" on the domain, and note the value of the "index"
> attribute that was assigned to the new pcie-root-ports you added.
> 
> 3) start the guest
> 
> 4) create an XML file for the device you want to hotplug, e.g.:
> 
>     <interface type='network'>
>       <source network='default'/>
>       <model type='virtio'/>
>       <address type='pci' bus='N'/>
>     </interface>
> 
> where "N" is the index value from one of the newly added pcie-root-ports.
> 
> 5) instead of "virsh attach-interface ..." use "virsh attach-device"
> 

So done this and it works as expected, so the device was hotplugged as expected.

> If the above works, then we should either close this as NOTABUG, or as a
> duplicate of Bug 1330024

*** This bug has been marked as a duplicate of bug 1330024 ***
Note You need to log in before you can comment on or make changes to this bug.