Thank you for your reply!
I know you weren't aiming for that, but this got me thinking, are we
checking that unplug works with not fully specified XML? I mean that
when unplugging, you don't need to specify everything. Whatever
uniquely identifies the device should be enough. So for example just
address or target, definitely no need for the readonly and shareable
flags. But as said, that's not meant to be part of this patch.
I have thought about that before and I agree that a few tests for this
would be useful. I decided not to add them yet, because of the issue
I explained in another patch:
So far, there is only one test for persistent attachment. I will
add more testcases as soon as I hear some feedback on these changes.
qemuhotplugtest.c should first be modified anyway, so that the three
xmls's filenames (basis domain xml, device xml, expected xml) are stated
explicitly instead of being calculated. This will allow for more
flexibility in testing and less xml files duplicates.
link to that patch:
https://www.redhat.com/archives/libvir-list/2016-July/msg00595.html
Adding tests will be a lot easier and without xml files duplication.
I can implement it now, but should I do it on top of the patch
“Test persistent device attachment”, parallelly to it, or wait for the feedback?
[…]
vde2 is an address for a partition. This works? I don't think itshould.[...][…]
... and this? This will never work, so that's another bug right here.
Yay, I am very happy that my tests proved to be useful so fast :)
What exactly is the problem with “vde2”? And is it working properly
if we change “vde2” to “vdea”?
The second problem is that the device aliases are the same for
two different devices. Am I correct?
+ <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
By the way, attaching a device without explicit address and withouttarget dev= specified (only bus='virtio') Should work and that wouldactually test address allocation. By allocating disk with targetdev='XX' the address gets calculated from that device, so no allocationis being tested.
I consider reserving/validating addresses as a part of address
allocation, because they are connected to each other: if some
address is reserved, it can’t be automatically allocated for another
device, and vice versa. So I want to test both of them. But you are
totally right and thank you :)
In this patch I added a test for both of these mixed together:
please, take a look at the last three DO_TEST_* in my patch.
The first two actions (an attachment and a detachment) are
with explicit addresses, and the last action (an attachment)
is with an implicit address.
There are a lot of possibilities to test, for example the first attachment
could also be done with an implicit address. I will write
tests for more cases with pleasure.
Tomasz