Re: Benchmarking Software's on VCL
Hi Amit, There will definitely be delays in screen refresh rates as a result of the RDP connection, so if, for example, you're dragging a map or other objects you may notice some lag. You might try adjusting Windows visual settings for best performance from the System control panel. There are also performance settings on the RDP client itself. Try opening Remote Desktop Connection and manually entering the connection information -- depending upon your platform, the RDP client settings for performance will be in a different tab. GIS software can also be doing a lot of number crunching. (Confirm the specs in Windows System control panel on the client VM if you haven't already to make sure the proper resources are assigned by VCL.) Have you run any other applications in the VM/VCL environment that experience similar issues? Regards, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Mon, Apr 16, 2012 at 09:40, Kumar, Amit H. ahku...@odu.edu wrote: Dear All, I have run into issues of software(GIS) being slower on VCL as opposed to Laptop. Although I have 8GB RAM and 2 vCPU assigned for this VM, comparison of few tests resulted in poor performance on VCL. It could be the nature of GIS and RDP or something else. I have tried to isolate GIS vm's onto one blade and no other vm's end up on this blade. Any ideas or options on how could I track this down to identify what could cause this. Thank you, Amit
Support for desktop Linux
Afternoon, dev team -- I'm curious if there is any effort already underway to support full (GUI) Linux desktops? I'd like to be able to provide a completely open-source experience to a relatively non-technical end-user. A couple folks on the vcl-user list have used both SSH with X-11 packet forwarding and RDP, but I was wondering what thoughts you might have on how to approach developing the support. I thought it might be relatively easy to add a variant of the download this RDP file approach for Linux desktops, if an RDP server was already installed on the image. Thanks regards, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com
Re: Adding a delay to the Connect button
Thanks, Josh! On Wed, Mar 14, 2012 at 08:52, Josh Thompson josh_thomp...@ncsu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike, Yes, if you look at the JIRA issue[1], you'll see some code contributed by Gerhard Hartl that will work with 2.2.1. Josh [1] https://issues.apache.org/jira/browse/VCL-444 On Wednesday, March 14, 2012 7:55:30 AM Mike Haudenschild wrote: Afternoon, dev team -- I noticed a jira item roll past my Inbox a week or so back regarding adding a delay in the code between when the user clicks the Connect! button and when the RDP file is actually available. I'm experiencing the issue that the ticket addressed -- if a user is really on it, the RDP connection can be starting before the target computer is actually ready to receive it. I'm still running the 2.2.1 release. Is the fix for this easy enough that I could just adjust a few lines in the existing code? Thanks as always, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com - -- - --- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk9glKwACgkQV/LQcNdtPQObqgCfdlAIcriASUUOYl5OfvfVC1lJ MG8An25XKYxJZI6XUh6x4YUpsKx7EmV1 =390w -END PGP SIGNATURE-
Re: Dev feedback requested, management commands sent to Cygwin
Hi Andy, Thanks for these suggestions. When I connect to the target using the -vvv option, it stalls in two places: when using /etc/vcl/vcl.key, and immediately before showing the shell prompt. I'm currently running the 2.2.1 release of the management node code. I'm assuming that the changes you noted would be made starting with the code from trunk? If so, are there any problems running the management node code from trunk with stock 2.2.1 front-end code? Thanks for your help! Mike On Thu, Mar 1, 2012 at 08:51, Andy Kurth andy_ku...@ncsu.edu wrote: I have seen similar slowness. Even on a pretty powerful workstation, a Cygwin shell can take a few seconds to open. If SSH is taking significantly longer than running Cygwin locally, you can run 'ssh -vvv' to try to figure out which stage in the SSH connection sequence is taking the most time. You may be able to tweak the sshd_config settings on the target. Make sure UseDNS is set to no. Yes, vcld currently establishes a new connection for every SSH call. Things should be quicker with VCL 2.3. I added code to establish a single SSH connection and then pass commands to it using Net::SSH::Expect. This code is in the OS.pm::execute_new() subroutine. The code in the repository is not currently configured to call this but you can test it by uncommenting the following lines: In OS.pm::execute(). #return execute_new(@_); In utils.pm::run_ssh_command: #return VCL::Module::OS::execute($node, $command, $output_level, $timeout_seconds, $max_attempts, $port, $user); Also, you'll need to run install_perl_libs.pl or manually install Net::SSH::Expect. -Andy On Wed, Feb 29, 2012 at 5:59 PM, James O'Dell jod...@fullerton.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Afaik the vcld process normally starts a new connection each time it wants to do something on the client. It may batch a few commands during a single session - like when it creates a user. But for most part it creates a new connection each time. On 2/29/2012 2:34 PM, Mike Haudenschild wrote: Hi Jim, I'm working from a new image, so (unfortunately?) Cygwin is already the latest version. I've disabled many of the default items in /etc/profile to try and speed up initial connections. Do you happen to know if the management node opens/closes the SSH connection for each command it issues, or uses the same SSH session for multiple commands? Many thanks, Mike On Wed, Feb 29, 2012 at 14:42, James O'Dell jod...@fullerton.edu wrote: Hey Mike, I had a similar issue with Cygwin. Basically, I installed Cygwin when I created the image. Over the course of time I patched the OS, but not Cygwin. This caused problems. I eventually removed Cygwin, and reinstalled it (had to re-run the Cygwin patch up stuff again). (Pay close attention to who you are actually 'logged in as' when installing Cygwin. I think I needed to be 'root') Anyway, a reinstall of Cygwin helped me out. Hope this helps, __Jim On 2/29/2012 10:41 AM, Mike Haudenschild wrote: Good afternoon, devs -- I've been experiencing slower than expected reservation provisioning times on a VCL infrastructure that uses a SAN for all storage (all ESXi, on blades). I first noticed it when I'd click the Connect! button on a reservation and the RDP connection wouldn't open the first time. Restarting the RDP client 15-30 seconds later, the connection would succeed. Watching vcld.log, I found that connecting to the Cygwin shell from the management node was taking 6-10 seconds (whereas the same connections on servers using local-disk storage take 1-2 seconds). I can replicate the behavior running ssh -i /etc/vcl/vcl.key target machine from the management node. It really hit home when I started a bash shell LOCALLY (with bash --login -i -x) on a target Windows VM and watched how long it took just to get to a bash prompt. Each of the startup scripts took a long time. (I'm not running bash-completion, a common complaint about slow Cygwin shell startups.) I *think* -- requesting confirmation of this -- that each time the management node wants to issue a command to a remote computer it initiates a new SSH connection, then closes that connection when the command finishes processing. Is that accurate? If so, that would mean that those 6-10 seconds would be compounded several times over while the management node prepares the remote computer for my reservation. I'm currently investigating moving Cygwin into a RAMdisk on the VM images, but that only makes sense if the above assumption about multiple SSH sessions is accurate. The latency on the SAN connection is very low, and ESXi reports that latencies on the virtural disks are slow. I have /etc/hosts set up, DNS resolves fine, and pings between the management node and VMs are fine. Has anyone
Dev feedback requested, management commands sent to Cygwin
Good afternoon, devs -- I've been experiencing slower than expected reservation provisioning times on a VCL infrastructure that uses a SAN for all storage (all ESXi, on blades). I first noticed it when I'd click the Connect! button on a reservation and the RDP connection wouldn't open the first time. Restarting the RDP client 15-30 seconds later, the connection would succeed. Watching vcld.log, I found that connecting to the Cygwin shell from the management node was taking 6-10 seconds (whereas the same connections on servers using local-disk storage take 1-2 seconds). I can replicate the behavior running ssh -i /etc/vcl/vcl.key target machine from the management node. It really hit home when I started a bash shell LOCALLY (with bash --login -i -x) on a target Windows VM and watched how long it took just to get to a bash prompt. Each of the startup scripts took a long time. (I'm not running bash-completion, a common complaint about slow Cygwin shell startups.) I *think* -- requesting confirmation of this -- that each time the management node wants to issue a command to a remote computer it initiates a new SSH connection, then closes that connection when the command finishes processing. Is that accurate? If so, that would mean that those 6-10 seconds would be compounded several times over while the management node prepares the remote computer for my reservation. I'm currently investigating moving Cygwin into a RAMdisk on the VM images, but that only makes sense if the above assumption about multiple SSH sessions is accurate. The latency on the SAN connection is very low, and ESXi reports that latencies on the virtural disks are slow. I have /etc/hosts set up, DNS resolves fine, and pings between the management node and VMs are fine. Has anyone else run into any similar behavior with Cygwin? Many thanks, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com
Re: Dev feedback requested, management commands sent to Cygwin
Hi Jim, I'm working from a new image, so (unfortunately?) Cygwin is already the latest version. I've disabled many of the default items in /etc/profile to try and speed up initial connections. Do you happen to know if the management node opens/closes the SSH connection for each command it issues, or uses the same SSH session for multiple commands? Many thanks, Mike On Wed, Feb 29, 2012 at 14:42, James O'Dell jod...@fullerton.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Mike, I had a similar issue with Cygwin. Basically, I installed Cygwin when I created the image. Over the course of time I patched the OS, but not Cygwin. This caused problems. I eventually removed Cygwin, and reinstalled it (had to re-run the Cygwin patch up stuff again). (Pay close attention to who you are actually 'logged in as' when installing Cygwin. I think I needed to be 'root') Anyway, a reinstall of Cygwin helped me out. Hope this helps, __Jim On 2/29/2012 10:41 AM, Mike Haudenschild wrote: Good afternoon, devs -- I've been experiencing slower than expected reservation provisioning times on a VCL infrastructure that uses a SAN for all storage (all ESXi, on blades). I first noticed it when I'd click the Connect! button on a reservation and the RDP connection wouldn't open the first time. Restarting the RDP client 15-30 seconds later, the connection would succeed. Watching vcld.log, I found that connecting to the Cygwin shell from the management node was taking 6-10 seconds (whereas the same connections on servers using local-disk storage take 1-2 seconds). I can replicate the behavior running ssh -i /etc/vcl/vcl.key target machine from the management node. It really hit home when I started a bash shell LOCALLY (with bash --login -i -x) on a target Windows VM and watched how long it took just to get to a bash prompt. Each of the startup scripts took a long time. (I'm not running bash-completion, a common complaint about slow Cygwin shell startups.) I *think* -- requesting confirmation of this -- that each time the management node wants to issue a command to a remote computer it initiates a new SSH connection, then closes that connection when the command finishes processing. Is that accurate? If so, that would mean that those 6-10 seconds would be compounded several times over while the management node prepares the remote computer for my reservation. I'm currently investigating moving Cygwin into a RAMdisk on the VM images, but that only makes sense if the above assumption about multiple SSH sessions is accurate. The latency on the SAN connection is very low, and ESXi reports that latencies on the virtural disks are slow. I have /etc/hosts set up, DNS resolves fine, and pings between the management node and VMs are fine. Has anyone else run into any similar behavior with Cygwin? Many thanks, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com - -- Jim O'Dell Network Analyst California State University Fullerton Email: jod...@fullerton.edu Phone: (657) 278-2256 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Of5IACgkQREVHAOnXPYQu1QCfTcjbu1cat6jOpNRGGPGwlPsz TYkAn0smAWtrocgCiw2RssbShsm4b2gP =/8Pd -END PGP SIGNATURE-
Network adapters
Good morning, dev team -- I've been troubleshooting slow SSH connection times (lots of lag between the management node and VMs running Cygwin, slow provisioning). I found that my XP 32-bit VMs were using the VMWare default network adapter. I'd specified the E1000 when creating the original image per the docs, but of course VCL only brings over the VMDK and the generic VMWare adapter is assigned when the VM boots via VCL. Waiting for XP to find new hardware is definitely contributing to my slow startup times, but since I'll eventually have a variety of 32- and 64-bit Windows and Linux guest OSs in VCL I thought I would ask which network adapters should be assigned to which operating systems. I read a passing mention in the listserv archive that VCL assigned different adapters to different architectures [1]. Thanks, Mike [1] http://markmail.org/message/ae4eb6fk2x7rg3rh?q=set:arkurth/vcl+vmware+e1000 -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com
Re: Possible Database Problem
Hi, Aaron -- Are you able to SSH to the VM host using key authentication? ssh -i /etc/vcl/vcl.key VM host Also, check to be sure that 6vsphere resolves to its IP from the management node (in /etc/hosts). Regards, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Wed, Feb 22, 2012 at 12:42, Aaron Bryant amb...@pitt.edu wrote: Greetings, I am new to VCL and having a problem configuring a Fedora 15 machine running Apache VCL 2.2.1. This VCL project is being tested as a pilot project for the University I work for. My testing environment is a Dell PowerEdge running Fedora 15 and a Dell PowerEdge R710 running VMware ESXI 4.1.0. I have created a Windows 7 32 bit virtual machine using an ESXI client machine. I completed installing Cygwin SSHD and I'm attempting to run the vcld -setup command. My problem occurs in this step while creating a base image. I am able to get through all of the prompts and start the creation before the script crashes with no image creation occurring. I have checked the '/var/log/vcld.log' log file and this is a portion of the output: 16:25:34|2772|4:4|image|OS.pm:is_ssh_responding(386)|6vsphere is NOT responding to SSH, ports 22 or 24 are both closed 2012-01-24 16:25:34|2772|4:4|image|VMware.pm:initialize(257)|unable to control OS of VM host 6vsphere using VCL::Module::OS::Windows::Version_6::7 OS object because VM host is not responding to SSH I have checked and am able to ssh between the management node and the virtual machines. I am thinking that my problem may be with how the virtual machines are configured in the Database but I can't be sure. Please see the log file attached for more information. Thanks, Aaron Bryant
Re: VCL block alloc, PERL module issue update
Hi Aaron, I hadn't noticed this specifically (was on CentOS 5.7), but I was hunting specifically for RPC-XML issues so I might've missed it. I can run another test install on a clean setup later this week with the updated install_perl_libs.pl. Mike On Fri, Feb 17, 2012 at 09:06, Aaron Peeler aaron_pee...@ncsu.edu wrote: Hi Mike, When you ran the latest install_perl_libs.pl. Did you see any errors in the CPAN section - should be toward the end of the output. That had: cpan tar: Options `-[0-7][lmh]' not supported by *this* tar I'm seeing an error related to config option for cpan that the verbosity level is set wrong on different linux OS versions. It's not consistent, so just checking to see if you had seen this. Thanks, Aaron On Mon, Feb 6, 2012 at 3:53 PM, Mike Haudenschild m...@longsight.com wrote: Hi Andy, I pulled down the updated install_perl_libs.pl and used alongside the 2.2.1 management node release. I did notice that libwww was installed to satisfy dependencies for perl-xml-simple. I didn't do any other tweaking -- just ran the script and otherwise followed the normal management node install procedure. A block allocation didn't work, however: |3394|blockrequest| CRITICAL |3394|blockrequest| 2012-02-06 15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object method type via package RPC::XML::Client::send_request: HTTP server error: you need (perhaps you forgot to load RPC::XML::Client::send_request: HTTP server error: you need?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. |3394|blockrequest| ( 0) vcld, die_handler (line: 636) |3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) |3394|blockrequest| (-3) blockrequest.pm, process (line: 193) |3394|blockrequest| (-4) vcld, make_new_child (line: 568) |3394|blockrequest| (-5) vcld, main (line: 448) On Mon, Feb 6, 2012 at 12:23, Andy Kurth andy_ku...@ncsu.edu wrote: I updated install_perl_libs.pl in the repository: https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl You should now be able to run it without having to perform any additional steps. Please give it a try. Thanks, Andy On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild m...@longsight.com wrote: All, I've managed to get around the CRITICAL error I was seeing in the vcld log during block allocations. perl-libwww-perl wasn't installed. *sigh* Installing that prior to running install_perl_libs.pl solved the problem (should that be added to the install_perl_libs script?). I noticed that there are two listings of PERL-related software required for the management node: https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation and https://cwiki.apache.org/confluence/display/VCL/Apache+VCL We might want to consolidate those. I was running from the install docs and didn't even think to check that perl-libwww-perl was installed. Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71 (which is NOT the most recent version) using the make method from the CPAN archive. Note that I'm on CentOS 5.7, clean install and fully updated prior to install VCL management node. There is no package perl-XML-RPC (called from the script) available from the repos (with EPEL enabled), and perl-libwww-perl wasn't installed by default. Here's the process I used... 1. Used the 2.2.1 release install_perl_libs.pl script 2. Commented out the line that tells install_perl_libs.pl to retrieve RPC::XML from CPAN (line 285) 3. Ran install_perl_libs.pl 4. Installed RPC-XML 0.71 from CPAN 5. Completed VCL management node install steps from the documentation I went with the lowest-versions of the various dependencies needed by RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate any feedback from the list on whether that may have unintended consequences... Here's the dependency tree with links: - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/) - libwww-perl (LWP) 5.801 ( https://metacpan.org/release/GAAS/libwww-perl-5.801) - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note that some tests FAILED - HTML-Parser 3.33 ( https://metacpan.org/release/GAAS/HTML-Parser-3.33) - HTML-Tagest 3.02 ( https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/) - XML-Parser 2.31 ( https://metacpan.org/release/COOPERCL/XML-Parser-2.31) Having the most recent perl-libwww-perl from CPAN yielded an install that didn't include LWP::Protocol::https (and the script is trying to make an HTTPS connection). Installing LWP
Re: VCL block alloc, PERL module issue update
Hi Andy,
I pulled down the updated install_perl_libs.pl and used alongside the 2.2.1
management node release. I did notice that libwww was installed to satisfy
dependencies for perl-xml-simple. I didn't do any other tweaking -- just
ran the script and otherwise followed the normal management node install
procedure.
A block allocation didn't work, however:
|3394|blockrequest| CRITICAL
|3394|blockrequest| 2012-02-06
15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object method
type via package RPC::XML::Client::send_request: HTTP server error: you
need (perhaps you forgot to load RPC::XML::Client::send_request: HTTP
server error: you need?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line
9121.
|3394|blockrequest| ( 0) vcld, die_handler (line: 636)
|3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121)
|3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373)
|3394|blockrequest| (-3) blockrequest.pm, process (line: 193)
|3394|blockrequest| (-4) vcld, make_new_child (line: 568)
|3394|blockrequest| (-5) vcld, main (line: 448)
On Mon, Feb 6, 2012 at 12:23, Andy Kurth andy_ku...@ncsu.edu wrote:
I updated install_perl_libs.pl in the repository:
https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl
You should now be able to run it without having to perform any
additional steps. Please give it a try.
Thanks,
Andy
On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild m...@longsight.com
wrote:
All,
I've managed to get around the CRITICAL error I was seeing in the vcld
log
during block allocations. perl-libwww-perl wasn't installed. *sigh*
Installing that prior to running install_perl_libs.pl solved the
problem
(should that be added to the install_perl_libs script?). I noticed that
there are two listings of PERL-related software required for the
management
node:
https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation
and
https://cwiki.apache.org/confluence/display/VCL/Apache+VCL
We might want to consolidate those. I was running from the install docs
and didn't even think to check that perl-libwww-perl was installed.
Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71
(which is NOT the most recent version) using the make method from the
CPAN
archive.
Note that I'm on CentOS 5.7, clean install and fully updated prior to
install VCL management node. There is no package perl-XML-RPC (called
from
the script) available from the repos (with EPEL enabled),
and perl-libwww-perl wasn't installed by default.
Here's the process I used...
1. Used the 2.2.1 release install_perl_libs.pl script
2. Commented out the line that tells install_perl_libs.pl to retrieve
RPC::XML from CPAN (line 285)
3. Ran install_perl_libs.pl
4. Installed RPC-XML 0.71 from CPAN
5. Completed VCL management node install steps from the documentation
I went with the lowest-versions of the various dependencies needed by
RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate
any
feedback from the list on whether that may have unintended
consequences...
Here's the dependency tree with links:
- RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/)
- libwww-perl (LWP) 5.801 (
https://metacpan.org/release/GAAS/libwww-perl-5.801)
- URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note
that some tests FAILED
- HTML-Parser 3.33 (
https://metacpan.org/release/GAAS/HTML-Parser-3.33)
- HTML-Tagest 3.02 (
https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/)
- XML-Parser 2.31 (
https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
Having the most recent perl-libwww-perl from CPAN yielded an install that
didn't include LWP::Protocol::https (and the script is trying to make an
HTTPS connection). Installing LWP-Protocol-https doesn't solve the
problem
because of stricter SSL certification requirements and hostname
verification (
http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
).
Many thanks,
Mike
On Wed, Feb 1, 2012 at 11:44, Andy Kurth andy_ku...@ncsu.edu wrote:
You shouldn't have to install anything manually. It looks like there
are some problems with the current install_perl_libs.pl script. There
is a CPAN notest option which I added to make the script run a lot
faster. Apparently this option isn't always available. Try editing
install_perl_libs.pl and then run it again. Swap the comment from the
install line to the notest line, change:
eval { CPAN::Shell-notest(install, $perl_module) };
#eval { CPAN::Shell-install($perl_module) };
-to-
#eval { CPAN::Shell-notest(install, $perl_module) };
eval { CPAN::Shell-install($perl_module) };
Also, was epel successfully installed? Run 'yum
Numerous AJAX errors
Good evening, dev team -- I started seeing AJAX errors accessing VCL pages out of the blue today. I changed the domain serving VCL and added the appropriate SSL certs, but when this problem occurred I rolled those changes back. Even after rolling back the changes (I'm back to my original domain and SSL config) I'm still getting numerous AJAX errors: - entering the new reservation page - when the current reservations page attempts to auto-refresh when a request is pending AJAX Error: syntax error Line 42 in https://urvcl.richmond.edu/js/requests.js AJAX Error: syntax error Line 14 in https://urvcl.richmond.edu/dojo/dojo/dojo.js - attempting to delete a block allocation AJAX Error: syntax error Line 58 in https://urvcl.richmond.edu/js/blockallocations.js - creating a new block allocation Any guidance would be appreciated. Thanks! Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com
Re: Numerous AJAX errors
Solved it -- rebuilt my conf.php from the default. I must have edited it without the -w option on nano or something, and corrupted it... On Mon, Feb 6, 2012 at 17:12, Mike Haudenschild m...@longsight.com wrote: Good evening, dev team -- I started seeing AJAX errors accessing VCL pages out of the blue today. I changed the domain serving VCL and added the appropriate SSL certs, but when this problem occurred I rolled those changes back. Even after rolling back the changes (I'm back to my original domain and SSL config) I'm still getting numerous AJAX errors: - entering the new reservation page - when the current reservations page attempts to auto-refresh when a request is pending AJAX Error: syntax error Line 42 in https://urvcl.richmond.edu/js/requests.js AJAX Error: syntax error Line 14 in https://urvcl.richmond.edu/dojo/dojo/dojo.js - attempting to delete a block allocation AJAX Error: syntax error Line 58 in https://urvcl.richmond.edu/js/blockallocations.js - creating a new block allocation Any guidance would be appreciated. Thanks! Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com
Re: [Discuss] Graduation ? next steps
Hi Aaron, No problem, I'm looking forward to this work! I submitted my contributor agreement this morning to Apache and asked that they notify you. If you're getting close to a 2.3 release, this will be a great time to start developing and revising docs. We should probably set up a time to talk offline...? Regards, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Thu, Feb 2, 2012 at 10:40, Aaron Peeler aaron_pee...@ncsu.edu wrote: Hi Mike, This is great. Thank you, thank you, thank you So the next steps (I think) are for you to file your ICLA. Then we can discuss how we want the documentation and website to go. Confluence is our current wiki, but that is fading. So we may want to take this time to request a new CMS and start migrating. When we graduate, we'll need to migrate anyway so might as well start thinking about it now. Aaron On Wed, Feb 1, 2012 at 3:56 PM, Mike Haudenschild m...@longsight.com wrote: I'm all about good karma. I owe the VCL guys. Besides, I'm one of the sick ones that actually ENJOY writing documentation. Don't judge me! -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Wed, Feb 1, 2012 at 14:30, Kevan Miller kevan.mil...@gmail.com wrote: On Feb 1, 2012, at 9:36 AM, Mike Haudenschild wrote: Hi, Aaron et al. -- I'm heavily invested in VCL for two large production projects. I'm not a developer, but I have extensive experience writing documentation and would be happy to help in that regard. Most of my recent technical writing is proprietary, but a couple years ago I wrote a Moodle install doc that you could review here: http://mhauden.com/moodle Cool! Your contributions would be most welcome. I multiple Apache projects with committers who have earned their commit karma via documentation contributions (not code). --kevan -- Aaron Peeler Program Manager Virtual Computing Lab NC State University All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.
Re: [Discuss] Graduation ? next steps
Hi, Aaron et al. -- I'm heavily invested in VCL for two large production projects. I'm not a developer, but I have extensive experience writing documentation and would be happy to help in that regard. Most of my recent technical writing is proprietary, but a couple years ago I wrote a Moodle install doc that you could review here: http://mhauden.com/moodle Regards, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Mon, Jan 30, 2012 at 13:52, Aaron Peeler aaron_pee...@ncsu.edu wrote: Hi Folks, We are getting close to being able to ask for graduation. Based on the checklist: http://incubator.apache.org/guides/graduation.html#checklist We've meet many of the goals: - the community is growing - cut official releases, soon to be another one - good communication on user/dev mailing lists and irc channel. - more diversity in committers, hopefully over next month or so we can bring one or two more. Our current active committers are: Andy kurth - NCSU Josh Thompson - NCSU David Hutchins - Not-NCSU Aaron Coburn - Not-NCSU myself(Aaron Peeler) - NCSU Part of our challenge in not graduating yet has been the diversity among our committers. It is/was heavily weighted with NCSU only committers. In order to move quicker to graduation, it would be great to attract one more committer. Which means being active on the list and submitting code for review. Other areas to be a committer can be with the web site or documentation, in case you are not comfortable with writing code. Mentors, Can you advise on other areas or issues that your think we need to address before we apply for graduation? Best Regards, Aaron -- Aaron Peeler Program Manager Virtual Computing Lab NC State University All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.
Re: VCL block alloc, PERL module issue update
All,
I've managed to get around the CRITICAL error I was seeing in the vcld log
during block allocations. perl-libwww-perl wasn't installed. *sigh*
Installing that prior to running install_perl_libs.pl solved the problem
(should that be added to the install_perl_libs script?). I noticed that
there are two listings of PERL-related software required for the management
node:
https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation
and
https://cwiki.apache.org/confluence/display/VCL/Apache+VCL
We might want to consolidate those. I was running from the install docs
and didn't even think to check that perl-libwww-perl was installed.
Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71
(which is NOT the most recent version) using the make method from the CPAN
archive.
Note that I'm on CentOS 5.7, clean install and fully updated prior to
install VCL management node. There is no package perl-XML-RPC (called from
the script) available from the repos (with EPEL enabled),
and perl-libwww-perl wasn't installed by default.
Here's the process I used...
1. Used the 2.2.1 release install_perl_libs.pl script
2. Commented out the line that tells install_perl_libs.pl to retrieve
RPC::XML from CPAN (line 285)
3. Ran install_perl_libs.pl
4. Installed RPC-XML 0.71 from CPAN
5. Completed VCL management node install steps from the documentation
I went with the lowest-versions of the various dependencies needed by
RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate any
feedback from the list on whether that may have unintended consequences...
Here's the dependency tree with links:
- RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/)
- libwww-perl (LWP) 5.801 (
https://metacpan.org/release/GAAS/libwww-perl-5.801)
- URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note
that some tests FAILED
- HTML-Parser 3.33 (
https://metacpan.org/release/GAAS/HTML-Parser-3.33)
- HTML-Tagest 3.02 (
https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/)
- XML-Parser 2.31 (
https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
Having the most recent perl-libwww-perl from CPAN yielded an install that
didn't include LWP::Protocol::https (and the script is trying to make an
HTTPS connection). Installing LWP-Protocol-https doesn't solve the problem
because of stricter SSL certification requirements and hostname
verification (
http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
).
Many thanks,
Mike
On Wed, Feb 1, 2012 at 11:44, Andy Kurth andy_ku...@ncsu.edu wrote:
You shouldn't have to install anything manually. It looks like there
are some problems with the current install_perl_libs.pl script. There
is a CPAN notest option which I added to make the script run a lot
faster. Apparently this option isn't always available. Try editing
install_perl_libs.pl and then run it again. Swap the comment from the
install line to the notest line, change:
eval { CPAN::Shell-notest(install, $perl_module) };
#eval { CPAN::Shell-install($perl_module) };
-to-
#eval { CPAN::Shell-notest(install, $perl_module) };
eval { CPAN::Shell-install($perl_module) };
Also, was epel successfully installed? Run 'yum repolist'. Do you
see epel listed? If not, check the install_perl_libs.pl output for
errors when it tries to install it.
-Andy
On Tue, Jan 31, 2012 at 6:07 PM, Mike Haudenschild m...@longsight.com
wrote:
Here's the output:
@
XML::LibXML not found
You may ignore the warnings about XML::LibXML not being present,
if
you plan only to use the XML::Parser-based parsing engine. The use
of XML::LibXML is completely optional.
@
WARNING: MIN_PERL_VERSION is not a known parameter.
WARNING: META_MERGE is not a known parameter.
WARNING: LICENSE is not a known parameter.
Warning: prerequisite LWP 5.834 not found. We have 5.805.
Warning: prerequisite Test::More 0.94 not found. We have 0.62.
'LICENSE' is not a known MakeMaker parameter name.
'META_MERGE' is not a known MakeMaker parameter name.
'MIN_PERL_VERSION' is not a known MakeMaker parameter name.
Writing Makefile for RPC::XML
On Tue, Jan 31, 2012 at 17:52, Mike Haudenschild m...@longsight.com
wrote:
Hi Aaron,
You're right, RPC-XML wasn't installed, although perl-libwww-perl is
installed and updated.
Should I install RPC-XML AFTER I run install_perl_libs.pl? (I get
errors
when I run Makefile about various missing prerequisites on a clean
CentOS
install.)
Thanks,
Mike
On Tue, Jan 31, 2012 at 16:49, Aaron Coburn acob...@amherst.edu
wrote:
Oh. It looks like RPC-XML is not installed.
You can verify that by using this command:
perl -MRPC::XML -e print 'have a nice day'
If you get errors, the module isn't installed. If the script seems
Re: [Discuss] Graduation ? next steps
I'm all about good karma. I owe the VCL guys. Besides, I'm one of the sick ones that actually ENJOY writing documentation. Don't judge me! -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Wed, Feb 1, 2012 at 14:30, Kevan Miller kevan.mil...@gmail.com wrote: On Feb 1, 2012, at 9:36 AM, Mike Haudenschild wrote: Hi, Aaron et al. -- I'm heavily invested in VCL for two large production projects. I'm not a developer, but I have extensive experience writing documentation and would be happy to help in that regard. Most of my recent technical writing is proprietary, but a couple years ago I wrote a Moodle install doc that you could review here: http://mhauden.com/moodle Cool! Your contributions would be most welcome. I multiple Apache projects with committers who have earned their commit karma via documentation contributions (not code). --kevan
Re: VCL block alloc, PERL module issue update
Hi Aaron, I really appreciate your response -- starting to sweat bullets on this one. Still seeing the problem. It starts out as: |3425|blockrequest| CRITICAL |3425|blockrequest| 2012-01-31 10:45:07|3425|blockrequest|vcld:die_handler(636)|Can't locate object method type via package RPC::XML::Client::send_request: HTTP server error: Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) (perhaps you forgot to load RPC::XML::Client::send_request: HTTP server error: Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)?) at /usr/local/vcl/bin/../lib/VCL/ utils.pm line 9121. |3425|blockrequest| ( 0) vcld, die_handler (line: 636) |3425|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |3425|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) |3425|blockrequest| (-3) blockrequest.pm, process (line: 193) |3425|blockrequest| (-4) vcld, make_new_child (line: 568) |3425|blockrequest| (-5) vcld, main (line: 448) And if I hand-install LWP::Protocol::https, it becomes: |5745|blockrequest| CRITICAL |5745|blockrequest| 2012-01-31 11:24:30|5745|blockrequest|vcld:die_handler(636)|Can't locate object method type via package RPC::XML::Client::send_request: HTTP server error: Can't connect to urichmond.longsight.com:443 (certificate verify failed) (perhaps you forgot to load RPC::XML::Client::send_request: HTTP server error: Can't connect to urichmond.longsight.com:443 (certificate verify failed)?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. |5745|blockrequest| ( 0) vcld, die_handler (line: 636) |5745|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |5745|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) |5745|blockrequest| (-3) blockrequest.pm, process (line: 193) |5745|blockrequest| (-4) vcld, make_new_child (line: 568) |5745|blockrequest| (-5) vcld, main (line: 448) I have been using the install_perl_libs.pl from the 2.2.1 distro -- I will bring up a clean OS and try this. I've been using CentOS 5.7 -- is 5.x still the most appropriate version? Thanks! Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Tue, Jan 31, 2012 at 14:43, Aaron Peeler aaron_pee...@ncsu.edu wrote: Hi Mike, Apologies for not responding on this. Are you still seeing this issue with your block allocations? If so you could try to use the latest install_perl_libs.pl script https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl Aaron On Wed, Jan 25, 2012 at 6:40 PM, Mike Haudenschild m...@longsight.com wrote: Dev team, I would very much appreciate guidance on whether I should try defining (or bypassing) the SSL cert variables in the PERL scripts, or if I should/can downgrade the applicable PERL modules to older known-working versions to workaround this issue altogether. The log was telling me that LWP::Protocol::https was required, and it's not installed by the install_perl_libs script (because LWP::Protocol::https was recently split out from libwww-perl?). Once installed, however, I get static as shown in the logs below. I'm dead in the water with block allocations. Thanks very much for any help. Regards, Mike On Tue, Jan 24, 2012 at 21:00, Mike Haudenschild m...@longsight.com wrote: Good evening, I apologize for the numerous emails, but as I continue working through this something new popped up: I managed to get LWP::Protocol::https to install by first updating Net::SSLLeay with CPAN. However, when making a block allocation I now get this in the log: |4978|blockrequest| CRITICAL |4978|blockrequest| 2012-01-24 20 :53:45|4978|blockrequest|vcld:die_handler(636)|Can't locate object method type via package RPC::XML::Client::send_request: HTTP server error:* Can't connect to vclserver:443 http://urichmond.longsight.com:443(certificate verify failed) * (perhaps you forgot to load RPC::XML::Client::send_request: HTTP server error: Can't connect to server.domain.com:443 (certificate verify failed)?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. |4978|blockrequest| ( 0) vcld, die_handler (line: 636) |4978|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |4978|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) |4978|blockrequest| (-3) blockrequest.pm, process (line: 193) |4978|blockrequest| (-4) vcld, make_new_child (line: 568) |4978|blockrequest| (-5) vcld, main (line: 448) 2012-01-24 20 :53:45|4978|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest destructor called, address: f7be070 2012-01-24 20:53:45|4978|blockrequest|State.pm:DESTROY(848)|number of database handles state process created: 1 2012-01-24 20:53:45|4138|vcld:REAPER(718)|VCL process exited for reservation unknown, PID: 4978, signal: CHLD My limited understanding of PERL is at play here
Getting reclaim errors, SQL syntax statements in log with block allocations
Hello, VCL dev -- I've seen three instances of relaim errors on my VCL instance today -- machines that vcld couldn't seem to reach, although they appeared running on the ESXi console. It started when I began creating block allocations (which did not appear to work). In both cases there seemed to be text in the log regarding incorrect SQL syntax. After the errors, the affected machines showed as failed in the VCL front end, but eventually reloaded and appear to be working fine. Regular, individual reservations appear to be working fine. I've attached both snippets of log and would appreciate any feedback. Many thanks, Mike RECENT LOG ENTRIES FOR THIS PROCESS: |28851|193:193|deleted| request state: deleted |28851|193:193|deleted| request laststate: reserved |28851|193:193|deleted| computer state: available |28851|193:193|deleted| computer type: virtualmachine 2012-01-24 09:37:20|28851|193:193|deleted|reclaim.pm:process(124)|request laststate is reserved, checking if computer table current image matches image currently loaded on richmond41 |28851|193:193|deleted| WARNING |28851|193:193|deleted| 2012-01-24 11:38:35|28851|193:193|deleted|OS.pm:get_currentimage_txt_contents(161)|failed to retrieve currentimage.txt from richmond41, exit status: 255, output: |28851|193:193|deleted| ssh_exchange_identification: read: Connection reset by peer |28851|193:193|deleted| ( 0) OS.pm, get_currentimage_txt_contents (line: 161) |28851|193:193|deleted| (-1) OS.pm, get_current_image_name (line: 197) |28851|193:193|deleted| (-2) reclaim.pm, process (line: 133) |28851|193:193|deleted| (-3) vcld, make_new_child (line: 568) |28851|193:193|deleted| (-4) vcld, main (line: 346) |28851|193:193|deleted| WARNING |28851|193:193|deleted| 2012-01-24 11:38:35|28851|193:193|deleted|OS.pm:get_current_image_name(201)|failed to retrieve currentimage.txt contents from richmond41 |28851|193:193|deleted| ( 0) OS.pm, get_current_image_name (line: 201) |28851|193:193|deleted| (-1) reclaim.pm, process (line: 133) |28851|193:193|deleted| (-2) vcld, make_new_child (line: 568) |28851|193:193|deleted| (-3) vcld, main (line: 346) |28851|193:193|deleted| WARNING |28851|193:193|deleted| 2012-01-24 11:38:35|28851|193:193|deleted|reclaim.pm:process(135)|failed to retrieve name of image currently loaded on richmond41, computer will be reloaded |28851|193:193|deleted| ( 0) reclaim.pm, process (line: 135) |28851|193:193|deleted| (-1) vcld, make_new_child (line: 568) |28851|193:193|deleted| (-2) vcld, main (line: 346) 2012-01-24 11:38:35|28851|193:193|deleted|utils.pm:get_management_predictive_info(5849)|management node info retrieved from database 2012-01-24 11:38:35|28851|193:193|deleted|DataStructure.pm:get_next_image_dataStructure(1187)|attempting to load predictive loading module: VCL::Module::Predictive::Level_1 2012-01-24 11:38:35|28851|193:193|deleted|Module.pm:create_mn_os_object(335)|management node OS object has already been created, address: 1ac5a880, returning 1 2012-01-24 11:38:35|28851|193:193|deleted|Module.pm:new(203)|VCL::Module::Predictive::Level_1 object created, address: 1b199aa0 2012-01-24 11:38:35|28851|193:193|deleted|DataStructure.pm:get_next_image_dataStructure(1197)|VCL::Module::Predictive::Level_1 predictive loading object successfully created 2012-01-24 11:38:35|28851|193:193|deleted|Level_1.pm:get_next_image(91)|predictive_reload_Level_1 : starting predictive_reload_level_1 for 45 2012-01-24 11:38:35|28851|193:193|deleted|utils.pm:is_inblockrequest(6163)|zero rows were returned from database select 2012-01-24 11:38:35|28851|193:193|deleted|Level_1.pm:get_next_image(247)|predictive_reload_Level_1 : computer_short_name= richmond41 type= virtualmachine 2012-01-24 11:38:35|28851|193:193|deleted|Level_1.pm:get_next_image(248)|predictive_reload_Level_1 : avail= 25 notavail= 25 online= 50 timeframe= 1 DAY 2012-01-24 11:38:35|28851|193:193|deleted|Level_1.pm:get_next_image(357)|predictive_reload_Level_1 : 1 available images can go on richmond41 2012-01-24 11:38:35|28851|193:193|deleted|Level_1.pm:get_next_image(379)|predictive_reload_Level_1 : 1 of 1 available images loaded at least once 2012-01-24 11:38:35|28851|193:193|deleted|Level_1.pm:get_next_image(391)|predictive_reload_Level_1 : 0 of 1 total images available for selection |28851|193:193|deleted| WARNING |28851|193:193|deleted| 2012-01-24 11:38:35|28851|193:193|deleted|utils.pm:database_select(4008)|could not execute statement, |28851|193:193|deleted| SELECT |28851|193:193|deleted| COUNT(imageid) AS cnt, |28851|193:193|deleted| imageid |28851|193:193|deleted| FROM |28851|193:193|deleted| log |28851|193:193|deleted| WHERE |28851|193:193|deleted| imageid IN () |28851|193:193|deleted| AND start (NOW() - INTERVAL 1 DAY) |28851|193:193|deleted| GROUP BY imageid |28851|193:193|deleted| ORDER BY cnt DESC |28851|193:193|deleted| LIMIT 1
Re: Getting reclaim errors, SQL syntax statements in log with block allocations
I've been looking into this further, and I've found what appears to be a missing PERL module (LWP::Protocol::https). I attempted to install it manually with CPAN, but I get two test errors. I've attached the CPAN error message immediately below, and the section of vcld.log from the moment I save the block allocation. Thanks to all, Mike -- t/apache# Failed test 1 in t/apache.t at line 12 # t/apache.t line 12 is: ok($res-is_success); # Failed test 2 in t/apache.t at line 13 # t/apache.t line 13 is: ok($res-content =~ /Apache Software Foundation/); t/apacheFAILED tests 1-2 Failed 2/2 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache.t 22 100.00% 1-2 Failed 1/1 test scripts, 0.00% okay. 2/2 subtests failed, 0.00% okay. make: *** [test_dynamic] Error 255 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force -- 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm:process(166)|owner email: root@localhost Use of uninitialized value in concatenation (.) or string at /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167 (#1) (W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a or a 0, but maybe it was a mistake. To suppress this warning assign a defined value to your variables. To help you figure out what was undefined, perl tells you what operation you used the undefined value in. Note, however, that perl optimizes your program and the operation displayed in the warning may not necessarily appear literally in your program. For example, that $foo is usually optimized into that . $foo, and the warning will refer to the concatenation (.) operator, even though there is no . in your program. |3518|blockrequest| WARNING |3518|blockrequest| 2012-01-24 19:40:35|3518|blockrequest|vcld:warning_handler(610)|Use of uninitialized value in concatenation (.) or string at /usr/local/vcl/bin/../lib/VCL/ blockrequest.pm line 167. |3518|blockrequest| ( 0) vcld, warning_handler (line: 610) |3518|blockrequest| (-1) blockrequest.pm, process (line: 167) |3518|blockrequest| (-2) vcld, make_new_child (line: 568) |3518|blockrequest| (-3) vcld, main (line: 448) 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm:process(167)|help address: 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm:process(172)|updated process flag on blocktime_id= 4 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm:process(192)|processing blocktime_id= 4 pass 1 2012-01-24 19:40:35|3518|blockrequest|utils.pm:xmlrpc_call(9105)|argument_string= XMLRPCprocessBlockTime 4 1 2012-01-24 19:40:35|3518|blockrequest|utils.pm:mail(1268)|SUCCESS -- Sending mail To: 0, PROBLEM -- vcld:die_handler(636)|test |3518|blockrequest| CRITICAL |3518|blockrequest| 2012-01-24 19:40:35|3518|blockrequest|vcld:die_handler(636)|Can't locate object method type via package RPC::XML::Client::send_request: HTTP server error: Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) (perhaps you forgot to load RPC::XML::Client::send_request: HTTP server error: Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)?) at /usr/local/vcl/bin/../lib/VCL/ utils.pm line 9121. |3518|blockrequest| ( 0) vcld, die_handler (line: 636) |3518|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |3518|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) |3518|blockrequest| (-3) blockrequest.pm, process (line: 193) |3518|blockrequest| (-4) vcld, make_new_child (line: 568) |3518|blockrequest| (-5) vcld, main (line: 448) 2012-01-24 19:40:35|3518|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest destructor called, address: 96b7c1c 2012-01-24 19:40:35|3518|blockrequest|State.pm:DESTROY(848)|number of database handles state process created: 1 2012-01-24 19:40:35|3459|vcld:REAPER(718)|VCL process exited for reservation unknown, PID: 3518, signal: CHLD On Tue, Jan 24, 2012 at 12:05, Mike Haudenschild m...@longsight.com wrote: Hello, VCL dev -- I've seen three instances of relaim errors on my VCL instance today -- machines that vcld couldn't seem to reach, although they appeared running on the ESXi console. It started when I began creating block allocations (which did not appear to work). In both cases there seemed to be text in the log regarding incorrect SQL syntax. After the errors, the affected machines showed as failed in the VCL front end, but eventually reloaded and appear to be working fine. Regular, individual reservations appear to be working fine. I've attached both snippets of log and would appreciate any feedback. Many thanks, Mike
VCL block alloc, PERL module issue update
Good evening, I apologize for the numerous emails, but as I continue working through this something new popped up: I managed to get LWP::Protocol::https to install by first updating Net::SSLLeay with CPAN. However, when making a block allocation I now get this in the log: |4978|blockrequest| CRITICAL |4978|blockrequest| 2012-01-24 20:53:45|4978|blockrequest|vcld:die_handler(636)|Can't locate object method type via package RPC::XML::Client::send_request: HTTP server error:*Can't connect to urichmond.longsight.com:443 (certificate verify failed)* (perhaps you forgot to load RPC::XML::Client::send_request: HTTP server error: Can't connect to server.domain.com:443 (certificate verify failed)?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. |4978|blockrequest| ( 0) vcld, die_handler (line: 636) |4978|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |4978|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) |4978|blockrequest| (-3) blockrequest.pm, process (line: 193) |4978|blockrequest| (-4) vcld, make_new_child (line: 568) |4978|blockrequest| (-5) vcld, main (line: 448) 2012-01-24 20:53:45|4978|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest destructor called, address: f7be070 2012-01-24 20:53:45|4978|blockrequest|State.pm:DESTROY(848)|number of database handles state process created: 1 2012-01-24 20:53:45|4138|vcld:REAPER(718)|VCL process exited for reservation unknown, PID: 4978, signal: CHLD My limited understanding of PERL is at play here, but from my research it seems that updated versions of LWP::UserAgent do strict SSL certificate checking. (We do have a CA-issued SSL cert installed for the VCL Web front end.) http://stackoverflow.com/questions/74358/how-can-i-get-lwp-to-validate-ssl-server-certificates I'd very much appreciate any feedback from experts on the list. Many thanks, Mike On Tue, Jan 24, 2012 at 20:12, Mike Haudenschild m...@longsight.com wrote: I've been looking into this further, and I've found what appears to be a missing PERL module (LWP::Protocol::https). I attempted to install it manually with CPAN, but I get two test errors. I've attached the CPAN error message immediately below, and the section of vcld.log from the moment I save the block allocation. Thanks to all, Mike -- t/apache# Failed test 1 in t/apache.t at line 12 # t/apache.t line 12 is: ok($res-is_success); # Failed test 2 in t/apache.t at line 13 # t/apache.t line 13 is: ok($res-content =~ /Apache Software Foundation/); t/apacheFAILED tests 1-2 Failed 2/2 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache.t 22 100.00% 1-2 Failed 1/1 test scripts, 0.00% okay. 2/2 subtests failed, 0.00% okay. make: *** [test_dynamic] Error 255 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force -- 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm:process(166)|owner email: root@localhost Use of uninitialized value in concatenation (.) or string at /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167 (#1) (W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a or a 0, but maybe it was a mistake. To suppress this warning assign a defined value to your variables. To help you figure out what was undefined, perl tells you what operation you used the undefined value in. Note, however, that perl optimizes your program and the operation displayed in the warning may not necessarily appear literally in your program. For example, that $foo is usually optimized into that . $foo, and the warning will refer to the concatenation (.) operator, even though there is no . in your program. |3518|blockrequest| WARNING |3518|blockrequest| 2012-01-24 19:40:35|3518|blockrequest|vcld:warning_handler(610)|Use of uninitialized value in concatenation (.) or string at /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167. |3518|blockrequest| ( 0) vcld, warning_handler (line: 610) |3518|blockrequest| (-1) blockrequest.pm, process (line: 167) |3518|blockrequest| (-2) vcld, make_new_child (line: 568) |3518|blockrequest| (-3) vcld, main (line: 448) 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm:process(167)|help address: 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm:process(172)|updated process flag on blocktime_id= 4 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm:process(192)|processing blocktime_id= 4 pass 1 2012-01-24 19:40:35|3518|blockrequest|utils.pm:xmlrpc_call(9105)|argument_string= XMLRPCprocessBlockTime 4 1 2012-01-24 19:40:35|3518|blockrequest|utils.pm:mail(1268)|SUCCESS -- Sending mail To: 0, PROBLEM -- vcld:die_handler(636)|test |3518|blockrequest| CRITICAL |3518
[jira] [Commented] (VCL-168) Windows Media Player shortcut gets added to desktop for all users
[ https://issues.apache.org/jira/browse/VCL-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185617#comment-13185617 ] Mike Haudenschild commented on VCL-168: --- This is a function of SysPrep (at least for WinXP). It's definitely annoying. A workaround could be adding a script that deletes the desktop shortcut if it didn't exist in the original default user profile. Windows Media Player shortcut gets added to desktop for all users - Key: VCL-168 URL: https://issues.apache.org/jira/browse/VCL-168 Project: VCL Issue Type: Improvement Components: vcld (backend) Affects Versions: 2.0 Reporter: Andy Kurth Priority: Minor Fix For: 2.3 A shortcut to Windows Media Player gets added to all users' desktop even after configuring the default user profile to not display it. I'm not sure when the shortcut gets added, but it is not present just before an image is captured. This is particularly annoying because the default user profile doesn't appear as you would expect after going through an image capture. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
How VCL determines which VM computers to load
Good afternoon to all -- I'm bringing up a production VCL installation with two ESXi servers. I decided to assign all the odd-numbered VMs to *ESXi A*, and all the even-numbered VMs to *ESXi B*. When I started a quantity of simultaneous reversions (all using the same image), this is what happened: ESXi A: nothing ESXi B: VM 2, VM 4, VM 6, VM 8, VM 10 ... VCL had started up all even-numbered computers. Thinking there was a problem with vcld communicating to *ESXi A*, I reassigned ALL of the VMs to* ESXi A* -- I wanted to ensure that *A* could even receive/make a reservation at all. When I ran the same test again, *ESXi A* did take the reservations (yay), but now I see: ESXi A: VM 1, VM 2, VM 3 ... In this case, VCL started the machines up in serial order. I'm trying to spread the load across both ESXi servers, but I need some help interpreting what's happening here... Many thanks, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com
Re: VCL computer settings: RAM, processors, and speed
Hi Andy -- I have one XP image (created w/ 512MB RAM). I created two VM computers, one with only 256MB RAM. Two reservations of the image started on each of the two VMs -- but VCL created two identical 512MB VMs on ESXi, and started the image on both. If there's a hard-coded minimum RAM of 512MB, that would explain what I'm seeing. Does that sound correct? If I create a new base image with 1024MB RAM, will VCL deploy it on a VM computer with only 512MB? Thanks, Mike 1) By the scheduler to locate a computer that meets the requirements set in the image profile. This is the same for VMs and bare-metal computers. If your VM is set to 256 MB and your image is set to 512 MB, reservations for that image shouldn't be scheduled on that VM. Is this what you're seeing? If so then there's a problem with the scheduling code. 2) By the provisioning module to construct a VM. The RAM and CPU values for the image are normally used. If your image is set to 1 GB RAM and your computer is set to 2 GB, the VM will have 1 GB. There are a few caveats. There is a hard-coded minimum RAM value of 512 MB. This is done to prevent unusable VMs from being created if the image profile RAM setting is set to 0 or a very low value. If your computer is set to 1 GB and your image is set to 256 MB, the VM will be assigned 512 MB. There are other RAM minimums higher than 512 MB depending on the OS of the image being loaded. I don't recall all of them off hand but for example I believe 32-bit Windows 7 is 1 GB, etc.
VCL andVMWare licensing/load balancing
Hello to all. I've been tasked with building out and managing a VCL implementation that will utilize VMWare ESXi 4.1 hypervisors across 5 separate servers. I have trolled the existing documentation and listserv archive, but I have two burning questions: 1. I've read in another thread that VCL doesn't have load balancing capabilities per se as part of the scheduler. How does VCL equalize the load of virtual machines across several hypervisors? 2. I've found that the free VMWare hypervisor 4.1 license caps out at one physical processor (with 6 cores). Are most folks running a non-free VMWare license alongside VCL? I greatly appreciate any assistance that current VCL users and the dev team can provide! Regards, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com
