[PATCH] qemu: domfsinfo should print a target name on s390x, not a complete device path

Thomas Huth thuth at redhat.com
Fri Nov 13 07:37:46 UTC 2020


On 13/11/2020 08.21, Peter Krempa wrote:
> On Thu, Nov 12, 2020 at 23:48:02 +0100, Thomas Huth wrote:
>> While fixing domfsinfo for non-PCI (i.e. CCW) devices on s390x,
>> I accidentally used the whole device path for the devAlias field.
>> However, it should only contain the base target name.
>>
>> Currently we have the wrong output:
>>
>>  $ virsh domfsinfo guestname
>>   Mountpoint   Name   Type   Target
>>  ---------------------------------------
>>   /            sda3   xfs    /dev/sda3
>>   /boot        sda1   xfs    /dev/sda1
>>
>> It should look like this instead:
>>
>>  $ virsh domfsinfo guestname
>>   Mountpoint   Name   Type   Target
>>  ------------------------------------
>>   /            sda3   xfs    sda
>>   /boot        sda1   xfs    sda
>>
>> Thus we have to strip the "/dev/" prefix and the partition number
>> from the string.
> 
> This is not the correct approach. While our "target" looks suspiciously
> close to the guest /dev/name it can't be guaranteed to be the same.

Ouch, ok, got it now. On x86, I can apparently say:

 <target dev='vdc' bus='virtio'/>

for my first disk of my guest, and domfsinfo then shows up like this:

Mountpoint                   Name     Type     Target
-----------------------------------------------------------
/                            dm-0     xfs      vdc
/boot                        vda1     xfs      vdc

... very confusing if you're not used to it ;-)

> Stripping prefix and suffix may work in many cases, but if you want to
> uphold what's written in the API docs this won't be always correct.
> 
> I think we need to just relax the documentation of 'virsh domfsinfo' and
> report the path as we do now if the s390x platform is unable to report
> back any information which would allow us to match the device otherwise.

Ok, I'll ponder about this for a while - maybe there's a way to fix this on
s390x ... otherwise I'll consider sending a patch to update the docs.

 Thanks,
  Thomas




More information about the libvir-list mailing list