Bug 1418283
| Summary: | virt-v2v: appliance runs out of memory running setfiles command | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Pawan kumar Vilayatkar <pvilayat> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | juzhou, kuwei, mxie, mzhan, ptoscano, pvilayat, rjones, tzheng, xiaodwan |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | V2V | ||
| Fixed In Version: | libguestfs-1.36.1-1.el7 | Doc Type: | Bug Fix |
| Doc Text: |
Cause: when relabelling SELinux guests, the setfiles utility could require more memory (RAM) than needed
Consequence: setfiles using all the memory of the libguestfs appliance (helper VM), and being killed because of that, causing the conversion to fail
Fix: virt-v2v reserves more memory when launching its appliance
Result: the relabelling operation can complete successfully, and so the conversion of SELinux guests
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 22:11:26 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: | |||
| Bug Depends On: | 1359086 | ||
| Bug Blocks: | |||
|
Description
Pawan kumar Vilayatkar
2017-02-01 12:56:54 UTC
Created attachment 1246644 [details]
virt-v2v.log
Before running virt-v2v, can you set this environment variable and see if it fixes the problem: export LIBGUESTFS_MEMSIZE=2048 Hello Richard, Setting the environment variable resolved the problem. I am closing the bugzilla Thanks Thanks for testing this. We have an upstream fix which increases the memory available to the appliance: https://github.com/libguestfs/libguestfs/commit/2b5173712ba07e3e89926c82a236390a4ea6626a Please leave this bug open so it can be included in RHEL 7.4. Reproducer: $ virt-builder fedora-25 --size 10G --output test.img $ guestfish -a test.img -i fill-dir /etc 4000000 $ virt-v2v -i disk test.img -o null Both the guestfish and virt-v2v commands may take a very long time to run. If you can't reproduce the bug, try increasing the constant (4000000) to something even larger. Notice that you may see various different errors from selinux_relabel, because it can run out of memory in slightly different places. However as long as it's selinux_relabel which is breaking, then you are seeing the error. This bug (which is a bug in SELinux) appears to be fixed in Fedora 25+ Verify with below bulids: virt-v2v-1.36.2-1.el7.x86_64 libvirt-3.1.0-2.el7.x86_64 qemu-kvm-rhev-2.8.0-6.el7.x86_64 steps:(same as comment 8): $ virt-builder fedora-25 --size 10G --output test.img $ guestfish -a test.img -i fill-dir /etc 4000000 # virt-v2v -i disk test.img -o null [ 0.0] Opening the source -i disk test.img [ 0.1] Creating an overlay to protect the source from being modified [ 0.3] Initializing the target -o null [ 0.3] Opening the overlay [ 1.5] Inspecting the overlay [ 6.1] Checking for sufficient free disk space in the guest [ 6.1] Estimating space required on target for each disk [ 6.1] Converting Fedora 25 (Twenty Five) to run on KVM virt-v2v: warning: /files/boot/grub2/device.map/hd0 references unknown device "vda". You may have to fix this entry manually after conversion. virt-v2v: This guest has virtio drivers installed. [ 708.8] Mapping filesystem data to avoid copying unused and blank areas [ 708.9] Closing the overlay [ 709.0] Checking if the guest needs BIOS or UEFI to boot [ 709.0] Assigning disks to buses [ 709.0] Copying disk 1/1 to /var/tmp/null.K51C7B/sda (raw) (100.00/100%) [ 725.2] Creating output metadata [ 725.2] Finishing off Hi,rjones,from your comment 8 reproduce steps ,the conversion is successfully . But i am not sure if it can work better in customer Environment. The real bug is a memory leak in the setfiles program. By increasing the memory available to the program, we can make it fail after a longer time (hopefully much longer), but there will always be a case where a disk is so complex that it triggers the memory leak. Apparently we cannot fix the actual setfiles program because that's too complex or something. Anyway, I think we should move this to VERIFIED. From comment 11 and comment 12,move the bug from ON_QA to VERIFIED (In reply to kuwei from comment #11) > Verify with below bulids: > virt-v2v-1.36.2-1.el7.x86_64 > libvirt-3.1.0-2.el7.x86_64 > qemu-kvm-rhev-2.8.0-6.el7.x86_64 > > steps:(same as comment 8): > $ virt-builder fedora-25 --size 10G --output test.img > $ guestfish -a test.img -i fill-dir /etc 4000000 > # virt-v2v -i disk test.img -o null Try to builder a rhel7.3 geust to convert as the steps: steps:: $ virt-builder rhel-7.3 --size 10G --output test.img $ guestfish -a test.img -i fill-dir /etc 4000000 # virt-v2v -i disk test.img -o null [ 0.0] Opening the source -i disk test.img [ 0.1] Creating an overlay to protect the source from being modified [ 0.3] Initializing the target -o null [ 0.3] Opening the overlay [ 1.5] Inspecting the overlay [ 10.2] Checking for sufficient free disk space in the guest [ 10.2] Estimating space required on target for each disk [ 10.2] Converting Red Hat Enterprise Linux Server 7.3 (Maipo) to run on KVM virt-v2v: warning: /files/boot/grub2/device.map/hd0 references unknown device "vda". You may have to fix this entry manually after conversion. virt-v2v: This guest has virtio drivers installed. [ 722.9] Mapping filesystem data to avoid copying unused and blank areas [ 723.7] Closing the overlay [ 723.7] Checking if the guest needs BIOS or UEFI to boot [ 723.7] Assigning disks to buses [ 723.7] Copying disk 1/1 to /var/tmp/null.nUCcAd/sda (raw) (100.00/100%) [ 741.7] Creating output metadata [ 741.7] Finishing off Result: The conversion successfully too. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2023 |