I've updated the VCL-130 JIRA ticket with the following: The solution to be implemented in the esx.pm module is a check to see if a virtual machine's RAM = 0. If it is then return a friendly, but critical error message. This should solve the user confusion problem, and the provisioning engine doesn't try to compensate for misconfiguration in other areas of the system.

Best,
Brian


Brian Bouterse
Secure Open Systems Initiative
919.698.8796




On Apr 9, 2009, at 3:52 PM, Aaron Peeler wrote:

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.

-A

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

-Andrew

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?

Best,
Brian

Brian Bouterse
Secure Open Systems Initiative
919.698.8796





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 <
https://issues.apache.org/jira/browse/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
$dynamicmemvalue");
      }
      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"
<wschi...@linux.vnet.ibm.com>
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:

!/usr/bin/vmware
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?

Thanks....Wayne





Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu






Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu

Reply via email to