Bug 1124379
| Summary: | faulty free-space recognition on disk when installing on virtual machine | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vered Volansky <vered> | ||||
| Component: | anaconda | Assignee: | Vratislav Podzimek <vpodzime> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Release Test Team <release-test-team-automation> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.0 | CC: | amureini, vered, vpodzime | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-04-01 17:43:21 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: |
|
||||||
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? (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. 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. /tmp directory where? There's nothing in the host, and the VM wasn't installed, so I have no FS... (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. 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. (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. |
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).