Bug 1060861
| Summary: | Test 4TB virtual hosts on large SGI system [TestOnly] | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sherry Crandall <scrandall> |
| Component: | qemu-kvm | Assignee: | Hai Huang <hhuang> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.0 | CC: | aarcange, acathrow, ctatman, gbeshers, gbeshers, hhuang, jdonohue, juzhang, knoel, lwoodman, michen, mrezanin, nzimmer, qzhang, randerso, riel, rja, tee, virt-maint, xfu |
| Target Milestone: | rc | Keywords: | OtherQA, TestOnly |
| Target Release: | 7.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 09:45:47 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: | |||
| Bug Blocks: | 920743, 1201327 | ||
|
Description
Sherry Crandall
2014-02-03 19:01:26 UTC
Add Nate to the fun. Update tracker BZ. Hi Sherry, Could you update the testing result in the bz? Best Regards, Junyi Nate is covering the testing. (In reply to Russ Anderson from comment #5) > Nate is covering the testing. Thanks Russ and Nate. Hi Nate, Could you tell me when can you finish the testing? I'm asking since we need to verify all bzs before 3.28. Thanks. Best Regards, Junyi (In reply to Russ Anderson from comment #5) > Nate is covering the testing. Hi Russ, Could you have a look commnet6 as well? Any news? Best Regards, Junyi Hi John, could you please help point us a contact from SGI to follow up testing and give us a feedback on this bz? thanks. Hi, we will try to get it tested this week. I have been attempting to test this for a few days. However I have had other issues with the os in general. George is hitting simlar issues and has dug a more on them so he may have a bug or series of bugs to mention. It boots fine with 40cpus, I haven't tried it with more and it boots fine with 512GB of ram. However when attempting to boot a VM with more ~1TB of ram it fails very earty on. The guest machine was 3.10.0-110.el7.x86_64 #1 not tainted. This was in the console: BUG: unable to handle kernel paging request at ffff88fab830e3a0 IP: [<ffffffff812cdba4>] ioread32_rep+0x44/0x70 (In reply to Nathan Zimmer from comment #10) > I have been attempting to test this for a few days. However I have had > other issues with the os in general. George is hitting simlar issues and > has dug a more on them so he may have a bug or series of bugs to mention. > > It boots fine with 40cpus, I haven't tried it with more and it boots fine > with 512GB of ram. > > However when attempting to boot a VM with more ~1TB of ram it fails very > earty on. The guest machine was 3.10.0-110.el7.x86_64 #1 not tainted. > > This was in the console: > > BUG: unable to handle kernel paging request at ffff88fab830e3a0 > IP: [<ffffffff812cdba4>] ioread32_rep+0x44/0x70 Hi Nathan, Thanks for your update first. Would you please update the following infos? 1. Your qemu-kvm commandline I'm not sure you are using libvirt or qemu-kvm command line directly. If you are using libvirt tool, you can get the qemu-kvm command line by using "ps -aux | grep qemu-kvm" 2. Your testing host kernel, qemu-kvm and seabios version? Since fully support 4T need these packages' help #rpm -qa | grep kernel #rpm -qa | grep seabios #rpm -qa | grep qemu-kvm 3. I guess your guest is using rhel7.0-64, right? Since you mentioned the guest kernel is 3.10.0-110.el7.x86_64. Best Regards, Junyi Good call, I found that the qemu-kvm wasn't updated It was qemu-kvm-1.5.3-41.el7.x86_64 When I updated to the latest, qemu-kvm-1.5.3-57.el7.x86_64, it booted 4 TB fine. Also I was able to boot with 160 cpus with no issue. Other then booting and running some simple checkouts is there anything else that needs to be examined? (In reply to Nathan Zimmer from comment #13) > Good call, I found that the qemu-kvm wasn't updated > It was qemu-kvm-1.5.3-41.el7.x86_64 > > When I updated to the latest, qemu-kvm-1.5.3-57.el7.x86_64, it booted 4 TB > fine. > Also I was able to boot with 160 cpus with no issue. Cool. > > > Other then booting and running some simple checkouts is there anything else > that needs to be examined? From RedHat kvm QE pov, this bz is opened by SGI and according to comment0, seems make sure vms can boot with 4T is ok. As for this case, we can mark this issue as verified. The following testing scenarios are also welcome, I suggest to opening the new bz if you hit the issue when testing the following scenarios. 1. Repeated stop and start guest with 4T guest 2. Basic operation(boot/reboot/shutdown) 3. Run memory stress tool in guest 4. Boot guest with 4t and enable hugepage 5. Boot guest with >4TB memory 6. Longevity testing 7. Suspend to memory(S3) 8. Suspend to disk(S4) Best Regards, Junyi (In reply to juzhang from comment #14) > (In reply to Nathan Zimmer from comment #13) > > Good call, I found that the qemu-kvm wasn't updated > > It was qemu-kvm-1.5.3-41.el7.x86_64 > > > > When I updated to the latest, qemu-kvm-1.5.3-57.el7.x86_64, it booted 4 TB > > fine. > > Also I was able to boot with 160 cpus with no issue. > 7. Suspend to memory(S3) > 8. Suspend to disk(S4) Thanks Hai kindly reminder about s3/s4 notice in RHEL7.0 Hi Nathan, If you hit s3/s4 with 4T memory related problem, please proposed to rhel7.1 whiling file bz. Best Regards, Junyi > > Best Regards, > Junyi This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |