Re: Next step.... more guidance requested
- From: Antti Kantee <pooka@xxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Tue, 16 Jun 2015 17:20:07 +0000
On 16/06/15 11:54, Andrew Stuart wrote:
See the attached screenshot. The dialog contains the ID of the volume being
attached, the ID of the VM (instance) to which it is being attached and allows
you to specify the device name.
Ok, thanks, that's helpful, and I think I now understood.
Bugs notwithstanding, I've fixed things so that you can now use the same
naming in "path" as you use when you specify things from the AWS UI.
For example, if you specify "sda1" as the path, you get access to your
root/kernel partition. If you manage to partition the root storage and
put your data file system image on the second partition, you can use
"sda2" as path. If you still decide to go with your 2nd block device
storage without partitioning, use "sdf". etc.
>> Why isn't *one* block device enough for both?
It’s a good question which I will have to think about more. A few things come
to mind. If you are runing a LInux machine on AWS then absolutely you have full
access to your root EBS boot volume and it is a normal Linux boot volume.
In the case of rump, so far I have seen the 1GB root volume as something of an
annoyance. The rump kernel is only tens of megabytes but we are forced to use
an entire gigabyte block device to load it onto to get the rumpkernel launched.
Presumably most of it is empty and wasted space. In an ideal world, and I’m
guessing Amazon will make this happen perhaps because of unikernels, the size of
the EBS boot device will probably be the same as the size of the kernel plus
grub.
The binary is ~20MB since it's by default built with debugging symbols.
If you strip those out it'll be a lot smaller.
Yes, 1GB is waste space for most of the cases we are interested in. I
don't know if Amazon will want to change it, but we can try to contact
them once we have things in a reasonably working condition.
Other related posts:
