I think the command-line is far more flexable then the GUI interface. I use ec2-api-tools, but the python boto stuff works virtually the same. On Thu, 30 Apr 2015, Nico Kadel-Garcia wrote: > On Wed, Apr 29, 2015 at 11:33 PM, Kelly Prescott <kprescott at coolip.net> wrote: >> to follow-up, I will give an example. >> Here is the listing for the official centos AMI: >> >> IMAGE ami-96a818fe aws-marketplace/CentOS 7 x86_64 (2014_09_29) EBS >> HVM-b7ee8a69-ee97-4a49-9e68-afaee216db2e-ami-d2a117ba.2 aws-marketplace >> available public [marketplace: aw0evgkw8e5c1q413zgy5pjce] >> x86_64 machineebs hvm xen >> BLOCKDEVICEMAPPING EBS /dev/sda1 snap-591037fd 8 >> false standard Not Encrypted >> as you can see the block device mapping is by default set to >> BLOCKDEVICEMAPPING EBS /dev/sda1 snap-591037fd 8 >> false standard Not Encrypted >> >> it is a standard volume, not encrypted, and 8 GB >> my modification consists in adding this to my run command for my ami launch: >> -b /dev/sda1=snap-591037fd:20:false:gp2 >> >> I set the drive the same, the snapshot the same, and I give it 20GB instead >> of 8, I also use the gp2 type instead of the standard as well as telling it >> not to delete the volume when the instance terminates. >> >> Hope this helps. >> kp > > Perhaps so, and I appreciate the pointer. I can try to work with that > to integrate command line based deployment and get this option. > > So you're working from the command line tools in the EPEL 'cloud-init' > package, not the AWS GUI? Because when I tried expanding the size of > the base disk image in the GUI, I wound up with an an 8 Gig default > /dev/xvda1 on a 20 Gig /dev/xvda. That's why I was looking at "how do > I resize this thing safel?" > > Unfortunately, it doesn't help a lot with what I already have built, > but could be useful going forward. > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt >