This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.4
---
qemu (1:2.11+dfsg-1ubuntu7.4) bionic; urgency=medium
* d/p/ubuntu/machine-type-hpb.patch: add -hpb machine type
for host-phys-bits=true (LP: #1776189)
- add an info about this change in debian/qemu-system-x8
In addition we had the same pushed through regression tests (on ppa with
same content).
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
Upgraded:
qemu-block-extra/bionic-proposed 1:2.11+dfsg-1ubuntu7.4 amd64 [upgradable from:
1:2.11+dfsg-1ubuntu7.3]
qemu-kvm/bionic-proposed 1:2.11+dfsg-1ubuntu7.4 amd64 [upgradable from:
1:2.11+dfsg-1ubuntu7.3]
qemu-system-common/bionic-proposed 1:2.11+dfsg-1ubuntu7.4 amd64 [upgradable
from: 1:2.
SRU review for Bionic.
This looks reasonable to me. I'm not so sure about the hardware
enablement exception, but as a new feature it seems like something we'd
want for an LTS anyway, and complies with all the SRU requirements under
that exception. It's an entirely new machine type which isn't expe
- Final test build and test from PPA for target release
- Added SRU Template
- Uploaded to review/acceptance by the SRU Team
- Pushed to package repositories as we consider it proposed
Waiting on SRU Team now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
** Description changed:
+ [Impact]
+
+ * Qemu supports running guests >1TB but currently the virtualization
+stack above has no good way to control that (e.g. libvirt/openstack).
+
+ * Long term we'd want to see bug 1769053 (this is where all started)
+implemented in libvirt and expl
** Also affects: qemu (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: seabios (Ubuntu Bionic)
Importance: Undecided
Status: New
** No longer affects: seabios (Ubuntu Bionic)
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu11
---
qemu (1:2.11+dfsg-1ubuntu11) cosmic; urgency=medium
* d/p/ubuntu/machine-type-hpb.patch: add -hpb machine type
for host-phys-bits=true (LP: #1776189)
- add an info about this change in debian/qemu-system-x86.
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/347801
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1776189
Title:
implement a machine type ba
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/347796
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1776189
Title:
implement a machine type ba
We did a short brainstorm/bikeshed sesssion on the name and decided to:
- use "hpb" for host-phys-bits abbreviation as the former -large could be a lot
of other things
- acked on not start type proliferation in general (only in very special cases)
- if possible use a "+" instead of "-" in the type
Yep, now all things fit together.
- My old (swap based) tests that worked without a change
- working on real >1TB machines without a change.
That said the change to seabios is really not needed.
Setting that task to invalid.
** Changed in: seabios (Ubuntu)
Status: Triaged => Invalid
--
Y
RE: bikeshedding on the name; I don't think -large or -big maps well
the the feature, which is more like -cpu host; ie, give the host cpu
attributes to the guest vcpu.
In this case, we're asking to have host physical addressing bits
applied to the guest vcpus.
So maybe -hpb for HostPhysicalBits?
As assumed the seabios change really IS implemented differently.
That means I have the todo to restest without those.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1776189
Title:
implement a machine
FYI on the bug as I mentione dthis being controllable in higher stacks.
Libvirt is via type="" attribute.
Openstack can control this globally or per image
- global:
https://docs.openstack.org/mitaka/config-reference/compute/config-options.html
- per image: https://docs.openstack.org/image-guide
So far all tests work, but they are still ongoing.
While that is testing I was submitting a request for discussion upstream why
the change is not integrated there.
See: https://mail.coreboot.org/pipermail/seabios/2018-June/012310.html
I hope that the feedback will help to evaluate if we want to
I'll run less case-bound tests in the form of a full pre-upload regression test
on these changes.
Then if safe IMHO can start pushing this to Cosmic and from there consider
Bionic SRU.
Note: due to the fact that Cosmic has no "own" qemu version yet the
change there will also just modify/extend t
I already did some tests with these changes from ppa [1].
This also includes changes to seabios which seem safe for users with less
physical bits and required for those huge guests to work properly.
[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/large-virt
** Also affects: seabios
18 matches
Mail list logo
