5:42 p.m.
On 02/21/2012 03:46 PM, Igor Galić wrote:
Hi folks,
it's been adventurous.
Yesterday night I've started debugging this particular
issue of why my KVMs don't boot on Ubuntu 11.10.
On IRC, we identified the culprit:
<uuid>8cfcb7b0-10ee-7d08-9b64-9f39c154292a</uuid>
<memory>2048</memory>
<currentMemory>2048</currentMemory>
There ain't no way on earth you're going to boot a kernel in 2 megabytes
of memory!
I propose enhancing the XML; on output, libvirt should produce:
<memory units='k'>2048</memory> => 2048 * kibibyte
the output unit must remain the same as it has always been, but the new
attribute will make it easier for humans reading the XML to spot
blunders like what spawned this thread.
On input, the optional attribute is more useful - we can use it to
provide a multiplier (of course, the result will be rounded up to k, and
again rounded up to any higher granularity per the hypervisor):
b => bytes
k, KiB => kibibyte (1024)
KB => kilobyte (1000)
M, MiB => mebibyte (1024*1024)
MB => megabyte (1000000)
and so on for at least G and T (do we need P, E, Z, or Y? and I'm
jealous if you have a machine with 1Y memory).
Thoughts before I propose such a patch?
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
6:27 p.m.
On Wed, Feb 22, 2012 at 04:42:59PM -0700, Eric Blake wrote:
On 02/21/2012 03:46 PM, Igor Galić wrote:
>
> Hi folks,
>
> it's been adventurous.
> Yesterday night I've started debugging this particular
> issue of why my KVMs don't boot on Ubuntu 11.10.
On IRC, we identified the culprit:
> <uuid>8cfcb7b0-10ee-7d08-9b64-9f39c154292a</uuid>
> <memory>2048</memory>
> <currentMemory>2048</currentMemory>
There ain't no way on earth you're going to boot a kernel in 2 megabytes
of memory!
I propose enhancing the XML; on output, libvirt should produce:
<memory units='k'>2048</memory> => 2048 * kibibyte
the output unit must remain the same as it has always been, but the new
attribute will make it easier for humans reading the XML to spot
blunders like what spawned this thread.
On input, the optional attribute is more useful - we can use it to
provide a multiplier (of course, the result will be rounded up to k, and
again rounded up to any higher granularity per the hypervisor):
b => bytes
k, KiB => kibibyte (1024)
KB => kilobyte (1000)
M, MiB => mebibyte (1024*1024)
MB => megabyte (1000000)
and so on for at least G and T (do we need P, E, Z, or Y? and I'm
jealous if you have a machine with 1Y memory).
Thoughts before I propose such a patch?
I like the idea, maybe use units=KiB just to be completely clear?
Dave
3:45 a.m.
Hey,
On Wed, Feb 22, 2012 at 04:42:59PM -0700, Eric Blake wrote:
There ain't no way on earth you're going to boot a kernel in
2 megabytes
of memory!
I propose enhancing the XML; on output, libvirt should produce:
<memory units='k'>2048</memory> => 2048 * kibibyte
the output unit must remain the same as it has always been, but the new
attribute will make it easier for humans reading the XML to spot
blunders like what spawned this thread.
[...]
Thoughts before I propose such a patch?
For what it's worth, there are other places with unitless sizes, there's at
least <video vram=...>, everything under <memtune> and <bandwidth> (not
something measured in bytes though), and these 3 <pool> children:
<allocation>, <capacity> and <available>.
(NB: looked at your patches now and saw you handle memtune)
Also, <volume><allocation> and <volume><capacity> already
support a "unit" attribute which accept the K, M, G, T, P, E values
(xxxbyte), for consistency it would be better for the new <memory> attribute
to use "unit" and not "units" as suggested by Mathias, and for both
"unit"
attributes to accept the same values.
Christophe
4690
days inactive
4691
days old
2 comments
3 participants
participants (3)
-
Christophe Fergeau -
Dave Allan -
Eric Blake