(imported topic written by mc116991)
Full featured agent to inventory the system and patch it. Large ESX infrastructure!
(imported comment written by mynameisbear91)
mc1169
Full featured agent to inventory the system and patch it. Large ESX infrastructure!
What exactly would it be patching?
If you’re suggesting that they should be patching the ESX hypervisor, I strongly disagree. I also strongly disagree with the notion that BigFix should be running as a part of the hypervisor at all. I’ll assume that’s not what you’re suggesting.
If you’re suggesting that they should be patching the guest operating systems that run under ESX, you should be running the BES Client on the guest operating systems. Otherwise, how do you propose that an agent knows enough about the guest OS to get the required information from the filesystem/registry/etc?
Conrad
(imported comment written by rharmer91)
If it doesn’t patch it (which I’m fine with), I’d like the inventory information.
(imported comment written by SystemAdmin)
Hi Cgolightly,
If you’re suggesting that they should be patching the ESX hypervisor, I strongly disagree. I also strongly disagree with the notion that BigFix should be running as a part of the hypervisor at all.
Could you explain your position on why you would not want BigFix on the ESX hypervisor in more detail? We have heard lots of requests from customers wanting to put the agent on the the ESX hypervisor before for inventory first and management (patches, configurations, ect…) second. The rational seems to be that it’s an OS/Hardware on the network and needs to be managed like anything everything else in the enterprise. The hosted OSes also need to have the client on them to do patches/configuration to prevent security problems. So, I would like to hear more information about why you would not want the client on the host OS, maybe there may be downsides or special considerations for ESX we should be looking into here that we’ve overlooked.
(imported comment written by mynameisbear91)
I probably jumped the gun a bit by using the word hypervisor in the first place, but I’ve seen similar questions about other products that repeatedly used the word hypervisor without fully understanding the concepts.
Just to make sure we’re on the same page, ESX has a type-1 hypervisor that runs directly on bare metal, unlike VMware Server or VMware workstation which run on top of Windows (type-2 hypervisor.) The “Linux box” you see when you install the product and reboot for the first time is actually a virtual machine (over which the end-user has little control) running on top of the hypervisor.
Here are my questions:
- Do you
actually
intend to run a BigFix client directly on the hypervisor, or do you intend to load it into the service console like OpenManage and other hardware lifecycle management agents?
- When “patching” is mentioned, I’m interested to know what kind of patching you have in mind. I don’t really see any logical way to patch guest VMs from a BigFix client running on the service console, and patching the hypervisor or service console of an ESX server seems like the sort of thing you’d have informational fixlets about at most (like you do with many service packs, like Exchange) given that a VMware operating environment can potentially host dozens of VMs.
Conrad Golightly
(imported comment written by SystemAdmin)
Mr. Golightly 
I’m still learning about the ESX system so thank you for clarifying this and please correct me if I’m saying something off base or with the wrong terms.
-
We don’t intend to run a client on the hypervisor, it would be run through the service console (RedHat 3).
-
You won’t be patching or reporting on the Virtual Machines themselves through the client on the service console (but you would still do this by putting a client on each of the Virtual Machines and managing them like real computers). The goal of the ESX agent will be to report and patch the service console itself and use the ESX agent to report on and patch the hypervisor. So, you wouldn’t load a client on the hypervisor directly but you would use the client on the service console as a reporting/patching service for the hypervisor.
There are specific details about how this will work that I don’t think I can get into but we do intend to have special relevance/action commands for the ESX agent to manage the ESX environment. So, you can run the existing redhat 3 agent on the management console already but the upcoming ESX agent will have additional ESX specific functionality in it.
(imported comment written by mynameisbear91)
Tyler Duni
- You won’t be patching or reporting on the Virtual Machines themselves through the client on the service console (but you would still do this by putting a client on each of the Virtual Machines and managing them like real computers). The goal of the ESX agent will be to report and patch the service console itself and use the ESX agent to report on and patch the hypervisor. So, you wouldn’t load a client on the hypervisor directly but you would use the client on the service console as a reporting/patching service for the hypervisor.
Rock on. I’d almost certainly be a customer.
(imported comment written by BenKus)
Hopefully you all saw that we added VMWare ESX support (based on the RHEL 3.0 agent).
Ben
(imported comment written by mynameisbear91)
Ben Kus
Hopefully you all saw that we added VMWare ESX support (based on the RHEL 3.0 agent).
Ben
Oooooooooooooo.
(imported comment written by Shawn_Jefferson)
No, I didn’t see this… How does it work? Are there some install guides around that I can look at? I have a somewhat small ESX installation, but growing all the time… I’d like to manage it via Bigfix as well.
(imported comment written by BenKus)
Hi Shawn,
You can find the VMWare ESX Agent here: http://support.bigfix.com/install/besclients-nonwindows.html#vmware
It works just like any other BigFix Agent (in fact, we adapted the RHEL3 agent to work with VMWare ESX) and so all documentation you can find relating to RHEL3 BigFix Agents should apply to VMWare ESX agents.
Ben
(imported comment written by Shawn_Jefferson)
What about ESX version 3.5 ? We are about to upgrade away from 3.0.x
(imported comment written by Shawn_Jefferson)
Is it compatible with ESX v3.5 ? I don’t want to use it if is untested…
Thanks,
Shawn
(imported comment written by BenKus)
Hi Shawn,
I don’t believe we have ever tried it with ESX 3.5.
Ben
(imported comment written by Shawn_Jefferson)
Ok, thanks. I’ll wait until you’ve tested it and verified it works properly then. Too bad.
Shawn
(imported comment written by BenKus)
Hey guys,
Note that with BigFix 7.1, ESX 3.5 is a supported platform:
http://support.bigfix.com/bes/misc/supportpolicy.html
Ben
(imported comment written by jeko1791)
Hi Ben.
Do you know when Bigfix will support ESX 3.5 patches in their Patches for ESX site? We’re moving to 3.5 but are losing our ability to patch ESX with Bigfix once we do.
(imported comment written by BenKus)
Hey Jeko,
We have plans to support ESX 3.5 patching content, but I don’t have a timeframe for you unfortunately.
Ben
(imported comment written by jocelyn91)
Hi everyone,
One issue I encountered when installing the agent on ESX, is that there is a software firewall running. Without opening the required ports the client will not report to the BES. I was surprised to not find this mentioned anywhere in the documentation.
Here is what you have to run to let the agent communicate with the server and receive refresh triggers from it (adjust if you are not using the default ports):
esxcfg-firewall -o 52311,tcp,out,bigfix
esxcfg-firewall -o 52311,udp,in,bigfix
You can undo the changes with:
esxcfg-firewall -c 52311,tcp,out
esxcfg-firewall -c 52311,udp,in
Finally you can see the rules using esx-firewall –q, make sure you have the following:
Opened ports:
bigfix : port 52311 tcp.out udp.in
Unless I missed something in the doco.
Jocelyn