[collectd] [PATCH] UUID plugin for collectd

[Richard W.M. Jones]

Florian Forster wrote:
>> However this is most often useful for virtual guests, where we have a
>> concept of a UUID that refers to the guest for all time, even if the
>> guest is shutdown or migrated to another physical host.
> 
> Just out of curiosity: Why don't hostnames work for you?

For guests there's the question of what we put in the hostname field. 
The previous plugin (libvirtstats) puts the guest's name in this field, 
but there are some problems with this:

   physicalserver1 <--- (hostname of physical server)
     |
      \--- database <--- (name of guest)
      \--- web

   physicalserver2
     |
      \--- database
      \--- web

   coldbackupserver
     |
     (no guests)

Guest names aren't really unique.  Different physical servers may have 
guests with overlapping names as in the example above.  Also guest names 
aren't fixed.  Xen in particular renames guests at will.  For example if 
a guest is about to migrate then Xen renames the guest as 
'migrating-foo' and if the guest is about to shutdown Xen renames it as 
'Zombie-foo'.  The administrator of the physical server can also rename 
guests.

While you're migrating you'll have an intermediate situation like this:

   physicalserver1
     |
      \--- migrating-database
      \--- migrating-web     |
                             | migration
   coldbackupserver          |
     |                       V
      \--- database
      \--- web

During live migrations the old instance ('migrating-foo') is still running.

The UUID is unique across physical servers, and is copied by migration 
and preserved across shutdowns so if you care about which guest your 
stats "really" came from then only the UUID tells you this.

Guests also have a hostname which is separate from the guest's name (the 
guest's name is stored in the hypervisor, the hostname is stored inside 
the guest's kernel).  However it's not feasible to access the guest's 
hostname from the hypervisor since this would involve some sort of 
snooping into the guest kernel.  The guest might be running Windows or 
FreeBSD etc.  The only feasible way to get this is to run an instance of 
collectd inside each guest, but then the uuid plugin will also work in 
this scenario and can get the UUID since it is exposed inside the guest 
either through an emulated BIOS or in /sys/hypervisor/uuid.

I'll fix up the rest of the code & manpage as per your suggestions and 
send another patch.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20071106/89abc6ff/attachment.bin