[openstack-dev] [Nova] Providing instance's guest OS with data (ssh keys, root password, hostname)
Daniel P. Berrange
berrange at redhat.com
Fri Dec 19 14:38:29 UTC 2014
On Fri, Dec 19, 2014 at 05:34:19PM +0300, Dmitry Guryanov wrote:
> On Friday 19 December 2014 14:17:34 Daniel P. Berrange wrote:
> > On Fri, Dec 19, 2014 at 05:11:57PM +0300, Dmitry Guryanov wrote:
> > > Hello,
> > >
> > > If I understood correctly, there are 3 ways to provide guest OS with some
> > > data (SSH keys, for example):
> > >
> > > 1. mount guest root fs on host (with libguestfs) and copy data there.
> > > 2. config drive and cloud-init
> > > 3. nova metadata service and cloud-init
> > >
> > >
> > > All 3 methods do almost the same thing and can be enabled or disabled in
> > > nova config file. So which one is preferred? How do people usually
> > > configure their openstack clusters?
> > >
> > > I'm asking, because we are going to extend nova/libvirt driver to support
> > > our virtualization solution (parallels driver in libvirt) and it seems it
> > > will not work as is and requires some development. Which method is
> > > first-priority and used by most people?
> > I'd probably prioritize in this order:
> > 1. config drive and cloud-init
> > 2. nova metadata service and cloud-init
> > 3. mount guest root fs on host (with libguestfs) and copy data there.
> > but there's not much to choose between 1 & 2.
> Thanks! Config drive already works for VMs, need to check how it will work
> with containers, since we can't add cdrom there.
There are currently two variables wrt config drive
- device type - cdrom vs disk
- filesystem - vfat vs iso9660
For your fully virt machines I'd probably just stick with the default
that ibvirt already supports.
When we discussed this for LXC, we came to the conclusion that for
containers we shouldn't try to expose a block device at all. Instead
just mount the contents of the config drive at the directory location
that cloud-init wants the data (it was somewhere under /var/ but I
can't remember where right now). I think the same makes sense for
parallels' container based guests.
|: 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 :|
More information about the OpenStack-dev