On Tue, Nov 21, 2017 at 3:55 AM, Pino Toscano <ptoscano@redhat.com> wrote:> Hi, > > On Monday, 20 November 2017 22:57:04 CET David Kaylor wrote: > > I was trying out virt-builder and noticed that in some directories I > > receive an error when the image is resized. > > > > For example, if I run the following command from my home directory it > works > > fine: > > > > virt-builder rhel-7.4 --size 10G --output test.img > > > > If I run the same command from /tmp or /vms (my default libvirt pool), I > > see the following in my verbose output: > > > > virt-resize '--verbose' '--format' 'raw' '--output-format' 'raw' > '--expand' > > '/dev/sda3' '--unknown-filesystems' 'error' 'test.img' 'test.img' > > command line: virt-resize --verbose --format raw --output-format raw > > --expand /dev/sda3 --unknown-filesystems error test.img test.img > > virt-resize: error: you cannot use the same disk image for input and > output > > > > Am I doing something wrong or is this possibly a bug? The host I am > running > > virt-builder on is Fedora 27. > > The only thing it comes into my mind is that there is already a file > called "test.img" in the directories where it fails. > > Can you please check that, and provide also a full log virt-builder > with -v -x? > > Thanks, > -- > Pino ToscanoThanks, Pino. Attached is the requested log. A few other observations: In most directories, I can run the command successfully whether a file of the same name is present or not. Looking at the verbose output, it appears that a randomly-generated name in /var/tmp is used for the indisk. Example: virt-resize --verbose --format raw --output-format raw --expand /dev/sda3 --unknown-filesystems error /var/tmp/vbaf3053.img test.img For directories where it fails, both the indisk and outdisk are the same: virt-resize --verbose --format raw --output-format raw --expand /dev/sda3 --unknown-filesystems error test.img test.img -David
On Tuesday, 21 November 2017 15:36:02 CET David Kaylor wrote:> On Tue, Nov 21, 2017 at 3:55 AM, Pino Toscano <ptoscano@redhat.com> wrote: > > > Hi, > > > > On Monday, 20 November 2017 22:57:04 CET David Kaylor wrote: > > > I was trying out virt-builder and noticed that in some directories I > > > receive an error when the image is resized. > > > > > > For example, if I run the following command from my home directory it > > works > > > fine: > > > > > > virt-builder rhel-7.4 --size 10G --output test.img > > > > > > If I run the same command from /tmp or /vms (my default libvirt pool), I > > > see the following in my verbose output: > > > > > > virt-resize '--verbose' '--format' 'raw' '--output-format' 'raw' > > '--expand' > > > '/dev/sda3' '--unknown-filesystems' 'error' 'test.img' 'test.img' > > > command line: virt-resize --verbose --format raw --output-format raw > > > --expand /dev/sda3 --unknown-filesystems error test.img test.img > > > virt-resize: error: you cannot use the same disk image for input and > > output > > > > > > Am I doing something wrong or is this possibly a bug? The host I am > > running > > > virt-builder on is Fedora 27. > > > > The only thing it comes into my mind is that there is already a file > > called "test.img" in the directories where it fails. > > > > Can you please check that, and provide also a full log virt-builder > > with -v -x? > > > > Thanks, > > -- > > Pino Toscano > > > Thanks, Pino. Attached is the requested log. A few other observations: > > In most directories, I can run the command successfully whether a file of > the same name is present or not. > > Looking at the verbose output, it appears that a randomly-generated name in > /var/tmp is used for the indisk. Example: > > virt-resize --verbose --format raw --output-format raw --expand /dev/sda3 > --unknown-filesystems error /var/tmp/vbaf3053.img test.img > > For directories where it fails, both the indisk and outdisk are the same: > > virt-resize --verbose --format raw --output-format raw --expand /dev/sda3 > --unknown-filesystems error test.img test.imgHmm... can you please paste the output of `findmnt --df`? In addition to that, do /tmp or /vms (mentioned above by you) have any special mount point (or free space)? What's the exact version of libguestfs? (`rpm -q libguestfs`) -- Pino Toscano
(In addition to Pino's question) Does test.img (the output file) exist? If so does it work if you delete it before running the command? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Tue, Nov 21, 2017 at 10:44 AM, Pino Toscano <ptoscano@redhat.com> wrote:> On Tuesday, 21 November 2017 15:36:02 CET David Kaylor wrote: > > On Tue, Nov 21, 2017 at 3:55 AM, Pino Toscano <ptoscano@redhat.com> > wrote: > > > > > Hi, > > > > > > On Monday, 20 November 2017 22:57:04 CET David Kaylor wrote: > > > > I was trying out virt-builder and noticed that in some directories I > > > > receive an error when the image is resized. > > > > > > > > For example, if I run the following command from my home directory it > > > works > > > > fine: > > > > > > > > virt-builder rhel-7.4 --size 10G --output test.img > > > > > > > > If I run the same command from /tmp or /vms (my default libvirt > pool), I > > > > see the following in my verbose output: > > > > > > > > virt-resize '--verbose' '--format' 'raw' '--output-format' 'raw' > > > '--expand' > > > > '/dev/sda3' '--unknown-filesystems' 'error' 'test.img' 'test.img' > > > > command line: virt-resize --verbose --format raw --output-format raw > > > > --expand /dev/sda3 --unknown-filesystems error test.img test.img > > > > virt-resize: error: you cannot use the same disk image for input and > > > output > > > > > > > > Am I doing something wrong or is this possibly a bug? The host I am > > > running > > > > virt-builder on is Fedora 27. > > > > > > The only thing it comes into my mind is that there is already a file > > > called "test.img" in the directories where it fails. > > > > > > Can you please check that, and provide also a full log virt-builder > > > with -v -x? > > > > > > Thanks, > > > -- > > > Pino Toscano > > > > > > Thanks, Pino. Attached is the requested log. A few other observations: > > > > In most directories, I can run the command successfully whether a file of > > the same name is present or not. > > > > Looking at the verbose output, it appears that a randomly-generated name > in > > /var/tmp is used for the indisk. Example: > > > > virt-resize --verbose --format raw --output-format raw --expand /dev/sda3 > > --unknown-filesystems error /var/tmp/vbaf3053.img test.img > > > > For directories where it fails, both the indisk and outdisk are the same: > > > > virt-resize --verbose --format raw --output-format raw --expand /dev/sda3 > > --unknown-filesystems error test.img test.img > > Hmm... can you please paste the output of `findmnt --df`? In addition > to that, do /tmp or /vms (mentioned above by you) have any special > mount point (or free space)? > > What's the exact version of libguestfs? (`rpm -q libguestfs`) > > -- > Pino ToscanoThere is nothing special about the mounts and there is enough free space on both. Here is the requested output: $ findmnt --df SOURCE FSTYPE SIZE USED AVAIL USE% TARGET devtmpfs devtmpfs 15.4G 0 15.4G 0% /dev tmpfs tmpfs 15.4G 267.7M 15.1G 2% /dev/shm tmpfs tmpfs 15.4G 2.2M 15.4G 0% /run tmpfs tmpfs 15.4G 0 15.4G 0% /sys/fs/cgroup /dev/mapper/fedora-root ext4 452.2G 45.4G 383.8G 10% / selinuxfs selinuxfs 0 0 0 - /sys/fs/selinux tmpfs tmpfs 15.4G 3.3M 15.4G 0% /tmp /dev/nvme0n1p1 ext4 975.9M 196.6M 712.1M 20% /boot /dev/mapper/luks-c4229932-74e7-4cdf-a8e9-e814004cc4c2 ext4 468.5G 291.1G 153.5G 62% /vms tmpfs tmpfs 3.1G 16K 3.1G 0% /run/user/42 tmpfs tmpfs 3.1G 80K 3.1G 0% /run/user/24951 gvfsd-fuse fuse.gvfsd-fuse 0 0 0 - /run/user/24951/gvfs $ rpm -q libguestfs libguestfs-1.37.31-1.fc27.x86_64 Thanks, David
On Tue, Nov 21, 2017 at 09:36:02AM -0500, David Kaylor wrote:> [ 2.9] Planning how to build this image > 0: itags: +filename=/home/dkaylor/.cache/virt-builder/rhel-7.4.x86_64.2 +size=6442450944 +format=raw +template +xz > 0: task : pxzcat > 0: otags: +filename=test.img +size=6442450944 +format=raw > > 1: itags: +filename=test.img +size=6442450944 +format=raw > 1: task : virt-resize > 1: otags: +filename=test.img +size=8589934592 +format=rawThis plan is completely bogus. Why is it choosing to write to the output file? I think what's happened here is that when I rewrote the planner weights (https://github.com/libguestfs/libguestfs/commit/a6a982f004ac0e861d1889219163ec5e6d7c8924) it has exposed a latent bug. It should be dropping any plan which involves running virt-resize on a same-named file, since that is impossible. Probably adjusting the weights caused that plan to become the best one, exposing the (existing) bug. I'll have to think about this one ... 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