[openstack-dev] RFC: custom metadata per VM instance at boot time (eg for kernel args)
ijw.ubuntu at cack.org.uk
Fri Feb 8 14:19:38 UTC 2013
Seconded (in the generic form, not just for kernel arguments; I'm sure
there are other things that we might want to tweak about the machine
pre-boot in the longer term, as we already do with such things as config
disks and file injection). You may want to have a property in glance that
indicates that, for a given image, you should respect the kernel args
Your proposal is libvirt specific. There's no real reason for it to be.
On 6 February 2013 16:30, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Wed, Jan 30, 2013 at 02:13:29PM +0000, Daniel P. Berrange wrote:
> > I have a need to be able to provide custom kernel command line args per
> > VM instance at boot time. For example, if glance is storing a kernel and
> > initrd pair associated with the Fedora installer, it is neccessary to
> > also provide a command line arg to tell the installer where to download
> > a kickstart automation script from, or where the install tree is located.
> > While some of this data could be stored in glance as metadata properties
> > against the 'kernel' image, some it is inherantly data that changes per
> > VM instance spawned. Thus I need some way to provide it at 'nova boot'
> > time.
> > https://blueprints.launchpad.net/nova/+spec/custom-kernel-args
> > http://wiki.openstack.org/LibvirtCustomKernelArgs
> > Two approaches come to mind for me
> > - Add an explicit 'kernel-args' parameter to the 'nova boot' command
> > and corresponding REST/RPC APIs
> > - Add a generic 'properties' dict parameter to the 'nova boot' command
> > and corresponding REST/RPC APIs, and define a standard property
> > name 'kernel-args'.
> > I'm figuring the latter would be preferrable since it gives us an
> > extensible framework for instance metadata. NB, this is separate
> > from metadata that you can alrady provide to feed through to the
> > cloud-init services via config-drive / metadata service. It is
> > metadata intended for interpretation by Nova itself, where as the
> > existing metadata is for interpretation by the guest OS.
> Does anyone else have an opinion on the design of this proposal ?
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org -o- http://virt-manager.org:|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:|
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev