CloudAtCost legacy wiki

From eddynetweb's cesspit
Revision as of 19:41, 11 March 2017 by Eddynetweb (talk | contribs) (CloudAtCost dump!)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


From CloudAtCocks

You cannot build a machine in this 'Datacenter' as of May 4th, 2016 or earlier... We don't know.

DC-1 is the first known datacenter option offered by CloudAtCost for their CloudPro infrastructure. It's been interpreted by many as being their DC with the highest individual VPS uptime, however due to abuse (and the fact that DC-1 was the only option for a considerable length of time) it's likely the slowest option for disk I/O and network performance.

I/O speed tests[<a title="Edit section: I/O speed tests" data-external="true" href="">edit</a>]

High end

  • I/O (1st run)  : 54.9 MB/s
  • I/O (2nd run)  : 61.4 MB/s
  • I/O (3rd run)  : 59.0 MB/s

Average I/O  : 58.4333 MB/s

Low end (average CaC I/O as submitted by users)

  • Not enough data

Speedtests[<a title="Edit section: Speedtests" data-external="true" href="">edit</a>]

High end

Cachefly        7.93MB/s

Low end

Cachefly        849KB/s

rDNS[<a title="Edit section: rDNS" data-external="true" href="">edit</a>]

The following IP blocks for DC-1 currently have working rDNS:

  • 104.167.x
  • 104.233.x

CPU Options[<a title="Edit section: CPU Options" data-external="true" href="">edit</a>]

  • Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
  • Intel(R) Xeon(R) CPU X7560 @ 2.27GHz

ESXi Nodes[<a title="Edit section: ESXi Nodes" data-external="true" href="">edit</a>]

esx174 ?OKNot Working

Change ESX

From CloudAtCocks

If you're having connection, node-based issues, or your VM seems to have suddenly "disappeared", a simple reboot in most cases will fix the problem. In many cases, problematic VMWare vSphere ESXi nodes may cause problems with connectivity, incredibly slow node, etc.

To change the machine's ESXi:

1) You might want to safely power down your OS first.

In the <a rel="nofollow" class="external text" data-external="true" href="">CloudAtCost panel</a>:

2) Power Off VM

3) Power On VM

You can check if you've been moved by going into the "Console" and checking the URL, as shown:<span class="err">&</span><span class="err">&</span>sshkey=XXX<span class="err">&</span>sha1hash=XXX

Based on the above link, the ESXi in this case would be 3024 (



From CloudAtCocks

Console access with CloudAtCost is served over unsecured HTTP protocol allowing any user to copy his/her console URL and paste it to another user on a different network, resulting in a positive authentication.

Console access is incredibly unstable, you can build a machine, have access and later lose access only to regain it again. We recommend deleting any machine that doesn't initially have console access.

Console is also unencrypted, best practice is to only use the console for netinstalls and forcing fscks.


Alternate Console Access[<a title="Edit section: Alternate Console Access" data-external="true" href="">edit</a>]

CloudAtCost uses noVNC for it's console connections. It is possible to connect to your server instance via noVNC's website.

Step 1

You will need to go to your CloudAtCost control panel and select console. A window will pop-up and begin to connect to the server.

Step 2 The URL will begin with "<a rel="nofollow" class="external free" data-external="true" href=""></a>" but this will soon change to something like

"<a rel="nofollow" class="external free" data-external="true" href=""></a>"

this is the URL we are interested in

Step 3

from this second URL we need to extract the following information: Hostname, Port number, and Password.

1. The Hostname should always be ""

2. The Port Number is the sshkey in the URL. in the example the port is 40000

3. The Password is the sha1hash in the URL. in the example it is ABCdEfG1HI

Write these three things down.

Step 4

Go to "<a rel="nofollow" class="external free" data-external="true" href=""></a>" then go to the 'Connect' button next to the settings button. Enter the hostname the port number and the password and then hit connect.



CloudAtCost IP crisis

From CloudAtCocks

The CloudAtCost IP crisis is a name to describe the exhaustion of IP resources in the entire available pool.

People will frequently experience the following error when generating a new virtual machine:

Failed: Cant Get IP from DC-X. Please Try again.

The ASN used on these addresses is assigned to <a rel="nofollow" class="external text" data-external="true" href="">AS 55053</a>.

In more rare cases, some IP's may even be assigned to more than one customer. This generally results in packet collisions and VM's which have partial or no network functionality.

IP Ranges[<a title="Edit section: IP Ranges" data-external="true" href="">edit</a>]

Here are the following known IP ranges used in each DC.




64.137.x.x (crossover from DC-3)



Solutions[<a title="Edit section: Solutions" data-external="true" href="">edit</a>]

In most cases, just waiting a short period of time will generally be enough to free up IP space from destroyed instances. It is unknown whether IP space after an instance has been destroyed is immediately usable once more, or is allocated at another time.

However, if you're having continual issues, you might want to give the new <a title="Undocumented API" data-external="true" href="">Undocumented API</a> a try. It allows you to specify a DC which may have IP space available.

If you've been assigned a duplicate IP, you can either open a support ticket or just regenerate the VM until you're assigned an IP which is not already assigned. If you suspect a duplicated IP has been assigned to you, you can always check with "arping" on GNU/Linux or "Wireshark" on Windows systems.


CloudAtCost miracle

From CloudAtCocks

Jump to: navigation, search A CloudAtCost miracle is described as an instance in which a previous or current problem with CloudAtCost services have been miraculously solved.

The most common problems noticed are long waits for virtual machine deployment, loss of network connection, or total loss of a virtual machine. This is generally more common after major sales (such as the 2016 Black Friday sale).


A few examples:

Virtual instances notoriously take a profound amount of time to deploy, and in many instances, fail to deploy at all. This is especially prevalent in major sales (see 2016 Black Friday Sale). However, it is possible if you're persistent enough. If you successfully deploy a machine, you'll generally next face network issues (physical or virtual), R/O (read-only, especially on DC-3), and rather slow performance (as a result of abuse and virtual limitations). Rebooting your machine will meet mixed results, such as machines getting stuck during ESXi transitions, loss of network on another node, etc. However, in some cases, you'll land on a node which is actually pretty stable. This had generally been more common in DC-1 (and DC-2 sometimes). Contacting support generally entails your ticket being closed after waiting a long period of time. If you do get a response, it's a mixed bag whether they'll fix the issue at hand. However, they do actually fix issues (such as stuck virtual machines during ESXi power-off transitions, common issues, etc). In some cases, people do get their problems solved though. Experiences[edit]

Post your experiences here!

Retrieved from ‘’

Undocumented API

From CloudAtCocks

Jump to: navigation, search The API the panel uses includes a few improvements over the published "API v1".

Namely: - The ability to specify the data centre when building a VM


Unfortunately, the new panel doesn't use a proper API-like structure. For example, the list of VMs is embedded in index.php, rather than being supplied in JSON and then interpreted. This gives the panel an old-world style behaviour. e.g. refreshing the whole page when things change.

URLs[edit] [HTTP POST]


datacenter int Currently (1, 2, or 3) cpu int Number of CPUs ram int Amount of memory in MB storage int Amount of storage in GB os int Operating System to load (see below) cid int The customer ID - should be ~9 digits freecpu int Obviously remaining CPU in the account, but as to why we'd be posting this, I have no idea. freeram int Ditto for free RAM freestorage int Ditto for free storage btkn int An API token, presumeably

Operating Systems:

1 CentOS 6.7 64bit 15 CentOS-7-64bit 3 Debian-8-64bit 18 FreeBSD-10-1-64bit 16 Ubuntu-14.04.1-LTS-64bit 13 Windows 2008 R2 64bit 14 Windows 2012 R2 64bit 4 Windows 7 64bit Retrieved from ‘’


From CloudAtCocks

Jump to: navigation, search DC-2 Arguably the best DC CloudAtCost has to offer (currently the only) RIP (Machines are Still Up)


1 I/O speed tests 2 Speedtests 3 rDNS 4 CPU Options 5 ESXi Nodes I/O speed tests[edit]

High end

I/O (1st run) : 69.6 MB/s I/O (2nd run) : 70.6 MB/s I/O (3rd run) : 62.5 MB/s Average I/O : 67.5667 MB/s

Low end (average CaC I/O as submitted by users)

I/O (1st run) : 6.4 MB/s I/O (2nd run) : 6.5 MB/s I/O (3rd run) : 6.4 MB/s Average I/O : 6.5667 MB/s


High end

Cachefly 96.45MB/s Low end

Cachefly 1.45MB/s rDNS[edit]

The following IP blocks for DC-2 currently have working rDNS:

45.62.x 162.x 167.x 64.137.162.x 64.137.166.x 64.137.186.x 64.137.182.x 64.137.183.x 64.137.x stolen from

CPU Options[edit]

Intel(R) Xeon(R) CPU L5520 @ 2.27GHz Intel(R) Xeon(R) CPU X7560 @ 2.27GHz Intel(R) Xeon(R) CPU L7455 @ 2.13GHz ESXi Nodes[edit]

Node CPU Network Console esx2012 No Route (2016-12-20) esx2017 L5520

esx2018 No Route (2016-12-20) esx2021 L5520

esx2046 L5520

esx2094 No Route (2017-02-07) esx2100 X7560 OK (2017-01-06) Error 1006 (2017-01-06) esx2102 X7560 OK (2016-12-20) OK (2016-12-20) esx2103 X7560 OK (2016-12-27) OK (2016-12-27) esx2105 X7560

esx2107 X7560

esx2108 X7560 OK (2017-01-18) Borked (2017-01-18) esx2110 X7560 OK (2017-01-06) Error 1006 (2017-01-06) Retrieved from ‘’

Navigation menu