qemu 2.10 locks images with no feature flag
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Opinion
|
Undecided
|
Unassigned | ||
libvirt (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Artful |
Won't Fix
|
Low
|
Unassigned | ||
qemu (Ubuntu) |
Opinion
|
Undecided
|
Unassigned | ||
Artful |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
1) % lsb_release -rd
Description: Ubuntu Artful Aardvark (development branch)
Release: 17.10
2) % apt-cache policy qemu-system-x86
qemu-system-x86:
Installed: 1:2.10~
Candidate: 1:2.10+
Version table:
1:
500 http://
*** 1:2.10~
100 /var/lib/
3) qemu locks image files with no way to discover this feature nor how to disable it
4) qemu provides a way to query if it supports image locking, and what the default value is, and how to disable the locking via cli
qemu 2.10 now will lock image files and warn if an image is currently locked. This prevent qemu from running (and possibly corrupting said image).
However, qemu does not provide any way to determine if a qemu binary actually has this capability. Normally behavior changing features are exposed via some change to the qemu help menu or QMP/QAPI output of capabilities.
I believe this slipped through since libvirt already does image locking, but direct cli users will be caught by this change.
In particular, we have a use-case where we simulate multipath disks by creating to disks which point to the same file which now breaks without adding the 'file.locking=off' to the -drive parameters; which is also completely undocumented and unexposed.
Some parts of the cli like -device allow querying of settable options (qemu-system-x86 -device scsi_hd,?) but nothing equivalent exists for -drive parameters.
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: qemu-system-x86 1:2.10~
ProcVersionSign
Uname: Linux 4.12.0-11-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20.6-0ubuntu7
Architecture: amd64
Date: Fri Sep 8 12:56:53 2017
JournalErrors:
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal' can see all messages.
Pass -q to turn off this notice.
-- Logs begin at Mon 2017-01-30 11:56:02 CST, end at Fri 2017-09-08 12:56:46 CDT. --
-- No entries --
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
MachineType: HP ProLiant DL360 Gen9
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: qemu
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/05/2015
dmi.bios.vendor: HP
dmi.bios.version: P89
dmi.chassis.type: 23
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:
dmi.product.family: ProLiant
dmi.product.name: ProLiant DL360 Gen9
dmi.sys.vendor: HP
Related branches
- Ryan Harper (community): Approve
- Server Team CI bot: Approve (continuous-integration)
-
Diff: 170 lines (+47/-25)3 files modifiedtests/vmtests/__init__.py (+13/-14)
tools/launch (+10/-10)
tools/xkvm (+24/-1)
Changed in libvirt (Ubuntu): | |
importance: | Undecided → Medium |
tags: | added: qemu-file-locking |
Changed in qemu (Ubuntu Artful): | |
status: | New → Won't Fix |
Thanks Ryan for filing this bug, as I said in IRC all the file locking is rather new and I think this is for upstream qemu to address.
Might just be a missed use case for them as well.
I'll be adding an upstream qemu task to get their attention.
@Rayn - It would be nice if - from the multipath tests - you could copy in here a commandline that worked before but fails now.