On Mon, Jun 16, 2014 at 11:54 AM, Karanbir Singh <mail-lists@xxxxxxxxx> 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 _______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
