Bug 1206114 - add an event on device attach
Summary: add an event on device attach
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1179138 1212168
TreeView+ depends on / blocked
 
Reported: 2015-03-26 10:50 UTC by Giuseppe Scrivano
Modified: 2015-11-19 06:24 UTC (History)
9 users (show)

Fixed In Version: libvirt-1.2.15-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1179138
: 1212168 (view as bug list)
Environment:
Last Closed: 2015-11-19 06:24:49 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description Giuseppe Scrivano 2015-03-26 10:50:32 UTC
it seems there is no event that allows libvirt users to detect an attached device (while there is one for detached).

My testing was simply:

# virsh event --loop --all

while I was trying to attach a new device as showed in the 1179138 report.



+++ This bug was initially created as a clone of Bug #1179138 +++

Description:
virt-manager does not show the new added hot-plug devices immediately after virsh command attach device successfully,

Product version
virt-manager-1.1.0-10.el7.noarch
libvirt-1.2.8-11.el7.x86_64
qemu-kvm-rhev-2.1.2-17.el7.x86_64
3.10.0-220.el7.x86_64

How producible
100%

Steps:
1. Prepare a running guest, works well, check the network device in guest and virt-manager
# virsh list
 Id    Name                           State
----------------------------------------------------
 7     rhel7                          running

2. Dumpxml guest for interface list, also checks it in guest
# virsh dumpxml rhel
...
 <interface type='network'>
      <mac address='52:54:00:c6:3b:95'/>
      <source network='default' bridge='virbr0'/>
      <bandwidth>
        <inbound average='1000' peak='5000' burst='1024'/>
        <outbound average='128' peak='256' burst='256'/>
      </bandwidth>
      <target dev='vnet2'/>
      <model type='virtio'/>
      <driver name='vhost' queues='5'/>
      <link state='down'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/>
    </interface>
...

# virsh domiflist rhel7
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet2      network    default    virtio      52:54:00:c6:3b:95

in guest:
# lspci |grep Eth
00:10.0 Ethernet controller: Red Hat, Inc Virtio network device

2. Prepare a network xml, attach it to the guest
# cat /tmp/network1.xml
 <interface type='network'>
      <mac address='52:54:00:b0:8d:2c'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
    </interface>

# virsh attach-device rhel7 /tmp/network1.xml
Device attached successfully

3. Recheck the guest interface list and dumpxml to confirm the network device has been hot-plugged to guest success
# virsh domiflist rhel7
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet2      network    default    virtio      52:54:00:c6:3b:95
vnet3      network    default    rtl8139     52:54:00:b0:8d:2c

# virsh dumpxml rhel
...
<interface type='network'>
      <mac address='52:54:00:c6:3b:95'/>
      <source network='default' bridge='virbr0'/>
      <bandwidth>
        <inbound average='1000' peak='5000' burst='1024'/>
        <outbound average='128' peak='256' burst='256'/>
      </bandwidth>
      <target dev='vnet2'/>
      <model type='virtio'/>
      <driver name='vhost' queues='5'/>
      <link state='down'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:b0:8d:2c'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet3'/>
      <model type='rtl8139'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
...

4. in guest, network exist
# lspci |grep Eth
00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 20)  ----> the is the new added hot-plug network device
00:10.0 Ethernet controller: Red Hat, Inc Virtio network device

5. check with virt-manager for the new added hot-plug network interface device, click "Show virtual hardware details" menu.
the new added NIC device doest not shown, only the old one can be seen.

6. Close virt-manger window and open it again,  or restart libvirtd, the new added hot-plug devices can be seen from virt-manger.

Additional info:
The same issue also hit on hot-plug for disk, console, usb hostdev devices.

Actual result:
Although, virsh command has attached device successfully, but virt-manager does not sync with guest new added hot-plug devices immediately. It is abnormal.

Expected result:
Virt-manage can sync with virsh command immediately for hot-plug device attach.

Comment 2 Ján Tomko 2015-04-04 17:21:28 UTC
Upstream patches proposing the VIR_DOMAIN_EVENT_ID_DEVICE_ADDED event:
https://www.redhat.com/archives/libvir-list/2015-April/msg00183.html
and adding it to the python bindings:
https://www.redhat.com/archives/libvir-list/2015-April/msg00186.html

Note that both the new event and DEVICE_REMOVED are only emitted by the qemu driver.

Comment 3 Ján Tomko 2015-04-15 17:18:29 UTC
Now pushed upstream:
commit b693b2fb731f0f188974c63d84d06dedcfcc6c7a
Author:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2015-04-15 17:06:01 +0200

    Emit VIR_DOMAIN_EVENT_ID_DEVICE_ADDED in the QEMU driver
    
    Only for devices that have an alias.

