[CentOS-virt] Preferred method of provisioning VM images

Tue Jun 17 10:11:36 UTC 2014
lee <lee at yun.yagibdah.de>

Karanbir Singh <mail-lists at karan.org> writes:

> On 06/10/2014 05:21 PM, Lars Kurth wrote:
>> == #4 Cloud Image from Cloud Image SIG ==
>> We could rely on pre-built cloud images from the Cloud Images SIG. 
>> People could just download the cloud image once it's done and customize 
>> it, rather than installing / building their own.
>> 
>> Advantages: seems easy
>> 
>> Disadvantages: coordination with Cloud Images SIG. May not be flexible 
>> enough
>
> We ship a test/devel grade CentOS-6-x86_64-pv image ( well, its a qcow2
> image, should work for pvhvm as well, the fstab is label driven ).[1]
>
> The biggest problem in doing pre-baked images is the instance metadata.
> We need to find an easy way to get network settings into the instance
> and the root password ( or key ), and finally - in some cases, console
> redirection/setup, but i dont think the console is a deal breaker or a
> big deal. The network and access credentials however are.
>
> In a typical cloud environ this info would come from the cloud
> controller's metadata service; on a typical virtualised setup though
> this becomes an issue ( and isnt really Xen specific ).
>
> We could work around this by making some assumptions, we could 'own'
> dnsmasq and ensure that either libvirt is running and doing dhcp,
> otherwise we do the dhcp with some sane defaults, or we setup a script
> to 'instantiate image', which asks how the user wants to setup the
> instance ( pvhvm, hvm, pv ), the root password or key to use, and the
> network settings ( and if this is run on the dom0, we could even ask
> what bridge or device to connect with as well as the settings ).[2]
>
> Ofcourse, having these images pushed from here mean that clouds or
> virtualised environs that have metadata services are able to just-use
> the image as is, not needing any more tooling etc. And we can easily
> push monthly image updates and when things like heartbleed come around,
> there is a single place we need to update.

Wouldn't you still need to configure the services running in each VM?


-- 
Knowledge is volatile and fluid.  Software is power.