I sort of disagree, but can understand your view point. My viewpoint is from user complaints and tracing through logs as to why their image didn't load.

So it was easier to sanity check the image creator(the user) input values instead of pointing out to users, why their image broke.

Maybe the web front end for the image profile does not except '0' or allow below a certain value? I think some level of sanity checking is needed somewhere.


--On April 9, 2009 3:25:14 PM -0400 Andrew Brown <brow...@gmail.com> wrote:

I agree. Ideally, I like to keep systems as generalized as possible, and
that means not doing anything unnecessary and not making any unnecessary
assumptions. One such assumption being that there is some kind of minimum
ram amount for images that VCL supports.

A ram size of 0 is obviously an error, so I wouldn't be against a check
for 0 values and failing in that case... but the system already does just
that, it's just vmware that does the check, not VCL.


On Thu, Apr 9, 2009 at 3:17 PM, Brian Bouterse <bmbou...@ncsu.edu> wrote:

If an installation's configuration (in this case the RAM metadata for an
image) isn't properly setup, should the provisioning system compensate
for that?  I submit to the community that a provisioning engine should
take the values handed to it, provision them, and that is all.  If the
values handed to the provisioning engine don't make sense (like a ram
size of 0) then the provisioning engine should cause an error.  What do
you think?


Brian Bouterse
Secure Open Systems Initiative

On Apr 9, 2009, at 1:01 PM, Aaron Peeler wrote:

 Also that might be an improvement for the esx.pm to set the default to
512MB if it's less than 512. Created JIRA issue VCL-130 <

here's the snippet from the vmware.pm module. It's not perfect(doesn't
account for assigning too much ram) but it might help:

# check for memory settings
my $dynamicmemvalue = "512";
if (defined($vmclient_imageminram)) {
       # preform some sanity check
       if (($dynamicmemvalue < $vmclient_imageminram) &&
($vmclient_imageminram < $vmhost_RAM)) {
               $dynamicmemvalue = $vmclient_imageminram;
               notify($ERRORS{'OK'}, 0, "setting memory to
       else {
               notify($ERRORS{'WARNING'}, 0, "image memory value
$vmclient_imageminram out of the expected range in host machine
$vmhost_RAM setting to 512");

--On April 9, 2009 12:41:33 PM -0400 Wayne Schildhauer <
wschi...@linux.vnet.ibm.com> wrote:

 I found it.  The image data in the database had 0 instead of 512.  It
seems like we looked at everything but the most obvious....

Wayne F. Schildhauer
IBM Corporation
Research Triangle Park, NC

----- Original Message ----- From: "Wayne Schildhauer"
To: "vcl-dev" <vcl-dev@incubator.apache.org>
Sent: Wednesday, 08 April, 2009 18:22
Subject: xp image power on fail

 I am sorry for the naive question to come, but we figured out why our
Windows XPs VMs are not powering on.  In the deployed vmx file on
ESXi, esx3-windowsxp-v0.vmx, memsize = 0:

 config.version = "8"
 virtualHW.version = "4"
 memsize = "0"
 displayName = "windowsxp-bl1"
 guestOS = "other"

 <deleted remaining>

This causes VMware ESXi to panic the VM with an ASSERT failure.

Our master configuration file shows it being 512 MB (memsize = "512"),
and  the slots appear to be configured for 512 MB as well.  I suspect
that  memsize is not getting initialized, rather than overwritten,
but I cannot  trace where the object that is being given to esx.pm is
originally  generated.  Perhaps in the reservation?


Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU

Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU

Reply via email to