Bug 1458146

Summary: Cannot start pool with <format type='mac'>
Product: Red Hat Enterprise Linux 7 Reporter: yisun
Component: libvirtAssignee: John Ferlan <jferlan>
Status: CLOSED ERRATA QA Contact: jiyan <jiyan>
Severity: low Docs Contact:
Priority: low    
Version: 7.4CC: dyuan, hhan, jiyan, lmen, rbalakri, xuzhang
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-3.7.0-1.el7 Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 10:46:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description yisun 2017-06-02 07:07:50 UTC
Description:
Cannot start pool with <format type='mac'>

Versions:
parted-3.1-28.el7.x86_64
libvirt-3.2.0-5.el7_x86_64

How reproducible:
100%

Steps:
1. Prepare a block device for test ( I used a flash disk )
 ## lsscsi
..
[9:0:0:0]    disk    SanDisk  Cruzer Blade     1.26  /dev/sdd

2. use dd to totally clean up the block dev
## lsblk | grep sdd
sdd             8:48   1   7.5G  0 disk

## dd if=/dev/zero of=/dev/sdd bs=1M count=10000

3. define and build a pool with <format type='mac'> based on this block dev
## virsh pool-dumpxml usbdisk
<pool type='disk'>
  <name>usbdisk</name>
  <uuid>45f95e71-b8be-4a89-9a63-ba448ad5e12a</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <device path='/dev/sdd'/>
    <format type='mac'/>
  </source>
  <target>
    <path>/dev</path>
  </target>
</pool>

## virsh pool-build usbdisk --overwrite
Pool usbdisk built

## parted /dev/sdd p
Model: SanDisk Cruzer Blade (scsi)
Disk /dev/sdd: 8004MB
Sector size (logical/physical): 512B/512B
Partition Table: mac
Disk Flags:
Number  Start  End     Size    File system  Name   Flags
 1      512B   32.8kB  32.3kB               Apple


4. try to start the pool
## virsh pool-start usbdisk
error: Failed to start pool usbdisk
error: Storage volume not found: no storage vol with matching path '/dev/sdd1'

Actual result:
Pool cannot be started

Expected result:
Pool can be started

Additional info:
1. Even if I manually create a sdd1 partition, pool cannot be started either.
2. I saw there is a related patch set https://www.redhat.com/archives/libvir-list/2017-April/msg00461.html
So I use dd to totally clean up the block device in step 2, but pool still cannot be started.

Comment 2 yisun 2017-06-02 07:16:03 UTC
btw it's reproducible on latest libvirt-3.2.0-7

Comment 3 John Ferlan 2017-08-24 14:27:51 UTC

Strange - worked for me with most recent upstream (just prior to 3.7), but I'm not using a physical volume either.  I used an iSCSI served disk...

Still the one thing that stands out to me is the message:

error: Storage volume not found: no storage vol with matching path '/dev/sdd1'

That is probably elicited during virStorageBackendVolOpen when /dev/sdd1 isn't found. What you didn't show in your output is whether /dev/sdd1 exists on the host. There's no lsblk or ls -al to show it being there.  A secondary though would be a 'security related' issue... 

FWIW: The rest is my comparison/notes...

# virsh pool-define usbdisk.xml
Pool usbdisk defined from usbdisk.xml

# virsh pool-build usbdisk --overwrite
Pool usbdisk built

# parted /dev/sdd p
Model: IET VIRTUAL-DISK (scsi)
Disk /dev/sdd: 1074MB
Sector size (logical/physical): 512B/4096B
Partition Table: mac
Disk Flags: 

Number  Start  End     Size    File system  Name   Flags
 1      512B   32.8kB  32.3kB               Apple

# virsh pool-start usbdisk
Pool usbdisk started

# virsh vol-list usbdisk
 Name                 Path                                    
------------------------------------------------------------------------------
 sdd1                 /dev/sdd1                               

# lsblk | grep sdd
sdd                                             8:48   0     1G  0 disk  
├─sdd2                                          8:50   0  1024M  0 part  
└─sdd1                                          8:49   0  31.5K  0 part  

# ls -al /dev/sdd*
brw-rw----. 1 root disk 8, 48 Aug 24 09:36 /dev/sdd
brw-rw----. 1 root disk 8, 49 Aug 24 09:36 /dev/sdd1
brw-rw----. 1 root disk 8, 50 Aug 24 09:36 /dev/sdd2
#

-=-=-=-=-=-=-=-=-=-

So, I grabbed a handy USB stick I have and used it...

# lsscsi
...
[8:0:0:0]    disk    PNY      USB 2.0 FD       1100  /dev/sdo 

# grep sdo usbdisk.xml

# virsh pool-define usbdisk.xml
Pool usbdisk defined from usbdisk.xml

# virsh pool-build usbdisk --overwrite
Pool usbdisk built

# parted /dev/sdo p
Model: PNY USB 2.0 FD (scsi)
Disk /dev/sdo: 16.4GB
Sector size (logical/physical): 512B/512B
Partition Table: mac
Disk Flags: 

Number  Start  End     Size    File system  Name   Flags
 1      512B   32.8kB  32.3kB               Apple

# virsh pool-start usbdisk
Pool usbdisk started

# virsh vol-list usbdisk
 Name                 Path                                    
------------------------------------------------------------------------------
 sdo1                 /dev/sdo1                               

# lsblk | grep sdo
sdo                                             8:224  1  15.2G  0 disk  
└─sdo1                                          8:225  1  31.5K  0 part  

# ls -al /dev/sdo*
brw-rw----. 1 root disk 8, 224 Aug 24 09:56 /dev/sdo
brw-rw----. 1 root disk 8, 225 Aug 24 09:56 /dev/sdo1

Comment 6 jiyan 2017-09-11 08:23:36 UTC
Test env components:
libvirt-3.7.0-2.el7.x86_64
kernel-3.10.0-709.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.6.x86_64

Test scenarios:
Scenario-1: When the pool is created based on a physical USB disk.
1. Prepare a USB disk plugged into host
# lsscsi |grep sdb
[6:0:0:0]    disk    Kingston DT 101 II        1.00  /dev/sdb 

# lsblk |grep sdb
sdb             8:16   1   3.7G  0 disk 

2. Define and build a pool with '<format type='mac'/>' based on the physical USB disk.
# cat pool1.xml 
<pool type='disk'>
  <name>pool1</name>
  <source>
    <device path='/dev/sdb'/>
    <format type='mac'/>
  </source>
  <target>
    <path>/dev</path>
  </target>
</pool>

# virsh pool-define pool1.xml 
Pool pool1 defined from pool1.xml

# virsh pool-build pool1 --overwrite
Pool pool1 built

3. Check the partition table by 'parted' command
# parted /dev/sdb p
Model: Kingston DT 101 II (scsi)
Disk /dev/sdb: 4003MB
Sector size (logical/physical): 512B/512B
Partition Table: mac
Disk Flags: 
Number  Start  End     Size    File system  Name   Flags
 1      512B   32.8kB  32.3kB               Apple

4. Start the pool
# virsh pool-start pool1
Pool pool1 started

5. Check the info of pool, volume and the partition of the physical USB disk
# virsh pool-list --all 
 Name                 State      Autostart 
-------------------------------------------    
 pool1                active     no  

# virsh vol-list pool1
 Name                 Path                                    
------------------------------------------------------------------------------
 sdb1                 /dev/sdb1            

# lsblk |grep sdb
sdb             8:16   1   3.7G  0 disk 
├─sdb1          8:17   1  31.5K  0 part 
└─sdb2          8:18   1   3.7G  0 part 

Scenario-2: When the pool is created based on a iSCSI server disk.
1. Prepare a iSCSI server and the configuration is as follows:
iSCSI server
# targetcli ls
o- / .....................................[...]
  o- backstores ..........................[...]
  | o- fileio ............................[Storage Objects: 1]
  | | o- block ...........................[/home/block/block.qcow2 (1.2GiB) write-back activated]
  o- iscsi ...............................[Targets: 1]
  | o- iqn.2017-09.com.jiyan:pool.target .[TPGs: 1]
  |   o- tpg1 ............................[gen-acls, no-auth]
  |     o- luns ..........................[LUNs: 1]
  |     | o- lun0 ........................[fileio/block (/home/block/block.qcow2) (default_tg_pt_gp)]

2. Login the iSCSI server and check the iSCSI server disk in the test physical host
# iscsiadm -m discovery -t st -p 10.66.4.217
10.66.4.217:3260,1 iqn.2017-09.com.jiyan:pool.target

# iscsiadm -m node -T iqn.2017-09.com.jiyan:pool.target -p 10.66.4.217 --login
Logging in to [iface: default, target: iqn.2017-09.com.jiyan:pool.target, portal: 10.66.4.217,3260] (multiple)
Login to [iface: default, target: iqn.2017-09.com.jiyan:pool.target, portal: 10.66.4.217,3260] successful.

# lsscsi |grep sdc
[7:0:0:0]    disk    LIO-ORG  block            4.0   /dev/sdc 

# lsblk |grep sdc
sdc             8:32   0   1.2G  0 disk 

3. Define and build a pool with '<format type='mac'/>' based on the iSCSI server disk.
# cat pool2.xml 
<pool type='disk'>
  <name>pool2</name>
  <source>
    <device path='/dev/sdc'/>
    <format type='mac'/>
  </source>
  <target>
    <path>/dev</path>
  </target>
</pool>

# virsh pool-define pool2.xml 
Pool pool2 defined from pool2.xml

# virsh pool-build pool2 --overwrite
Pool pool2 built

4. Check the partition table by 'parted' command
# parted /dev/sdc p
Model: LIO-ORG block (scsi)
Disk /dev/sdc: 1321MB
Sector size (logical/physical): 512B/512B
Partition Table: mac
Disk Flags: 
Number  Start  End     Size    File system  Name   Flags
 1      512B   32.8kB  32.3kB               Apple

5. Start the pool
# virsh pool-start pool2
Pool pool2 started

6. Check the info of pool, volume and the partition of the iSCSI server disk
# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------     
 pool2                active     no        

# virsh vol-list pool2
 Name                 Path                                    
------------------------------------------------------------------------------
 sdc1                 /dev/sdc1     

# lsblk |grep sdc
sdc             8:32   0   1.2G  0 disk 
├─sdc1          8:33   0  31.5K  0 part 
└─sdc2          8:34   0   1.2G  0 part 

All the results are as expected, move this bug to be verified.

Comment 10 errata-xmlrpc 2018-04-10 10:46:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0704