On Thu, Nov 23, 2017 at 10:57 AM, Richard W.M. Jones <rjones@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? > > Is something else using the lago-basic-suite-master-host-0_root.qcow2 > image at the same time? >Not that I know of...> > I'm not clear if the backend is libvirt or direct. For libvirt we > don't have a solution to this yet, although there is a patch series > you can try: >I think we use direct by default. Y.> > https://www.redhat.com/archives/libvir-list/2017-November/msg00617.html > > Rich. > > > 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@redhat.com > > https://www.redhat.com/mailman/listinfo/libguestfs > > > -- > 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 >
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@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/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. 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 4:05 PM, Richard W.M. Jones <rjones@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@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/ > 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. >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... 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 >
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@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/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