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 <[email protected]>
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 <[email protected]>
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 <
[email protected]> 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"
<[email protected]>
To: "vcl-dev" <[email protected]>
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
