[CentOS-virt] Preferred method of provisioning VM images

George Dunlap dunlapg at umich.edu
Tue Jun 17 13:45:01 UTC 2014


On Mon, Jun 16, 2014 at 11:54 AM, Karanbir Singh <mail-lists at karan.org> wrote:
> 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.
>
> - KB
> [1]: http://cloud.centos.org/centos/6/devel/
>
> [2] might need to pull in all of libguestfs to make the changes, which
> in turn has its own challenges if run inside a virtualised environ.

I didn't follow this -- virt-builder seems to run fine in dom0 with
qemu, albeit a bit slow.  Upstream is open to having patches for Xen
bindings for the utility VM.

Or is there something else I'm missing?

 -George


More information about the CentOS-virt mailing list