Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

instance hard disks (/dev/vda1) smaller than it should be for instance size #15

Open
tracer888 opened this issue May 12, 2013 · 5 comments

Comments

@tracer888
Copy link

Great guide, everything is up and running (though it could use an edit to show to start iscsitarget).

I started a medium image and it shows a small /dev/vda1.

Just to make sure it wasn't a single image, I pulled down a Ubuntu ami and loaded that into glance and started that as well. It shows 1.4G vs 40g like a medium should.

That being said /dev/vda itself does appear to be 40g, so my question is what piece might be missing that is growing the image before it is spawned?

ubuntu@t4:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 1.4G 630M 686M 48% /
none 2.0G 152K 2.0G 1% /dev
none 2.0G 0 2.0G 0% /dev/shm
none 2.0G 48K 2.0G 1% /var/run
none 2.0G 0 2.0G 0% /var/lock
none 2.0G 0 2.0G 0% /lib/init/rw

ubuntu@t4:~$ sudo fdisk /dev/vda
sudo: unable to resolve host t4

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').

Command (m for help): p

Disk /dev/vda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/vda1 * 2 261 2088450 83 Linux

Command (m for help): q

@lorin
Copy link

lorin commented May 14, 2013

Virtual machine images need to be configured to automatically resize on boot. However, the Ubuntu images should be pre-configured to do this, as they contain cloud-init (which issues the resize on boot command) and cloud-utils (which contains the growpart utility that cloud-init will call to resize the partition).

@tracer888
Copy link
Author

That makes sense from looking at some of the rackspace pre-configured 60 gig images. I noticed that Ubuntu 10.04 seems to not allow the reconfiguration, and cirros was having issues too (whatever version was in there). The 12.04 Ubuntu images did allow it.

The hard disk itself was 40 gigs for Centos 6 and ubuntu 10 but it did not auto expand. Just wondering if I may have missed something or if it's all image related.

@lorin
Copy link

lorin commented May 14, 2013

If you're using KVM as your hypervisor, resize behavior is entirely dependent on the image. I believe that "growpart" requires a newer kernel, otherwise you need to do something with the ramdisk so that the resize is done early enough in the boot process.

If you're using XenServer or XCP as your hypervisor backend, and your image contains a single ext2 or ext3 partition, and you're not using LVM on the image, and the appropriate config option is set in nova.conf, then nova-compute will actually do the resize for you.

@tracer888
Copy link
Author

Good to know, yes my setup is using Ubuntu on metal so kvm based. Any ideas on how to tweak the ramdisk to make the resize work? I've searched around, there are definitely a few others following this install as I've seen the same question in the Ubuntu forums (unanswered unfortunately)

@lorin
Copy link

lorin commented May 14, 2013

I'm afraid I don't know how to do this. If you find out, please let me know and I'll add to the docs here: http://docs.openstack.org/grizzly/openstack-compute/admin/content/image-customizing-what-you-need-to-know.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants