Hi, I'm looking to extend the setup module to include support for
SunOSVirtual "facts". Currently it looks like there are basically two
virtual facts being detected (on Linux), virtualization_type and
virtualization_role. With solaris zones (freebsd jails is another
example) it's possible to have a solaris zone that is running on a
solaris vmware (or whatever) virtual machine or it could running on a
stand-alone physical solaris box.
Is there any interest in representing this layering in the facts? Or
should the virtualization_type just be a "zone" regardless of what
it's running on?
Thanks,
Likewise, if a solaris vm is hosting some zones, is it's role a guest
or a host at that point?
It seems that the Solaris fact class should should add a new fact key,
'solaris_zone', and it should be None unless it's running from a zone
and not-set on other platforms.
--Michael
Thanks, thinking about this a bit more, I was wondering if it makes
sense to make a new fact key 'container' set at the parent class level
that all the OS's could use. My thinking is that this would be set to
the container type (e.g. zone, jail, openvz, lxc, etc...) if it's a
container, otherwise None. It seems this could kill a few birds with
one stone.
In regards to how to define a VM's 'virtualization_role' if it's
simultaneously a VM on a hypervisor but also hosting containers (zone,
jail) I thinking just keeping it simple and still defining it's role
as a 'guest' makes the most sense.
Thanks,
Thanks, thinking about this a bit more, I was wondering if it makes
sense to make a new fact key 'container' set at the parent class level
that all the OS's could use. My thinking is that this would be set to
the container type (e.g. zone, jail, openvz, lxc, etc...) if it's a
container, otherwise None. It seems this could kill a few birds with
one stone.
Sounds reasonable.
In regards to how to define a VM's 'virtualization_role' if it's
simultaneously a VM on a hypervisor but also hosting containers (zone,
jail) I thinking just keeping it simple and still defining it's role
as a 'guest' makes the most sense.
Hmm...
While these are both "virtualization", the reason you want to know are
different -- in particular, say you want to update vmware tools on all
machines running VMware.
You would not want to lose information that a machine was running
inside VMware because it was also running something underneath that.
So the container idea sounds good.
If it's too hard to set both, though, this is ok.
This is a good point. I'll spend some time determining if it's
possible (in a reliable manner) to detect from within containers if
their host is itself a virtual machine. If anyone knows this about any
of the container technologies I'd be happy to hear from you 
I'll do
some experimenting and also take a look at if/how puppet/chef are
dealing with this. If we can detect this it would be ideal. Otherwise
I'll just stick with the 'container' key.
Thanks,
Hi Gerrit, thanks for the link. We already know how to determine if a
machine is a zone or not though. The thing we want to be able to
determine is if the zone's "parent" (or global zone) is itself a VM.
And we want to determine that from within the zone itself.
Hey,
http://unix.derkeiler.com/Newsgroups/comp.unix.solaris/2010-04/msg00202.html
They are using the command: smbios
smbios|grep VMware
Manufacturer: VMware, Inc.
Product: VMware Virtual Platform
Serial Number: VMware-56 4d 6d f3 ac d3 e0 20-df 74 70 9e 16 cf da bd
VMware SVGA I
At our sparc server:
smbios
smbios: failed to load SMBIOS: System does not export an SMBIOS table
That’s normal.
Gerrit
Thanks! This looked promising but I just tried it in a solaris 10
(x86) zone that is in a Virtualbox VM and get the same error:
bash-3.00# smbios
smbios: failed to load SMBIOS: System does not export an SMBIOS table
too bad... that would have been nice. I haven't had the chance to dig
much more as of yet but I did find that listing the kernel modules
with `modinfo` from within the zone shows that it's a Virtualbox VM:
bash-3.00# modinfo | grep VirtualBox
186 fffffffff6033000 21768 258 1 vboxguest (VirtualBox GstDrv 4.0.4r70112)
256 fffffffff5a41000 19e68 25 1 vboxfs (VirtualBox ShrdFS 4.0.4r70112)
I believe this will work with Vmware and others as well. Gotcha is
that I think the vmware/virtualbox client tools need to be installed
to get this information. If I can't find a better way I think I'll go
this route as I think most people install the client tools and if they
don't we just won't have that information.