commit 1882c0bd8d9ebedea527419df32098bdd24b4047
Author:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2015-04-15 17:06:01 +0200

    Add VIR_DOMAIN_EVENT_ID_DEVICE_ADDED event
    
    The counterpart to VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1206114

git describe: v1.2.14-188-gb693b2f

Comment 5 zhenfeng wang 2015-05-28 11:46:00 UTC
Hi Jan
I could verify this bug with the libvirt-1.2.15-2.el7.x86_64 packet, Verify steps as following


1.Start a guest in the first terminal
1.Open the second terminal, run the 'event-test.py' python script to catch the event

# python /usr/share/doc/libvirt-python-1.2.15/examples/event-test.py qemu:///system
Using uri:qemu:///system

2.Open third terminal, run the virsh event command to catch the evetns
#virsh event --all --loop

3.Prepare a network xml
# cat nic.xml
<interface type='network'>
  <source network='default'/>
</interface>

4.Attach the network xml to the guest
# virsh attach-device 7.0 network.xml 
Device attached successfully

# virsh attach-disk 7.0 /var/lib/libvirt/images/test.img vdb
Disk attached successfully

# virsh detach-disk 7.0 vdb
Disk detached successfully


5.Hotplug /hotunplug the disk 

5.Check the events in the second and third terminal could catch the device-add events successfully

# python /usr/share/doc/libvirt-python-1.2.15/examples/event-test.py qemu:///system
Using uri:qemu:///system
myDomainEventDeviceAddedCallback: Domain 7.0(38) device added: net
myDomainEventDeviceAddedCallback: Domain 7.0(38) device added: virtio-disk1
myDomainEventDeviceRemovedCallback: Domain 7.0(38) device removed: virtio-disk1

# virsh event --all --loop
event 'device-added' for domain 7.0: net1
event 'device-added' for domain 7.0: virtio-disk1
event 'device-removed' for domain 7.0: virtio-disk1



However, met a strange thing while run the virsh change-media command, it catched  'disk-change' events for virsh event --loop --all command, however capture 'myDomainEventTrayChangeCallback:' events for "event-test.py" python scripts, I think they should be coincident, can you help confirm it? thanks

1.Start a guest with cdrom in the first termina
# virsh dumpxml 7.0 |grep cdrom -A 6
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <backingStore/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>

2.Create a iso file 
#qemu-img create /var/lib/libvirt/image/test.img 100M

3.Open the second terminal, run the 'event-test.py' python script to catch the event

# python /usr/share/doc/libvirt-python-1.2.15/examples/event-test.py qemu:///system
Using uri:qemu:///system

4.Open third terminal, run the virsh event command to catch the events
#virsh event --all --loop

5.Run the change-media command

# virsh change-media 7.0 hdc /var/lib/libvirt/images/test.img
Successfully updated media.

6.Check the events in the second terminal and the third terminal, found they didn't report the same events, the event-test.py report the 'tray-change' events, virsh events command report the 'disk-change' events

# python /usr/share/doc/libvirt-python-1.2.15/examples/event-test.py qemu:///system
Using uri:qemu:///system
myDomainEventTrayChangeCallback: Domain 7.0(39) tray change devAlias: drive-ide0-1-0 reason: 0
myDomainEventTrayChangeCallback: Domain 7.0(39) tray change devAlias: drive-ide0-1-0 reason: 1


# virsh events --all --loop
event 'disk-change' for domain 7.0 disk drive-ide0-1-0: opened
event 'disk-change' for domain 7.0 disk drive-ide0-1-0: closed

Comment 6 Ján Tomko 2015-05-28 12:17:31 UTC
That's a copy and paste error in virsh's handler for that event. Fixed by:
commit 61139c4438bf9f72271c7df08aada844153ba61d
Author:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2015-05-28 14:14:47 +0200

    Fix the event name in vshEventTrayChangePrint
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1206114#c5
    
    Reported by: zhenfeng wang <zhwang@redhat.com>

git describe: v1.2.16-rc1-10-g61139c4

Comment 7 zhenfeng wang 2015-06-01 09:42:49 UTC
Thanks for Jan's response, since the comment5's issue is a seperate issue for this bug, so mark this verified and file a seprate bug track the comment5's issue.

Comment 9 errata-xmlrpc 2015-11-19 06:24:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html


Note You need to log in before you can comment on or make changes to this bug.