Re: Dev feedback requested, management commands sent to Cygwin
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 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 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 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 (Ming
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 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 > 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 > 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 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
[jira] [Resolved] (VCL-502) allow aspects of automatic user groups to be managed through UI
[ https://issues.apache.org/jira/browse/VCL-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson resolved VCL-502. --- Resolution: Fixed > allow aspects of automatic user groups to be managed through UI > --- > > Key: VCL-502 > URL: https://issues.apache.org/jira/browse/VCL-502 > Project: VCL > Issue Type: Improvement > Components: web gui (frontend) >Reporter: Josh Thompson >Assignee: Josh Thompson > Fix For: 2.3 > > > Make automated user groups show up on Manage Groups page and allow everything > but membership to be modified. Allow group to be deleted but with a warning > that it will be recreated if someone that is a member of the group logs in > through ldap or shib. -- 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
[jira] [Assigned] (VCL-513) allow block allocation control per affiliation
[ https://issues.apache.org/jira/browse/VCL-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson reassigned VCL-513: - Assignee: Josh Thompson > allow block allocation control per affiliation > -- > > Key: VCL-513 > URL: https://issues.apache.org/jira/browse/VCL-513 > Project: VCL > Issue Type: Improvement > Components: web gui (frontend) >Reporter: Josh Thompson >Assignee: Josh Thompson > Fix For: 2.3 > > > Add a user group permission that grants the ability to control block > allocations matching that user's affiliation only. -- 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
[jira] [Resolved] (VCL-551) deleting an active VM doesn't remove it from the VM host
[ https://issues.apache.org/jira/browse/VCL-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson resolved VCL-551. --- Resolution: Fixed > deleting an active VM doesn't remove it from the VM host > > > Key: VCL-551 > URL: https://issues.apache.org/jira/browse/VCL-551 > Project: VCL > Issue Type: Bug > Components: web gui (frontend) >Affects Versions: 2.2.1 >Reporter: Josh Thompson > > If you delete a VM assigned to a VM host, it leaves the VM assigned to the > host. The vmhostid for the VM should be set to null. -- 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
[jira] [Assigned] (VCL-444) time delay the display of the Get RDP File button to allow vcld to grant access
[
https://issues.apache.org/jira/browse/VCL-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Thompson reassigned VCL-444:
-
Assignee: Josh Thompson
> time delay the display of the Get RDP File button to allow vcld to grant
> access
> ---
>
> Key: VCL-444
> URL: https://issues.apache.org/jira/browse/VCL-444
> Project: VCL
> Issue Type: Improvement
> Components: web gui (frontend)
>Reporter: Josh Thompson
>Assignee: Josh Thompson
> Fix For: 2.3
>
>
> If a user clicks the Connect button and then the Get RDP File button too
> quickly, vcld will not have a chance to actually grant the user access
> through the host firewall. Having javascript delay the display of the Get
> RDP File button would help users not be confused about why they were not able
> to connect to the machine.
> Gerhard Hartl from ODU contributed the following code to make this happen:
> Roughly around line 2217 (v2.2.1) on requests.php replace the Get RDP File
> form section with:
> print "\n";
> print " .off {\n";
> print " visibility: hidden;\n";
> print " } .on {\n";
> print " visibility: visible;\n";
> print " }\n";
> print "\n";
> print "\n";
> print " window.onload = function() {\n";
> print " var timeInterval = 5;\n";
> print " if (typeof timeInterval === 'undefined' || parseInt(timeInterval) <=
> 0) {\n";
> print " timeInterval = 1\n";
> print " }\n";
> print "document.getElementById('counter').innerHTML = \" Ready to connect in
> \" + timeInterval + \" seconds\";\n";
> print "var si = setInterval(function() {\n";
> print "if (timeInterval === 0) {\n";
> print " clearInterval(si);\n";
> print " } else {\n";
> print "--timeInterval;\n";
> print "if (timeInterval !== 0) {\n";
> print " document.getElementById('counter').innerHTML = \" Ready to
> connect in \" + timeInterval + \" seconds\";\n";
> print "} else {\n";
> print " document.getElementById('counter').className = 'off';
> //Hiding the counter area.\n";
> print " document.getElementById('submit').className = 'on'; //Unhide
> the Submit button\n";
> print "}\n";
> print "}\n";
> print "}, 1000);\n";
> print "setTimeout(function() {\n";
> print "}, timeInterval * 1000);\n";
> print "}\n";
> print "\n";
> print "For automatic connection, you can download an RDP file that can ";
> print "be opened by the Remote Desktop Connection program.\n";
> print "";
> print "\n";
> print " \n";
> print "\n";
> print " id=\"connect\">\n";
> $cdata = array('requestid' => $requestid,
> 'resid' =>
> $requestData['reservations'][0]['reservationid']);
> $expire = datetimeToUnix($requestData['end']) -
>datetimeToUnix($requestData['start']) + 1800; # reservation
> time plus 30 min
> $cont = addContinuationsEntry('sendRDPfile', $cdata, $expire);
> print " \n";
> print " id=\"submit\">\n";
> print " \n";
> print "\n";
> print " \n";
> print "\n";
--
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
[jira] [Assigned] (VCL-497) dedup eppn
[ https://issues.apache.org/jira/browse/VCL-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson reassigned VCL-497: - Assignee: Josh Thompson > dedup eppn > -- > > Key: VCL-497 > URL: https://issues.apache.org/jira/browse/VCL-497 > Project: VCL > Issue Type: Improvement > Components: web gui (frontend) >Reporter: Josh Thompson >Assignee: Josh Thompson > Fix For: 2.3 > > > The Shibboleth spec allows the eppn to contain duplicates. The code needs to > be updated to handle multiples as well as duplicates in those multiples. -- 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
[jira] [Assigned] (VCL-520) Improving display control, on an detailed information of an image
[ https://issues.apache.org/jira/browse/VCL-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson reassigned VCL-520: - Assignee: Josh Thompson > Improving display control, on an detailed information of an image > - > > Key: VCL-520 > URL: https://issues.apache.org/jira/browse/VCL-520 > Project: VCL > Issue Type: Improvement > Components: web gui (frontend) >Affects Versions: 2.2 >Reporter: Toru Yokoyama >Assignee: Josh Thompson >Priority: Minor > Fix For: 2.3 > > Attachments: requests.diff, requests.php > > > When inputing any character except alphabets or numbers to the "Image > Description" or "Usage Notes" of the Edit Image page, the detailed > information of an image will not be shown at the "New Reservation" page and > the "Connect" page. > Considering a case when VCL is used out of English-speaking areas, > improvement is needed in the display judging method for a detailed > information of an image. > (Refer [VCL-485]) -- 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
[jira] [Assigned] (VCL-521) An OS image named in japanese 2byte characters doesn't run
[ https://issues.apache.org/jira/browse/VCL-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson reassigned VCL-521: - Assignee: Josh Thompson > An OS image named in japanese 2byte characters doesn't run > -- > > Key: VCL-521 > URL: https://issues.apache.org/jira/browse/VCL-521 > Project: VCL > Issue Type: Improvement > Components: vcld (backend), web gui (frontend) >Affects Versions: 2.2 > Environment: Windows images (Japanese) >Reporter: Toru Yokoyama >Assignee: Josh Thompson >Priority: Minor > Fix For: 2.3 > > Attachments: images.diff, images.php > > > If the image name(prettyname) of an OS image is named in japanese 2byte > characters, the virtual OS will not run. The direct cause is that the Guest > OS does not reply, when set_my_computer_name function is submitted by VCL > daemon. Considering a case when VCL is used out of English-speaking areas, > we suggest an improvement.(Refer [VCL-485]) > We attached a source code with an interim bug fix. > Bug fix: Changing the character check method of the Web GUI to only allow > alphabets, numbers and limited symbols. -- 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
