1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
virtual: 0.851
performance: 0.824
user-level: 0.712
hypervisor: 0.689
architecture: 0.615
device: 0.608
arm: 0.603
semantic: 0.600
KVM: 0.591
ppc: 0.579
socket: 0.570
network: 0.569
kernel: 0.566
permissions: 0.554
mistranslation: 0.553
x86: 0.551
peripherals: 0.546
graphic: 0.542
PID: 0.532
debug: 0.475
register: 0.447
vnc: 0.406
VMM: 0.400
boot: 0.399
risc-v: 0.389
assembly: 0.322
TCG: 0.308
files: 0.236
i386: 0.229
qemu became more picky parsing -m option
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?
On 07/31/2017 03:34 AM, Markus Armbruster wrote:
> John Florian <email address hidden> writes:
>
>> Public bug reported:
>>
>> 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?
>
> We recognize suffix "G". Before commit 75cdcd1 (v2.9.0), trailing
> garbage after a recognized suffix was silently ignored. "1.0G",
> "1.0GiB", "1.0Garbage-trucks-of-RAM" were all the same to QEMU. No
> more.
>
> All clear?
That said, virsh from libvirt manages to recognize 'G' and 'GiB' as
synonyms (powers of 2), as well as 'GB' (powers of 10); we could justify
patching qemu's parser to accept more valid suffixes, particularly since
'GiB' is a typical suffix that has seen use (in spite of it not being
documented).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
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.)
Looks like nobody cared to implement this within 3 years ... and IMHO it's maybe even better to not overload the CLI syntax too much ... so I'm closing this ticket now.
|