Bug 1511480

Fixed upstream by:

commit 2b41c86294786c07f53afa633fe3dce703debc3c
Author: Peter Krempa <pkrempa>
Date:   Wed Nov 15 14:33:11 2017 +0100

    qemu: Disallow pivot of shared disks to unsupported storage
    
    Pivoting to a unsupported storage type might break the assumption that
    shared disks will not corrupt metadata.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511480

commit 9b2fbfa6f6b535b9f41a7503531d43d86d7a8868
Author: Peter Krempa <pkrempa>
Date:   Wed Nov 15 13:41:01 2017 +0100

    qemu: snapshot: Disallow snapshot of unsupported shared disks
    
    Creating a snapshot would introduce a possibly unsupported member for
    sharing into the backing chain. Add a check to prevent that from
    happening.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511480

commit 3b03a27cd00c2f032661d2bf8905795425752fc7
Author: Peter Krempa <pkrempa>
Date:   Tue Nov 14 15:37:09 2017 +0100

    qemu: domain: Reject shared disk access if backing format does not support it
    
    Disk sharing between two VMs may corrupt the images if the format driver
    does not support it. Check that the user declared use of a supported
    storage format when they want to share the disk.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511480


following patches were pushed as refactors before these:

commit 1fc3cd8731640aefc48bbd9fc489f21cb99c6f67
Author: Peter Krempa <pkrempa>
Date:   Tue Nov 14 15:34:46 2017 +0100

    qemu: block: Add function to check if storage source allows concurrent access
    
    Storage source format backing a shared device (e.g. running a cluster
    filesystem) needs to support the sharing so that metadata are not
    corrupted. Add a central function for checking this.

commit 85b0e2f1260bb169298db5b44859be48426821f0
Author: Peter Krempa <pkrempa>
Date:   Tue Nov 14 14:51:28 2017 +0100

    qemu: domain: Refactor domain device validation function
    
    Use a style that will discourage from adding inline checks.

commit ab948b6299aa311c07bb46b79c6ccbe7d46fb94e
Author: Peter Krempa <pkrempa>
Date:   Tue Nov 14 14:38:14 2017 +0100

    qemu: domain: Move video device validation into separate function

commit a6936ec0987f6b014516e4d51b44c9c9de57a6cb
Author: Peter Krempa <pkrempa>
Date:   Tue Nov 14 14:38:14 2017 +0100

    qemu: domain: Move hostdev validation into separate function

commit 577ccd07c35a8e9b9d682778cc7d6c1d34d891f9
Author: Peter Krempa <pkrempa>
Date:   Tue Nov 14 14:33:19 2017 +0100

    qemu: domain: Despaghettify qemuDomainDeviceDefValidate
    
    Move network device validation into a separate function.

commit 8ffdeed455650557df531aafc66c20b31bd4e0c4
Author: Peter Krempa <pkrempa>
Date:   Wed Nov 15 13:15:57 2017 +0100

    qemu: Move snapshot disk validation functions into one
    
    Move the code so that both the new image and old image can be verified
    in the same function.

Scenario 4 is probably a bug in qemu, when handling opening the files during migration. Please file a new bug assigned to qemu-kvm-rhev tracking this particular problem.

Hmmm, actually, since qemu does not have host-wide knowledge, the problem described in scenario 4 probably can't be solved at all since qemu will not know whether the lock is held by the qemu process which is being migrated or not.

So it is probably impossible for qemu to solve this problem. Whether you want to file a bug or not depends on you, but scenario 4 will require an external lock manager in this case.

Hi, Peter, thx for your timely checking, I have submitted https://bugzilla.redhat.com/show_bug.cgi?id=1531888 (for libvirt) to record this problem.

And what is the problem? It's supposed to have the shareable flag after migration. Shareable also influences selinux labelling and other stuff.

Sry, Update the description in https://bugzilla.redhat.com/show_bug.cgi?id=1511480#c12.
Hi, Peter, I think it's not supposed to have the shareable flag after migration to RHEL7.5.

I don't think it makes sense to forbid such configuration. In case when the image was used with only one VM at least the migration will work. If a second VM would use the image qemu image locking would kick in and forbid starting that process anyways.

Forbidding it would also break loading of saved VMs.

Version
libvirt-3.9.0-7.el7.x86_64
qemu-kvm-rhev-2.10.0-15.el7.x86_64
kernel-3.10.0-826.el7.x86_64
Test scenarios:
Scenario-1: Configure shareable for qcow2 source file in virtual disk
Step 1: Prepare a shutdown VM, edit VM by adding shareable for qcow2 source file in virtual disk, try to save the dumpxml file, it will fail  
# virsh edit test1
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.qcow2'/>
      <target dev='sda' bus='ide'/>
      <shareable/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
error: unsupported configuration: shared access for disk 'sda' requires use of supported storage format
Failed. Try again? [y,n,i,f,?]:
Scenario-2: Create snapshot for raw source file with shareable in virtual disk
Step 1: Prepare a running VM with shareable configured for raw source file in virtual disk
# virsh domstate test1
running
# virsh dumpxml test1 |grep "<disk" -A10
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.img'/>
      <backingStore/>
      <target dev='sda' bus='ide'/>
      <shareable/>
      <alias name='ide0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
Step 2: Try to create snapshot for virtual disk, it will fail
# virsh snapshot-create-as test1 --disk-only --diskspec sda,snapshot=external,file=/tmp/ss1
error: unsupported configuration: shared access for disk 'sda' requires use of supported storage format
Scenario-3: Try to share qcow2 file for 2 VMs at the same time
Step 1: Prepare 2 shutdown VMs with same qcow2 file in virtual disk
# virsh domstate test1;virsh domstate test2
shut off
shut off
# virsh dumpxml test1 |grep "<disk" -A5;virsh dumpxml test2 |grep "<disk" -A5
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.qcow2'/>
      <target dev='sda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.qcow2'/>
      <target dev='sda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
Step 2: Try to start 2 VMs, the 2nd will start failed
# virsh start test1;virsh start test2
Domain test1 started
error: Failed to start domain test2
error: internal error: process exited while connecting to monitor: 
2018-01-14T07:25:53.878709Z qemu-kvm: -drive file=/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.qcow2,format=qcow2,if=none,id=drive-ide0-0-1,cache=none: Failed to get "write" lock
Is another process using the image?

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

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