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?

libguestfs: trace: disk_format = NULL (error) libguestfs: trace: add_drive = -1 (error) libguestfs: trace: add_drive_ro = -1 (error) Any ideas? TIA, Y.

_______________________________________________ Libguestfs mailing list Libguestfs(a)redhat.com https://www.redhat.com/mailman/listinfo/libguestfs

On Thu, Nov 23, 2017 at 10:57 AM, Richard W.M. Jones <rjones(a)redhat.com&gt; 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?

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&gt; > 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.

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

On Thu, Nov 23, 2017 at 02:05:32PM +0000, Richard W.M. Jones 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&gt; >> 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/06df910491c49360c0292c7153b... > > 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. This bug has now been reported by a Debian user: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884110

On Thu, Nov 23, 2017 at 02:05:32PM +0000, Richard W.M. Jones 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&gt; > > 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/ 06df910491c49360c0292c7153ba5e5cd09a4735/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. This bug has now been reported by a Debian user: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884110 Yaniv, did you file an upstream bug report and/or get a reliable reproducer? I cannot reproduce this at all.

Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~ rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

What's happening [in the Perl test case, not necessarily in Yaniv's case] is that libguestfs is opening the VMDK file for write, and at the same time ‘qemu-img info’ is opening the VMDK file for read.