VM Image Size Dismatch

[Brian Huang]

The platform is Proxmox v1.8. I created a VM with the size of 75G. During the installation, Ubuntu 10.04 reported that the size of available disk was 80.5G. I did the math:

75*1024*1024*1024=80530636800

Does this mean Proxmox actually assign 80.530636800G instead of 75G?

 

[dietmar]

Does this mean Proxmox actually assign 80.530636800G instead of 75G?

Yes, 75G are 80530636800 bytes - what is the question?

 

[Brian Huang]

Yes, 75G are 80530636800 bytes but 80530636800 bytes are not 80.5G. The guest, Ubuntu 10.04, is actually getting 80.5G in size instead of 75G.
I was wondering why I got 80.5G when I assigned 75G. I did the math, trying to figure out the relation between the two figures, 75G and 80.5G. I think this is where the error comes.

 

[claytonjr]

I've seen this bug (?) more so with the QEMU package. I've seen this in Debian and a few versions of Ubuntu. You can specify a 20G hdd, and it will report something like 21.5G during the installation.

While it is a bit odd, I've never seen it become a problem.

 

[Brian Huang]

Claytonjr. Thanks for comfirming the issue.
I forgot to mention the image format. I use RAW.
I want to use DRBD to replication a block of an image on VMWare to another block of an image on Proxmox. This bug(supposed?) may create some problems although I can make the two replicating blocks of the same size.

 

[udo]

Claytonjr. Thanks for comfirming the issue.
I forgot to mention the image format. I use RAW.
I want to use DRBD to replication a block of an image on VMWare to another block of an image on Proxmox. This bug(supposed?) may create some problems although I can make the two replicating blocks of the same size.

Hi,
this is not an bug!
The old way is to use GB as 1024*1024*1024. But the harddisk-manufactures think that the people have an problem with 1024 - 1000 is much better! And hoops, the hdds are bigger!!
This is normaly called GiB, and unfortunality some distros/Programs also use this "easy math".

But this is normaly no problem - if you convert a machine (to lvm-storage) you must even look for space (e.g. extends) and perhaps expand this - easy doing.
E.G. if you create your volume group with -s 4M, you must only devide your bytes of the raw-partition (vmware, or anything else) through (4096*1024) and you get the amoung of extends, which your lv need.

If your lv is 2 extends too small, simple "lvextend -l +2 /dev/vggroup/vm-100-disk1".
Look before with lvdisplay...

Udo

 

[Brian Huang]

Hi,
this is not an bug!
The old way is to use GB as 1024*1024*1024. But the harddisk-manufactures think that the people have an problem with 1024 - 1000 is much better! And hoops, the hdds are bigger!!
This is normaly called GiB, and unfortunality some distros/Programs also use this "easy math".

But this is normaly no problem - if you convert a machine (to lvm-storage) you must even look for space (e.g. extends) and perhaps expand this - easy doing.
E.G. if you create your volume group with -s 4M, you must only devide your bytes of the raw-partition (vmware, or anything else) through (4096*1024) and you get the amoung of extends, which your lv need.

If your lv is 2 extends too small, simple "lvextend -l +2 /dev/vggroup/vm-100-disk1".
Look before with lvdisplay...

Udo

Thanks. My bad. That is the problem of Ubuntu.