Re: vmprofile and vmtype tables in vcl.sql

[Aaron Peeler]

--On April 9, 2009 1:48:40 PM -0400 Brian Bouterse  
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


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

Re: vmprofile and vmtype tables in vcl.sql

[Brian Bouterse]

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.


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?


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.


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

Re: vmprofile and vmtype tables in vcl.sql

[Aaron Peeler]

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

Re: vmprofile and vmtype tables in vcl.sql

[Aaron Peeler]

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

Re: vmprofile and vmtype tables in vcl.sql

[Brian Bouterse]

Yes, one of the two vmwareGSX and vmwarefreeserver entries in the  
vmtype table should be removed because they are redundant.


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?


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 larger issue.  As a fix, how about if we set the vmprofile.imageid  
to 4 (No Image) because of this?  What do you think?


Best,
Brian


Brian Bouterse
Secure Open Systems Initiative
919.698.8796




On Apr 8, 2009, at 11:46 AM, Josh Thompson wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian's commit to the vcl.sql file highlighted an issue to me.  The  
vmprofile
table includes an imageid field.  Even though we don't ship any  
images, we do
ship entries in the image table to serve as examples.  In our  
documentation,

we need to have one of two things:

1) tell users how to create the images that correspond with the  
entries we

ship in the image table

or

2) tell users that after they've created their own VM host server  
images and
added them to the image table, they need to update the vmprofile  
through the

web interface to assign the correct image to the profile

The vmtype table has both vmwareGSX and vmwarefreeserver, which are  
the same

thing.  Can we remove one of them?


Brian:  For the "VMware ESX SAN" vmprofile entry you added, you have  
vmtypeid
set to 5 which is vmwareESX3.  Should that have been 6 which is  
vmwareESXi
instead?  (and maybe vmwareESXi should be vmware ESX3i?).  Also, you  
have
imageid set to 9 which is "VMware ESX 3.5 standard server".  There  
is no
entry in the image table for an ESX 3i server, but given the above  
issue,
there's really no image that would correspond to an entry for it in  
the image

table anyway; so, it doesn't really matter that much.

Josh
- --
- ---
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University

josh_thomp...@ncsu.edu
919-515-5323

my GPG/PGP key can be found at pgp.mit.edu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ3MbLV/LQcNdtPQMRAusZAJoDyLJx68lrr0L5d7C7CoITH3jYoQCfYKKV
kzNCRfCzSwHSMfIrMrxt0JU=
=uVO6
-END PGP SIGNATURE-

vmprofile and vmtype tables in vcl.sql

[Josh Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian's commit to the vcl.sql file highlighted an issue to me.  The vmprofile 
table includes an imageid field.  Even though we don't ship any images, we do 
ship entries in the image table to serve as examples.  In our documentation, 
we need to have one of two things:

1) tell users how to create the images that correspond with the entries we 
ship in the image table

or

2) tell users that after they've created their own VM host server images and 
added them to the image table, they need to update the vmprofile through the 
web interface to assign the correct image to the profile

The vmtype table has both vmwareGSX and vmwarefreeserver, which are the same 
thing.  Can we remove one of them?


Brian:  For the "VMware ESX SAN" vmprofile entry you added, you have vmtypeid 
set to 5 which is vmwareESX3.  Should that have been 6 which is vmwareESXi 
instead?  (and maybe vmwareESXi should be vmware ESX3i?).  Also, you have 
imageid set to 9 which is "VMware ESX 3.5 standard server".  There is no 
entry in the image table for an ESX 3i server, but given the above issue, 
there's really no image that would correspond to an entry for it in the image 
table anyway; so, it doesn't really matter that much.

Josh
- -- 
- ---
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University

josh_thomp...@ncsu.edu
919-515-5323

my GPG/PGP key can be found at pgp.mit.edu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ3MbLV/LQcNdtPQMRAusZAJoDyLJx68lrr0L5d7C7CoITH3jYoQCfYKKV
kzNCRfCzSwHSMfIrMrxt0JU=
=uVO6
-END PGP SIGNATURE-