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 1060861 - Test 4TB virtual hosts on large SGI system [TestOnly]
Summary: Test 4TB virtual hosts on large SGI system [TestOnly]
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: 7.0
Assignee: Hai Huang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 920743 1201327
TreeView+ depends on / blocked
 
Reported: 2014-02-03 19:01 UTC by Sherry Crandall
Modified: 2015-03-12 13:55 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 09:45:47 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Sherry Crandall 2014-02-03 19:01:26 UTC 
Description of problem:  Need to test/verify virtual guests up to 4Tb of main memory on hardware with more than 4TB memory.

Version-Release number of selected component (if applicable): RHEL7.0
Comment 2 Russ Anderson 2014-02-18 18:04:25 UTC 
Add Nate to the fun.
Update tracker BZ.
Comment 4 juzhang 2014-03-11 05:48:35 UTC 
Hi Sherry,

Could you update the testing result in the bz?

Best Regards,
Junyi
Comment 5 Russ Anderson 2014-03-11 13:54:03 UTC 
Nate is covering the testing.
Comment 6 juzhang 2014-03-19 03:19:33 UTC 
(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
Comment 7 juzhang 2014-03-24 10:45:44 UTC 
(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
Comment 8 Miya Chen 2014-03-25 03:54:22 UTC 
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.
Comment 9 Russ Anderson 2014-03-25 04:02:55 UTC 
Hi, we will try to get it tested this week.
Comment 10 Nathan Zimmer 2014-03-25 19:00:51 UTC 
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
Comment 12 juzhang 2014-03-26 02:35:45 UTC 
(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
Comment 13 Nathan Zimmer 2014-03-27 22:27:03 UTC 
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?
Comment 14 juzhang 2014-03-28 01:49:33 UTC 
(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
Comment 16 juzhang 2014-03-31 03:40:39 UTC 
(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
Comment 17 Ludek Smid 2014-06-13 09:45:47 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.