[libvirt] [PATCH] update domain status forcibly even if attach a device failed

Wen Congyang wency at cn.fujitsu.com
Fri Feb 18 05:18:01 UTC 2011


At 02/18/2011 05:09 AM, Eric Blake Write:
> On 02/16/2011 08:32 PM, Wen Congyang wrote:
>> Steps to reproduce this bug:
>> 1. virsh attach-disk domain --source diskimage --target sdb --sourcetype file --driver qemu --subdriver qcow2
>>    error: Failed to attach disk
>>    error: operation failed: adding scsi-disk,bus=scsi0.0,scsi-id=1,drive=drive-scsi0-0-1,id=scsi0-0-1 device failed: Property 'scsi-disk.drive' can't find value 'drive-scsi0-0-1'
>> 2. service libvirtd restart
>>    Stopping libvirtd daemon:                                  [  OK  ]
>>    Starting libvirtd daemon:                                  [  OK  ]
>> 3. virsh attach-disk domain --source diskimage --target sdb --sourcetype file --driver qemu --subdriver raw  
>>    error: Failed to attach disk
>>    error: operation failed: adding lsi,id=scsi0,bus=pci.0,addr=0x6 device failed: Duplicate ID 'scsi0' for device
>>
>> The reason is that we create a new scsi controller but we do not update
>> /var/run/libvirt/qemu/domain.xml.
> 
> I agree that this is a bug, and that this patch is one way to solve
> things; however, I'm not convinced it's necessarily the right way.
> 
> Should we be instead rolling back and undoing the new controller
> creation if adding the device fails?

We use qemuDomainFindOrCreateSCSIDiskController() to create scsi disk controller,
so we do not know whether we create a new controller.

> 
> Should the successful addition of a controller save domain state at that
> point, even though that means two saves instead of one if this succeeds
> here?

Yes, it may be another way to solve this bug.
But, it will cause too many saves(For example, if we attach a scsi which uses scsi disk
controller 100, and we will create scsi disk controller 1 to 100)

> 
> But, if others agree with this approach, then ACK to the code.
> 




More information about the libvir-list mailing list