Since all but the libvirt task to expose these are set to invalid in
regard to the issue here I'm changing the title accordingly.
As a short term solution for Ubuntu users I forked bug 1776189 to
provide a machine type based solution until this here is implemented and
widely available and exploite
Reported to upstream libvirt's BZ with the suggestions of Daniel Berrage
and David Alan Glibert; now available at [1] I linked that up in the LP
bug status so that we auto-track this.
As eventually this has to go upstream using the bug tracker should
better ensure that there is no concurrent confl
Actually the qemu tasks are "invalid" not "incomplete" as they currently
are - after our discussions here it seems we agreed that qemu is doing
what is intended (and the reasons why larger bits are not the default).
Therefore set the status to that for the qemu tasks.
** Changed in: qemu (Ubuntu)
Crit prio on Qemu which was explained to work just fine is not correct IMHO.
After checking with David he meant to want to raise the prio on the suggested
libvirt extensions instead. I'm re-triaging this bug for that and will ping
David Berrange if work on this is already tracked on a libvirt-BZ
** Changed in: qemu (Ubuntu)
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1769053
Title:
Cannot start a guest with more than 1TB of RAM
To manage notifications
* Gerd Hoffmann (1769...@bugs.launchpad.net) wrote:
> Hi,
>
> > d) For smaller amount of RAM it might still fail if
> > RAM+rounding+pci+hotplug space goes over the limit.
> > Figuring that limit out is tricky (and I thought it
> > might be BIOS/EFI dependent as well depending where th
Hi,
> d) For smaller amount of RAM it might still fail if
> RAM+rounding+pci+hotplug space goes over the limit.
> Figuring that limit out is tricky (and I thought it
> might be BIOS/EFI dependent as well depending where they
> decide to put their PCI devices)
Both seabios and ovm
* Daniel Berrange (1769...@bugs.launchpad.net) wrote:
> Hmm, if we know that QEMU guests will crash & burn when > 1 TB mem, when
> host-phys-bits/phys-bits are unset, then perhaps libvirt should do the
> right thing by default here. eg we can't use host-phys-bits=true due to
> migration compat issu
Hmm, if we know that QEMU guests will crash & burn when > 1 TB mem, when
host-phys-bits/phys-bits are unset, then perhaps libvirt should do the
right thing by default here. eg we can't use host-phys-bits=true due to
migration compat issues, but if we see > 1TB mem, libvirt could
reasonably set phys
* ChristianEhrhardt (1769...@bugs.launchpad.net) wrote:
> On Tue, May 8, 2018 at 10:37 AM, Dr. David Alan Gilbert > wrote:
>
> > * ChristianEhrhardt (1769...@bugs.launchpad.net) wrote:
> > > > Interesting; I thought this was supposed to work.
> > >
> > > Exactly that was my thought when triaging
On Tue, May 8, 2018 at 10:37 AM, Dr. David Alan Gilbert wrote:
> * ChristianEhrhardt (1769...@bugs.launchpad.net) wrote:
> > > Interesting; I thought this was supposed to work.
> >
> > Exactly that was my thought when triaging it initially
> > Furthermore I assume people working la57 (https://lwn
* ChristianEhrhardt (1769...@bugs.launchpad.net) wrote:
> > Interesting; I thought this was supposed to work.
>
> Exactly that was my thought when triaging it initially
> Furthermore I assume people working la57 (https://lwn.net/Articles/730925/)
> and such ran tests on much bigger sizes.
I assu
> Interesting; I thought this was supposed to work.
Exactly that was my thought when triaging it initially
Furthermore I assume people working la57 (https://lwn.net/Articles/730925/) and
such ran tests on much bigger sizes.
> Ah right Dan, if you're seeing the 40 bits physical in the guest you
d
Ah right Dan, if you're seeing the 40 bits physical in the guest you
definitely need to try the flags I suggest in comment 6; host-phys-
bits=true should work for you.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launc
And with non-massive mem (so the guest actually boots up), the guest
does show only 40 bits of phys mem addressing, so qemu will definitely
have to increase that to be able to provide >1TB of phys mem to the
guest (assuming qemu doesn't adjust that dynamically based on the total
mem provided to the
BTW this is the stacktrace I get from a Xenial guest on Xenial host:
[0.00] BUG: unable to handle kernel paging request at c904
[0.00] IP: [] hpet_enable.part.13+0x23/0x2a5
[0.00] PGD 171629ab067 PUD 171629ac067 PMD 171629ad067 PTE
8000fed00073
[0.0
You don't need a >1TB host to spin up a >1TB guest. Unless you're using
pci passthru (and/or SRIOV), or something else that requires qemu to
alloc and pin all guest mem, you can simply overcommit; normal guests
don't require mem pre-allocation or pinning.
On your host do this to allow overcommitt
Interesting; I thought this was supposed to work.
I know we (RH) have some downstream patches for >1TB RAM, but the last I'd
heard they weren't supposed to be necessary any more, except for compatibility
with old versions.
It's probably worth checking the guest view fo the CPUs physical address
Thanks for your clarification Daniel, I'll mark both tasks incomplete
then until you come back with that data.
** Changed in: qemu (Ubuntu)
Status: New => Incomplete
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubu
Hi Christian,
Sorry, I should have been a *lot* more clear.
I wanted to file the bug so that we have somewhere to figure out what needs
to be done and track the progress - trying to avoid it becoming something
we vaguely know about but don't ever do anything about.
Thanks so much for your analys
Hi Daniel,
might I ask what you expect now?
The changes to seabios are not even upstream yet in
git://git.seabios.org/seabios.git
The changes to qemu are neither upstream in git://git.qemu.org/qemu.git
The changes linked also are for a qemu way++ back in time (like pre trusty), so
they just don
** Also affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1769053
Title:
Cannot start a guest with more than 1TB of RAM
To manage notifications
(I'm not trying to start this on my laptop, so ignore the uploaded
files. They're just what apport-bug decided to include.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1769053
Title:
Cannot start
23 matches
Mail list logo
