[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1707297] Re: qemu became more picky parsing -m option
From: |
John Florian |
Subject: |
[Qemu-devel] [Bug 1707297] Re: qemu became more picky parsing -m option |
Date: |
Mon, 31 Jul 2017 13:09:20 -0000 |
Not sure why I can only see Markus' comment here as part of Eric's but
anyway... the behavior change *is* expected.
Can qemu behave more like virsh then? That would be ideal IMHO. I
prefer to specify my RAM in powers of 2 and disk in powers of 10 so that
when I test virtually using qemu I more closely match the exact
constraints of real hardware. For the embedded work I do fitting in
tight confines, it can make a significant difference.
(I actually to this with a wrapper I have around qemu, which is why you
see a floating point value for GiB in my example above. My wrapper
behaves like virsh and takes any *B, *iB format and regurgitates it into
something qemu accepts.)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1707297
Title:
qemu became more picky parsing -m option
Status in QEMU:
New
Bug description:
With qemu-kvm-2.9.0-3.fc26.x86_64 I am no longer to specify the memory
size using something like "-m 1.00000GiB" but with qemu-
kvm-2.7.1-7.fc25.x86_64 I could without any problem. I now get an
error message like:
qemu-system-x86_64: -m 1.00000GiB: Parameter 'size' expects a non-negative
number below 2^64
Optional suffix k, M, G, T, P or E means kilo-, mega-, giga-, tera-, peta-
and exabytes, respectively.
Is this expected or a regression?
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1707297/+subscriptions