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 1124379 - faulty free-space recognition on disk when installing on virtual machine
Summary: faulty free-space recognition on disk when installing on virtual machine
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Vratislav Podzimek
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-29 11:32 UTC by Vered Volansky
Modified: 2015-04-01 17:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-01 17:43:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
screenshot (50.33 KB, image/jpeg)
2014-07-29 11:32 UTC, Vered Volansky 		no flags Details
View All

Description Vered Volansky 2014-07-29 11:32:14 UTC 
Created attachment 922116 [details]
screenshot

Description of problem:

We installed RHEL7 on a virtual machine (VM) using ovirt-3.5.
vdsm-4.16.1-0.gita4d9abf.fc20.x86_64 .
We allocated a virtual disk of 10GB.

However, as you can see in the screenshot, the installer sees 10G capacity but only 900k free space. 

When using a 50G virtual disk, the installer continues with no problems.

Version-Release number of selected component (if applicable):
CSB-RHEL7-x86-64-xDEV2.3

Note: this version comes from the PXE, and we're not sure it's bona-fide 7.0
Note: we verified that there is indeed plenty (>60G) of free space in the underlying storage.

How reproducible:
100%

Steps to Reproduce:
1. Create virtual machine, selecting RHEL 7.x as the OS
2. Create a virtual disk, 10GB, thin provisioning
3. Run Once the VM, boot from network
4. Select CSB-RHEL7-x86-64-xDEV2.3

Actual results:

Free space is reported to be 969.23 kb.
The "install destination" is not properly configured. Attempts to configure it fail with the message "new lv is too large to fit in free space".

Expected results:

The installer should continue without problems.


Additional info:
Will supply logs on request (don't know what is relevant or where to get it).
Comment 2 Vratislav Podzimek 2014-08-04 13:55:17 UTC 
Is this really reproducible? I have no idea how ovirt works, but I cannot reproduce this issue with VMs I run on top of qemu/KVM and virt-manager. Are you sure the selected 10 GB disk was empty? Or is oVirt somehow recycling/reusing such disks?
Comment 3 Vered Volansky 2014-08-05 07:21:04 UTC 
(In reply to Vratislav Podzimek from comment #2)
> Is this really reproducible?
yes, really really.
I don't think it matters, but I got to the same spot both when I just ran the VM and injected ALT+CTRL+DEL to spice, then installing the above-mentioned installation, and when I ran-once the VM from NIC, getting straight to the GRUB and selection the same installation.

BTW, this happened with other installations I tried - CSB-RHEL7-x86-64-xDEV2.1 and BETA.

It didn't happen when I tried it with 50G disk - this is where everything went well.

> I have no idea how ovirt works, but I cannot
> reproduce this issue with VMs I run on top of qemu/KVM and virt-manager. Are
> you sure the selected 10 GB disk was empty? Or is oVirt somehow
> recycling/reusing such disks?
I'm positive I selected 10 GB disk - I still have the configuration on ovirt and can see the disks. I used thin provisioning when I created them.
But then again I also used thin provisioning for the 50G disk.
BTW, storage domain was nfs and I used the same one for all. I do have enough space on that storage domain, and there's no recycling on ovirt.
Comment 4 Vratislav Podzimek 2014-08-12 11:24:28 UTC 
Please provide the logs from /tmp directory. I think the issue here is that there's not enough space for swap allocation or something like that.
Comment 5 Vered Volansky 2014-08-12 11:48:15 UTC 
/tmp directory where?
There's nothing in the host, and the VM wasn't installed, so I have no FS...
Comment 6 Vratislav Podzimek 2014-08-12 12:15:12 UTC 
(In reply to Vered Volansky from comment #5)
> /tmp directory where?
> There's nothing in the host, and the VM wasn't installed, so I have no FS...
If you sent CTRL+ALT+F2 to the VM (via spice) it will get you into a shell where you can gather the logs from the /tmp directory. These logs should tell us what's happening.

Is the installation using kickstart? If yes, please attach that kickstart as well. If you cannot get it from ovirt, grab it from /run/install in the same shell as described above.
Comment 7 Vered Volansky 2014-08-13 08:30:01 UTC 
 If you sent CTRL+ALT+F2 to the VM (via spice) it will get you into a shell
> where you can gather the logs from the /tmp directory. These logs should
> tell us what's happening.
I've tried that, unfortunately sending CTRL+ALT+F2 doesn't work for me, not with SPICE and not with VNC.
> 
> Is the installation using kickstart?
I've asked around, and it is using kickstart, but again - I don't have access to it. My environment has changed a lot since creating this bug. I'm sorry I can't be more helpful.
Comment 8 Vratislav Podzimek 2014-08-13 09:02:18 UTC 
(In reply to Vered Volansky from comment #7)
>  If you sent CTRL+ALT+F2 to the VM (via spice) it will get you into a shell
> > where you can gather the logs from the /tmp directory. These logs should
> > tell us what's happening.
> I've tried that, unfortunately sending CTRL+ALT+F2 doesn't work for me, not
> with SPICE and not with VNC.
> > 
> > Is the installation using kickstart?
> I've asked around, and it is using kickstart, but again - I don't have
> access to it. My environment has changed a lot since creating this bug. I'm
> sorry I can't be more helpful.
If you can at least tweak the boot options, you could add 'inst.sshd' to it and then ssh to that machine to grab the logs and the kickstart file.

Otherwise I'm probably going to close this bug report as CANTFIX because I cannot reproduce it on a plain VM in my virt-manager with a newly created 10GB disk image with any standard kickstart I use for testing.
Note You need to log in before you can comment on or make changes to this bug.