[openstack-dev] Blueprint for Nova native image building
john at johngarbutt.com
Wed Aug 7 14:49:06 UTC 2013
On 6 August 2013 23:06, Ian McLeod <imcleod at redhat.com> wrote:
> The proof of concept approach is limited to full-virt hypervisors. It's
> unclear to me if there's a way we can make this work for Xen-backed
> installs without the kind of lower level access to the virt environment
> that we'll get if we exist inside of Nova.
Xen does full virt, its how Windows runs. Xen works best with PV, and
other tools, but its not required.
Maybe I am missing something?
> More generally, it's likely that we'll have more flexibility to behave
> in a sane/optimized manner based on backing hypervisor if the code is
> inside of Nova. For example, we've talked about improving our detection
> of a failed install by monitoring disk IO.
That could be a nice improvement, but its probably not a requirement.
> On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote:
>> On 08/06/2013 03:46 PM, Russell Bryant wrote:
>> That said - if we did service-ify the tool, wouldn't glance be a more
>> appropriate place for that sort of thing?
> Possibly, though the proof of concept (and we hope our proposed
> nova-based re-implementation) can build both glance images and cinder
> volume backed images.
If you want something to create you given parameters, and it produces
you an image, it doesn't need to be part of Nova, and that makes total
However, this proposal is different:
The idea here is quite simple, boot up into a PXE installer, via an
ISO boot. The user access the server via VNC, and can interact with
the installer as they required.
If you use DHCP, you probably don't need anything in nova. However, in
environments without DHCP (i.e. Rackspace Cloud Servers), you need to
Without the injection, the user would have to see what IP address nova
has been given for the VM and enter that manually. So to avoid this,
there is an XenAPI plugin that has been added that can inject that
netwokring information into the ISO that is originally stored in
glance, so the user is then free to continue with the install of the
OS of their choice. Its not really possible to pass that info via
kernel args or similar, so injecting into the ISO image seems the only
In addition to the networking, the proposed blueprint also injects
some other settings, which could be baked into the glance image, but
happens to be injected the same way as networking, because its useful
and means the glance image can be more general, and shared between
different clouds and different cloud regions more easily.
More information about the OpenStack-dev