--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
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. Consid
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
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
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
-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
