Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1690910

Summary: Cannot get v2v error 'virt-v2v: error: not enough free space for conversion on filesystem' for rhel8 guest
Product: Red Hat Enterprise Linux 9 Reporter: Xiaodai Wang <xiaodwan>
Component: virt-v2vAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 9.1CC: jsuchane, juzhou, kkiwi, lersek, mxie, mzhan, ptoscano, rjones, tzheng
Target Milestone: rcKeywords: Reopened, Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: V2V
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-04-19 10:59:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
v2v debug log none

Description Xiaodai Wang 2019-03-20 13:04:13 UTC
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:

Comment 1 Xiaodai Wang 2019-03-20 13:04:50 UTC
Created attachment 1546063 [details]
v2v debug log

Comment 2 Pino Toscano 2019-04-12 12:26:15 UTC
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.

Comment 6 RHEL Program Management 2021-07-31 07:27:16 UTC
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.

Comment 7 Richard W.M. Jones 2021-07-31 07:45:34 UTC
My apologies, this bug was closed by a broken process that we
do not have any control over.  Reopening.

Comment 8 Laszlo Ersek 2022-04-18 15:11:40 UTC
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!

Comment 9 Xiaodai Wang 2022-04-19 09:25:54 UTC
(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.

Comment 10 Laszlo Ersek 2022-04-19 10:59:01 UTC
Thanks!