1 files changed, 105 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1721788 b/results/classifier/zero-shot/108/other/1721788
new file mode 100644
index 000000000..d8874760f
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1721788
@@ -0,0 +1,105 @@
+permissions: 0.746
+network: 0.717
+semantic: 0.668
+graphic: 0.629
+device: 0.606
+PID: 0.605
+other: 0.600
+KVM: 0.528
+debug: 0.522
+files: 0.518
+socket: 0.503
+vnc: 0.496
+boot: 0.492
+performance: 0.486
+
+Failed to get shared "write" lock with 'qemu-img info'
+
+When running 'qemu-img info test.qcow2' while test.qcow2 is currently used by a Qemu process, I get the error
+
+qemu-img: Could not open 'test.qcow2': Failed to get shared "write" lock.
+
+
+Why does displaying information about a disk image need a write lock for the file?
+
+Steps to reproduce:
+
+qemu-img create -f qcow2 test.qcow2 10M
+qemu-system-x86_64 -nographic -drive file=test.qcow2
+qemu-img info test.qcow2
+
+The above was tested with Qemu version 2.10.0
+
+The QEMU process that has the disk image open may be doing I/O that causes qcow2 metadata to be changed. Such changes could confuse the 'qemu-img' process it is was reading the metadata at the same time it was being changed, causing bad data to be printed or worse. So requiring a write lock is the 'safe' thing to do for reliability in the worst case. You can override this by passing '--force-share' arg though.
+
+I've just noticed, however, that '--force-share' appears totally undocumented in both CLI help output and the man page. So that's certainly something that should be fixed
+
+On 10/06/2017 09:09 AM, Jan Heidbrink wrote:
+> Public bug reported:
+> 
+> When running 'qemu-img info test.qcow2' while test.qcow2 is currently
+> used by a Qemu process, I get the error
+> 
+> qemu-img: Could not open 'test.qcow2': Failed to get shared "write"
+> lock.
+> 
+> 
+> Why does displaying information about a disk image need a write lock for the file?
+
+Because there is a risk (albeit rather slight) that what you read from
+the disk is inconsistent due to being an intermediate state in-between
+separate non-atomic write actions by the other process that has it open
+for write.
+
+If you are willing to ignore the risk, then use:
+
+qemu-img info -U test.qcow2
+
+which says that you are okay reading the image while it is shared with a
+concurrent writer, even if the read fails spectacularly in the unlikely
+case that it sees inconsistent information.
+
+-- 
+Eric Blake, Principal Software Engineer
+Red Hat, Inc.           +1-919-301-3266
+Virtualization:  qemu.org | libvirt.org
+
+
+
+This does  not only affect qemu-img only, it could not make libvirt
+"<shareable>" work either when two vms were running with share disk
+image.  Is there a workaround for this situation?
+
+Best,
+Liang
+
+On 10/6/17 10:30 AM, Daniel Berrange wrote:
+> I've just noticed, however, that '--force-share' appears totally
+> undocumented in both CLI help output and the man page. So that's
+> certainly something that should be fixed
+>
+
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+Hi,
+
+What exactly is the problem now?  As Eric explained in comment 3, "qemu-img info -U" is what needs to be used here.  Daniel raised the problem of --force-share/-U being undocumented, but that’s no longer the case as of commit a7e326df1c116e99e, which was first included in the 2.12.0 release.
+
+Max
+
+Ah ok, I think this bug can be closed then.
+
+I have the same problem
+