I don't think I've seen the vmwareGSX name used in a while at the vmware
sites, so we could just drop that entry.
Just need to double check the code first to see if it matters.
Speaking of redundancy in the vmtype table vcl.sql file, I'm confused
about why there are independent entries for ESX and ESX 3i. The esx.pm
provisioning module uses the VMware API
(http://www.vmware.com/support/pubs/sdk_pubs.html) which is designed by
VMware to be identical with ESX and ESX 3i. This way, folks like us
don't have to implement custom code for one ESX vs ESX 3i. Because of
this, does it even matter which vmprofile.vmtypeid was added to the
vcl.sql file? What do you think?
The reason is to separate ESX standard server and ESXi. So maybe ESX3 gets
renamed to ESX standard Server.
The vmware.pm module supports both vmware Free Server and ESX Standard
Server using the 'vmware-cmd' cmd via ssh on the host server.
ESX3i is only cmdline managed by the vmware-tools api - right?
Ultimately I'm not sure how much the vmtype table will matter in the
long-run. Since the computer.privisioingid, this
Given that VCL can't deploy ESX 3i (the free version), I propose VCL
shouldn't mess with the 3i hypervisors until this can be revisited as a
Can ESX3i be installed via kiskstart? If so then it can be installed using
the xcat provisioning module, as long as the hardware is supported and one
has xCAT setup on their management node.
Aaron
