Virtual fact should return a list for hosts that can support multiple virtual types
|Keywords:||Affected Facter version:|
The kernel I use on many systems is one that can do xen0, openvzhn, and also virtualbox. Unfortunately, the facter just shows xen0.
#2 Updated by Daniel Pittman almost 3 years ago
FWIW, we have recently hit this same problem at a different level:
We use both KVM virtual hardware machines and OpenVZ container system to divide up machine. Specifically: have have KVM guest systems that are OpenVZ host systems.
To avoid things like installing hardware layer management tools on the OpenVZ host system we are going to have to do something that reports both “KVM guest” and “OpenVZ host” at the same time.
We have no current design to solve this, although I hope to have something in the next week or so to address it.
#5 Updated by Daniel Pittman about 2 years ago
On Thu, Apr 21, 2011 at 10:24, Mark Lehrer email@example.com wrote:
Does it make any sense to return this as a comma-separated list in a string ?
This would work fine for me. I was thinking about something like the processorcount arrangement, but that might be over-engineering it.
So, er, changing the incorrect “there can be only one” fact will actually break production code, since we defined it that way and the values of facts are totally API.
However, the processor count like model of “export one boolean for each matching virtual type” would not have that problem. :)
#8 Updated by Nigel Kersten almost 2 years ago
- Status changed from Needs Decision to Accepted
- Assignee deleted (
is_virtual => true virtual => vmware
Just for some context.
The semantic intent of “virtual” can actually have multiple values for some environments as others have pointed out, but I’m reluctant to provide a comma-separated string here before Facter can provide arrays for facts.
I propose in the meantime we continue to use “is_virtual” as a boolean, leave the current behavior of “virtual” alone, and instead provide “virtual_$provider” boolean facts.