On Nov 23, 2017 4:19 PM, "Yaniv Kaul" <ykaul(a)redhat.com> wrote:
On Thu, Nov 23, 2017 at 4:05 PM, Richard W.M. Jones <rjones(a)redhat.com>
wrote:
On Thu, Nov 23, 2017 at 03:00:45PM +0200, Yaniv Kaul wrote:
> On Thu, Nov 23, 2017 at 10:57 AM, Richard W.M. Jones <rjones(a)redhat.com>
> wrote:
>
> > On Tue, Nov 21, 2017 at 11:43:54PM +0200, Yaniv Kaul wrote:
> > > Since I upgrading to FC27, I *sometimes* fail to virt-sysprep.
> > > The debug messages:
> > > libguestfs: trace: set_verbose true
> > > libguestfs: trace: set_verbose = 0
> > > libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program =
python2
> > > libguestfs: trace: set_program "lago"
> > > libguestfs: trace: set_program = 0
> > > libguestfs: trace: add_drive_ro
> > > "/home/ykaul/ovirt-system-tests/deployment-basic-suite-
> > master/default/images/lago-basic-suite-master-host-0_root.qcow2"
> > > libguestfs: trace: add_drive
> > > "/home/ykaul/ovirt-system-tests/deployment-basic-suite-
> > master/default/images/lago-basic-suite-master-host-0_root.qcow2"
> > > "readonly:true"
> > > libguestfs: creating COW overlay to protect original drive content
> > > libguestfs: trace: disk_format
> > > "/home/ykaul/ovirt-system-tests/deployment-basic-suite-
> > master/default/images/lago-basic-suite-master-host-0_root.qcow2"
> > > libguestfs: command: run: qemu-img
> > > libguestfs: command: run: \ info
> > > libguestfs: command: run: \ --output json
> > > libguestfs: command: run: \ /dev/fd/7
> > > qemu-img: Could not open '/dev/fd/7': Failed to get shared
"write"
lock
> > > Is another process using the image?
Looking at this a bit closer, I think this may be a bug in qemu.
/dev/fd/7 is supposed to be the file descriptor of the image which we
have opened in libguestfs, see this code:
https://github.com/libguestfs/libguestfs/blob/06df910491c493
60c0292c7153ba5e5cd09a4735/lib/info.c#L174-L191
I wonder if qemu gets confused by this and thinks that the image is
open in two places?
I can't reproduce this here however. Having a nice short reproducer
might help.
It's not reliably reproduced on my setup either.
I run Lago (
http://lago.readthedocs.io/en/latest/) which is
virt-sysprep'ing several VMs (using direct backend, but they were brought
up via libvirt - is that an issue?).
I don't recall seeing it before upgrading to FC27...
I've never seen it happen with libvirt as the backend btw. I think Lago's
default is direct though.
Y.
Y.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW