OTOY Forums

This just plain does not work as described in the document, trying to use the Cloud Workstation / Adsk edition
The connection always times out. In all browsers. Every time you start the system the GUID is different.
Setting the GUID outside in the user metadata does not have any effect, when starting the GUID will be different again.

A waste of time. I do wonder, why was it a good idea to push this out without further testing.
Did anybody get this to work?

If you set the GUID in the metadata it overrides the auto generated one entirely. I will update the documentation to make this is clearer. The GUID check was added by AWS right before launch as a security precaution. If you use the GUID metadata, also be sure to copy over the group policy settings.

At first I also had the timeout problem with an eu-west instance. Then I created a new instance in us-east and now it works (using the exact same settings otherwise).

Agreed this actually doesn't work for me either. My initial creation of the AMI instance (including RDP in to get GUID) then enter all info into Chrome browser worked!

But now after restarting my AMI instance (and yes revising the URL to include the new public DNS and the newly created GUID), I still get network timeouts so something is definitely going on with the connection between aws.otoy.com and the AMI instance.

Please confirm whether or not you are setting the GUID in the metadata field. If you are, then you should ignore the GUID showing up in the console, as it will be overridden by the GUID in the metadata field. Also, if you are having GUID issues with your instance, please PM your instance IP and I can remove the GUID check.

Goldorak wrote:Please confirm whether or not you are setting the GUID in the metadata field. If you are, then you should ignore the GUID showing up in the console, as it will be overridden by the GUID in the metadata field. Also, if you are having GUID issues with your instance, please PM your instance IP and I can remove the GUID check.

Tried it both ways actually. But for some reason, now it is working out of the blue with the user-supplied GUID method. (disregarding the autogenerated one).

I am still getting lots of latency and slow response. Not sure if this is expected this early in the technology or not.

kmorin wrote:

Goldorak wrote:Please confirm whether or not you are setting the GUID in the metadata field. If you are, then you should ignore the GUID showing up in the console, as it will be overridden by the GUID in the metadata field. Also, if you are having GUID issues with your instance, please PM your instance IP and I can remove the GUID check.

Tried it both ways actually. But for some reason, now it is working out of the blue with the user-supplied GUID method. (disregarding the autogenerated one).

I am still getting lots of latency and slow response. Not sure if this is expected this early in the technology or not.

Wow - no that is not normal at all!

The ping time should be well under <90 ms - even if you are a continent away, and under 50 ms if you are within 1000-2000 miles. What region is the server in, and how far are you from there?

I'm having the same issue with timeouts. I first tried creating an Octane Cloud Workstation instance straight from the marketplace. I got in with RDP and grabbed the GUID, but all attempts to connect timeout. I've even tried shutting down the firewall and opening up every port in my AWS Security Group just to make sure I'm not being blocked.

I then tried regenerating the instance from scratch with this AMI: AMI-OTOY-OCTANE-WINDOWS_1.0-1765694b-3372-4e71-9d75-0703468ad20d-ami-8f5d16e6.1 (ami-b8059a88)

I passed in the GUID=<guid> as a parameter but that GUID didn't successfully show up in the process parameters. I've tried connecting with both the GUID that I provided and the GUID that's listed in the process, but no luck. A timeout every time.

I've tried connecting with both Chrome and Firefox using this URL:
http://aws.otoy.com/?connect=//<my_inst ... D=<my_GUID>

An update: Repeated attempts to connect from Firefox or Chrome on PC all failed. However, we have successfully connected from OSX using Safari, Chrome, and Firefox! It's worth noting that the working URL is the one that uses the GUID specified in the launch parameters, not the one that shows up in the process details.

PixelWrangler wrote:An update: Repeated attempts to connect from Firefox or Chrome on PC all failed. However, we have successfully connected from OSX using Safari, Chrome, and Firefox! It's worth noting that the working URL is the one that uses the GUID specified in the launch parameters, not the one that shows up in the process details.

Correct - when you specify a GUID in the metadata, it overrides the GUID in the launch parameters, and will only allow you to connect with the GUID supplied in the metadata.