Open Stack

On Tue, Aug 12, 2014 at 04:50:12PM +0200, Markus Zoeller wrote:
> "Daniel P. Berrange" <berrange at redhat.com> wrote on 08/11/2014 11:39:25 
> AM:
> 
> > From: "Daniel P. Berrange" <berrange at redhat.com>
> > To: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> > Cc: 
> > Date: 08/11/2014 11:49 AM
> > Subject: Re: [Openstack] [nova] Libvirt driver domain metadata - add
> > instance metadata dictionary?
> > 
> > On Fri, Aug 01, 2014 at 03:47:48PM -0500, Matt Riedemann wrote:
> > > 
> > > 
> > > On 7/31/2014 6:58 AM, Markus Zoeller wrote:
> > > >The blueprint "libvirt-driver-domain-metadata" introduces some of the
> > > >istances properties to the `libvirt.xml` file. For example the name
> > > >of the instance, the name of the flavor and the creation date.
> > > >
> > > >Would it make sense to add the instance.metadata dictionary also?
> > > >
> > > >API: /v2/​{tenant_id}​/servers/​{server_id}​/metadata
> > > >Code: https://github.com/openstack/nova/blob/master/
> > > >       nova/objects/instance.py#L148
> > > >
> > > 
> > > You could ask danpb in #openstack-nova IRC about his thoughts, but 
> looking
> > > at the spec and code it looks like a specific metadata schema was in 
> mind.
> > > The metadata that a user can pass in when spawning an instance is 
> arbitrary
> > > so it wouldn't really fit into the schema created unless that was 
> modified
> > > to add some custom values, which would be the user metadata.
> > > 
> > > Is there a use case for putting user metadata in there?  Looks like 
> the
> > > blueprint is for adding specific metadata so an admin can correlate 
> his
> > > libvirt domains against nova API calls.
> > 
> > The intent was primarily to aid in debugging libvirt by providing 
> information
> > that is/was relevant to the libvirt guest configuration.
> > 
> > The instance metadata dict is not something that affects libvirt - IIRC 
> it
> > is only relevant to the guest OS, so i don't think it is relevant to 
> include
> > in the libvirt XML
>  
> Maybe the direction I'm heading is wrong. My intention is to enable a 
> correlation
> between multiple libvirt domains independent from their flavor.
> E.g.
> --------------     --------------    --------------
> | Server: A  |     | Server: B  |    | Server: C  |
> | Flavor: X  |     | Flavor: X  |    | Flavor: Y  |
> | Group: foo |     | Group: bar |    | Group: foo |
> --------------     --------------    --------------
> 
> I'd like to enable the hypervisor to understand that server A and C are 
> correlated
> because of the same "Group: foo". Is there already another mechanism which 
> enables that?

What is the purpose of the grouping ?  The domain metadata in libvirt is
explicitly declared to be completely opaque to the hypervisor and/or
libvirt itself. It holds metadata that is exclusively for use / definition
by the managment application (ie nova itself) and libvirt won't try to
interpret it at all. 

If you're looking at grouping for the POV of doing resource management,
the libvirt has an explicit concept of resource partitioning which allows
you to group VMs together and apply resource constraints to the VMs as
a whole. I don't know if that's what you're after.

http://libvirt.org/cgroups.html#customPartiton

Regards,
Daniel
-- 
|: 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 :|