This bug was fixed in the package libvirt - 4.0.0-1ubuntu1
---
libvirt (4.0.0-1ubuntu1) bionic; urgency=medium
* Merged with Debian unstable (4.0)
This closes several bugs:
- Error generating apparmor profile when hostname contains spaces
(LP: #77)
- qemu 2.10
Libvirt will make this "easier" to be avoided by
commit 28907b0043fbf71085a798372ab9c816ba043b93
Author: Peter Krempa
Date: Wed Nov 15 15:21:14 2017 +0100
qemu: command: Mark disks as such in qemu
Qemu has now an internal mechanism for locking images to fix specific
cases of d
I've taked this qemu-file-locking just so we can group/easily find other bugs
that have this tag.
link to search for all bugs with that tag is: https://goo.gl/W2aT2T
or the longer form:
https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=I
** Tags added: qemu-file-locking
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1716028
Title:
qemu 2.10 locks images with no feature flag
To manage notifications about this bug go to:
https://bugs.
** Changed in: libvirt (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1716028
Title:
qemu 2.10 locks images with no feature flag
To manage notifications a
Also on the qemu side this is "works as intended" and workarounds are
documented in this bug.
So we should set that bug status as well - looking back given it was mostly a
discussion I guess "opinion" is the best close status in this case.
** Changed in: qemu (Ubuntu)
Status: Won't Fix =>
Umm, the latter is the official way to go, but only in latter libvirt versions.
https://libvirt.org/git/?p=libvirt.git;a=commit;h=28907b0043fbf71085a798372ab9c816ba043b93
I'm adding a libvirt bug task for the bionic merge to pick that up
"explicitly"
** Changed in: qemu (Ubuntu)
Status: Ne
Note: Depending on the case you might also get lucky with "shareable"
and/or "readonly" disk attributes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1716028
Title:
qemu 2.10 locks images with no f
We had a discussion today on how to workaround if you drive qmeu via libvirt.
While discussions often and up at the correctness of such setups they exists, I
think it is worth to document until libvirt supports that officially.
TL:DR:
- no native libvirt feature yet
- discussions if should set i
Note that 'share-rw' was introduced earlier (commit dabd18f6, qemu 2.9)
than 'locking' (commit 16b48d5d, qemu 2.10), so if qemu 2.9 is relevant
for you, your hacky check doesn't work.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
htt
Kevin,
thanks again. You've provided enough support for me at this point. I had
looked at trying to coalesce multiple -drive values into a single one, and that
can definitely be made to work with the newer qemu, but i'm not sure I can make
it work with older.
the goal there would be to do s
The important difference between your -drive command line and my
-blockdev example is that I used the node-name to reference the image.
You can specify a node-name with -drive, too (having both id and node-
name is one of the main things that I meant what I said mixing both
styles can be confusing)
I see the answer to my question above. 'format' is now driver=qcow2.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1716028
Title:
qemu 2.10 locks images with no feature flag
To manage notification
Your example does work (using -blockdev), but I can't get it to work with
-drive.
$ qemu-system-x86_64 \
-drive id=d01,file=disk1.img,format=qcow2 \
-device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on \
-device drive=d01,serial=s01,driver=virtio-blk,index=2,share-rw=on
warn
The share-rw=on option belongs to -device, not to -drive/-blockdev.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1716028
Title:
qemu 2.10 locks images with no feature flag
To manage notifications
Kevin,
Thanks for the suggestion of share-rw=on. I figured I'd try to change our
'xkvm' wrapper around qemu to use that.
Unfortunately, it looks like , at least in our version of qemu (QEMU emulator
version 2.10.0(Debian 1:2.10+dfsg-0ubuntu1)), that this does not work
with the -drive path.
$ qe
Having a single QEMU process open the same qcow2 file twice is just as
dangerous as having two separate QEMU processes open the same qcow2 file
concurrently. In both cases you have qcow2 state cached in a
BlockDriverState and nothing is able to invalidate the cache in the
other BlockDriverState. S
In our multipath case, the initial open succeeds (it's not locked by
anything else) and the second lock attempt fails, however, IIUC the
fcntl structure[1] includes the locking pid, which should be our
invocation of QEMU;
Can we not check if the locking pid matches the current pid and not
fail? T
** Attachment added: "dump-qmp-schema.py: a hack job to dump and partially
"uncompress" qemu schema output"
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1716028/+attachment/4948029/+files/dump-qmp-schema.py
** Attachment removed: "dump-qmp-schema.py: a hack job to dump and partially
"
** Attachment added: "dump-qmp-schema.py: a hack job to dump and partially
"uncompress" qemu schema output"
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1716028/+attachment/4948028/+files/dump-qmp-schema.py
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Kevin,
Thanks for the information. A couple of points for feedback:
1) there doesn't appear to be a way to run qmp query-schema without
spawning a qemu instance in -qmp mode and having a second client issue
the query-schema; certainly a qemu-system-$arch -qmp-schema would be
quite useful when e
The correct way to query whether file locking is supported is 'query-
qmp-schema', which will expose the 'locking' option for the 'file'
branch of the 'blockdev-add' command then.
As a first comment, in your setup, completely disabling file locking is
probably a too big hammer. It is preferable to
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 te
Added a qemu task, this seems to be a use case affected by the file locking.
In particular a (formerly working) case for multipath tests that use the same
image files multiple times intentionally.
So far the workaround is to set file.locking=off for all these, which might be
just the right thing
** Branch linked: lp:~smoser/curtin/trunk.lp1716028-hack-file-locking-
in-qemu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1716028
Title:
qemu 2.10 locks images with no feature flag
To manage not
25 matches
Mail list logo
