Re: [Qemu-devel] [PULL 22/27] vl: Create block backends before setting machine properties

[Michal Privoznik <mprivozn@redhat.com>]

On 5/16/19 1:43 PM, Markus Armbruster wrote:
<snip/>

>> Actually, there is more problems with this. Trying to run a guest with
>> persistent reservations fails after this patch is applied (git bisect
>> points me to this commit). My command line is:
>>
>> qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 \
>> -monitor stdio \
>> -object pr-manager-helper,id=pr-helper0,path=/tmp/pr-helper0.sock
>> -drive
>> file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2
>> \
>> -device
>> scsi-block,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2
>>
>> Honestly, I have no idea how to fix it, so I'm just raising this issue
>> here. Do you want me to open a bug or something?
> 
> Let's skip the bug filing bureaucracy and go straight to debugging.

Agreed.

> 
> Actual and expected behavior of your reproducer, please :)
> 

Actual is that qemu fails to parse cmd line:


qemu-system-x86_64: -drive 
file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2: 
No persistent reservation manager with id 'pr-helper0'


Which obviously is not correct, because pr-helper0 is specified.
Expected result is that qemu suceeds in parsing the cmd line and starts 
the guest. To test it you don't need /dev/mapper/* really, I mean, if 
qemu fails with a different error message (e.g. it can't open the disk 
or EPERM or whatever), it's a sign it got past the cmd line parsing 
successfuly.

Michal