--On April 9, 2009 1:48:40 PM -0400 Brian Bouterse <bmbou...@ncsu.edu>
wrote:
Since ESX and ESX 3i both use the VMware API, VCL can name them different
things in the vmtype table, and try to treat them differently, but it's a
useless distinction. Since the API's are the same, the integration
effort should not be duplicating work by treating them differently.
Consider ESX 4.0; creating a distinction between ESX 4i and ESX 4 is
similarly useless since the management API (and therefore the integration
work) is the same for both of them.
Agreed.
A useful distinction would be between ESX 3.5 and ESX 4 since the API
does change between those versions. Does this make sense to folks?
makes sense
To answer the question asked about ESX3i kickstart installs, ESX3i cannot
be installed via kickstart. The only reason ESX3 could be kickstarted is
because the service console was RHEL based. ESX3i contains no RHEL, and
therefore no kickstart opportunity.
Hrmm, that makes it tough not being able to automate or dynamically install
ESXi on the bare metal, especially at scale for a large number of blades.
There are hints that a vmware kb article 'VMware ESX and ESXi Comparison'
page
<http://kb.vmware.com/selfservice/viewContent.do?externalId=1006543&sliceId=1>
under 'Scriptable installation'
so maybe some day.
Best,
Brian
Brian Bouterse
Secure Open Systems Initiative
919.698.8796
On Apr 8, 2009, at 3:24 PM, Aaron Peeler wrote:
doh - hit send too soon...
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 is being set to which
provisioning module to use.
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
Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu
