author | Richard Jones <rjones@redhat.com> | |
Tue, 6 Nov 2007 14:09:59 +0000 (14:09 +0000) | ||
committer | Florian Forster <octo@huhu.verplant.org> | |
Tue, 6 Nov 2007 17:15:11 +0000 (18:15 +0100) | ||
commit | 30f3e7b81e938d2fcf0512acb46e639a8cb37ae7 | |
tree | 3840864e20cecf0f1553481e58608915b0c7a362 | tree | snapshot |
parent | 9c2dc5d943adc4b8a6081c85896bd87f825a4c23 | commit | diff |
uuid plugin: Add a plugin which sets the hostname to an UUID.
Florian Forster wrote:
> 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.
Rich.
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
Florian Forster wrote:
> 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.
Rich.
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
AUTHORS | diff | blob | history | |
configure.in | diff | blob | history | |
src/Makefile.am | diff | blob | history | |
src/collectd.conf.pod | diff | blob | history | |
src/uuid.c | [new file with mode: 0644] | blob |