Description of problem: Cannot get v2v error 'virt-v2v: error: not enough free space for conversion on filesystem' for rhel8 guest Version-Release number of selected component (if applicable): kernel-4.18.0-80.el8.x86_64 libguestfs-1.38.4-10.module+el8+2709+40ed2f2c.x86_64 kernel in guest: 4.18.0-80.el8.x86_64 How reproducible: 100% Steps to Reproduce: 1. In a rhel8 guest, create some files by dd command to consume disk space to <20M. [root@localhost ~]# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/rhel-root 8.0G 7.4G 662M 92% / [root@localhost ~]# dd if=/dev/zero of=file.large2 bs=100M count=6 6+0 records in 6+0 records out 629145600 bytes (629 MB, 600 MiB) copied, 0.414708 s, 1.5 GB/s [root@localhost ~]# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/rhel-root 8.0G 8.0G 62M 100% / [root@localhost ~]# dd if=/dev/zero of=file.large3 bs=1M count=46 46+0 records in 46+0 records out 48234496 bytes (48 MB, 46 MiB) copied, 0.0144467 s, 3.3 GB/s [root@localhost ~]# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/rhel-root 8.0G 8.0G 16M 100% / [root@localhost ~]# stat -f / File: "/" ID: fd0000000000 Namelen: 255 Type: xfs Block size: 4096 Fundamental block size: 4096 Blocks: Total: 2093568 Free: 3950 Available: 3950 Inodes: Total: 70736 Free: 3176 2. Query disk space in guestfish before conversion. # LIBGUESTFS_BACKEND=direct guestfish --ro -d avocado-vt-vm1-nospace Welcome to guestfish, the guest filesystem shell for editing virtual machine filesystems and disk images. Type: ‘help’ for help on commands ‘man’ to read the manual ‘quit’ to quit the shell ><fs> run 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ --:-- ><fs> list-filesystems /dev/sda1: xfs /dev/rhel/root: xfs /dev/rhel/swap: swap ><fs> mount /dev/rhel/root / ><fs> statvfs / bsize: 4096 frsize: 4096 blocks: 2093568 bfree: 6003 bavail: 6003 files: 87160 ffree: 48191 favail: 48191 fsid: 64513 flag: 4096 namemax: 255 ><fs> debug sh "stat -f /sysroot" File: "/sysroot" ID: fc0100000000 Namelen: 255 Type: xfs Block size: 4096 Fundamental block size: 4096 Blocks: Total: 2093568 Free: 6003 Available: 6003 Inodes: Total: 87160 Free: 48191 3. Run v2v command. # virt-v2v -o rhev -os 10.73.194.236:/home/nfs_export -of raw avocado-vt-vm1-nospace -v -x Actual results: Can not get 'virt-v2v: error: not enough free space for conversion on filesystem' error. In v2v log, it shows about 24M space left. mountpoint statvfs /dev/rhel/root / (xfs): bsize=4096 blocks=2093568 bfree=6007 bavail=6007 Expected results: 'virt-v2v: error: not enough free space for conversion on filesystem' should display. Additional info:
Created attachment 1546063 [details] v2v debug log
Noting down the results of an investigation done in the past on the machine kindly provided by Xiaodai Wang (thanks!). It seems like the results of the statvfs API (used by virt-v2v) on the /boot partition of the guest are very different than when executing statvfs (e.g. via stat(1)) on the running guest.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
My apologies, this bug was closed by a broken process that we do not have any control over. Reopening.
I think there is no bug here. First, as far as I understand from comment#0, the conversion actually *succeeded* with virt-v2v; therefore, emitting an error message about "too little space" would have been wrong. The lack of the error message is consistent with the successful conversion. The report is actually about a failure to forcibly trigger this low-space error condition. But I don't know why that is an issue that virt-v2v should handle. I retested the scenario with a Fedora 35 guest that used ext4 for the root filesystem, and -- unsurprisingly -- the "free blocks" count reported inside the guest, while the guest was running live on the rootfs, and the "free blocks" count as reported by libguestfs when the same filesystem was mounted *but not used as rootfs*, differed. The difference was not huge, but there *was* a difference. System processes may very well keep files open on the root filesystem, even deleted files; the blocks for those files are released when the rootfs is finally unmounted during shutdown. In comment 0, the difference is approx. 8MiB (2053×4096), which I think is entirely possible with journals and various other system service databases being in use while the guest is running. Please retry with the following steps: - shut down the guest at first - open the rootfs with guestfish - check the free space available with df-h - on the *host*, create a large file with dd -- the size should be 10MB smaller than the free space reported in the previous step - in guestfish, please use "copy-in", for consuming almost all (except 10MB) space on the guest's rootfs - exit guestfish - initiate the conversion with virt-v2v Thanks!
(In reply to Laszlo Ersek from comment #8) > I think there is no bug here. > > First, as far as I understand from comment#0, the conversion actually > *succeeded* with virt-v2v; therefore, emitting an error message about "too > little space" would have been wrong. The lack of the error message is > consistent with the successful conversion. When there is not enough space in the guest, v2v will report an error like following. [ 14.1] Checking for sufficient free disk space in the guest [stderr] virt-v2v: error: not enough free space for conversion on filesystem [stderr] /. 48.3 MB free < 100 MB needed > > The report is actually about a failure to forcibly trigger this low-space > error condition. But I don't know why that is an issue that virt-v2v should > handle. > > I retested the scenario with a Fedora 35 guest that used ext4 for the root > filesystem, and -- unsurprisingly -- the "free blocks" count reported inside > the guest, while the guest was running live on the rootfs, and the "free > blocks" count as reported by libguestfs when the same filesystem was mounted > *but not used as rootfs*, differed. The difference was not huge, but there > *was* a difference. System processes may very well keep files open on the > root filesystem, even deleted files; the blocks for those files are released > when the rootfs is finally unmounted during shutdown. In comment 0, the > difference is approx. 8MiB (2053×4096), which I think is entirely possible > with journals and various other system service databases being in use while > the guest is running. That makes sense. > > Please retry with the following steps: > > - shut down the guest at first > - open the rootfs with guestfish > - check the free space available with df-h > - on the *host*, create a large file with dd -- the size should be 10MB > smaller than the free space reported in the previous step > - in guestfish, please use "copy-in", for consuming almost all (except 10MB) > space on the guest's rootfs > - exit guestfish > - initiate the conversion with virt-v2v > > Thanks! The guest space required for conversion has been enlarged to 100M, we're not happening with the problem now. see following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1949147 https://bugzilla.redhat.com/show_bug.cgi?id=1764569#c16 I think we can closed it now.
Thanks!