[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] virsh [attach-detach]-device question

On 08/06/2013 08:54 AM, Scott Sullivan wrote:
I have noticed a behavior I am hoping someone can help me understand. Consider the following scenario:

1.) Start a test dummy qemu-kvm instance with no OS via virsh named "no_os".

2.) Attach a device to it;
[root host ~]# virsh attach-device no_os /root/hotplug_device_b.xml
Device attached successfully

[root host ~]#

3.) Now detach the same device;
[root host ~]# virsh detach-device no_os /root/hotplug_device_b.xml
Device detached successfully

[root host ~]#

4.) Now re-attach the same device;
[root host ~]# virsh attach-device no_os /root/hotplug_device_b.xml
error: Failed to attach device from /root/hotplug_device_b.xml
error: internal error unable to execute QEMU command 'device_add': Duplicate ID 'virtio-disk1' for device

[root host ~]#

Is this expected behavior? If so, why does my detach-device call in step 3 appear to not free the device, leading to the duplicate ID error in step 4?

Libvirt XML's used:


<disk type='block' device='disk'>
<driver name='qemu' cache='none'/>
<source dev="/dev/syseng/hotplug_test_b"/>
<target dev="vdb" bus="virtio"/>

I started the "no_os" instance with this:

<domain type="kvm">
<type arch="x86_64" machine="pc-1.1">hvm</type>
<boot dev="hd"/>
<clock offset="utc"/>
<disk type="block" device="disk">
<driver name="qemu" cache="none"/>
<source dev="/dev/LVM/no_os"/>
<target dev="vda" bus="virtio"/>
<disk type="file" device="cdrom">
<target dev="hdc" bus="ide"/>

<serial type="pty">
<target port="0"/>
<console type="pty">
<target port="0"/>
<input type="mouse" bus="ps2"/>
<graphics type="vnc" port="-1" autoport="yes" keymap="en-us"/>
<interface type="bridge">
<mac address="52:54:00:87:14:3d"/>
<source bridge="virbr0"/>
<target dev="no_os_0"/>
<model type="virtio"/>

libvir-list mailing list
libvir-list redhat com

After some digging, it looks like what i'm looking for is covered by this bugzilla:


So we would want to

1. device_del


3. if timeout, drive_del

Might make sense to offer a choice in the API between "fail" and "destroy the block device" if guest doesn't cooperate.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]