Support¶
Our KVM and Cloud Server are unamanaged VPS.
Control Panel¶
You can reach our control panel here:
The username is your customer number, which you can find in our welcome mail or invoices.
Access Root Console¶
You can access the root console of your systems via our control panel
https://my.virtualhosts.de/cloud/
Via ‘cloud’ you will see all your current services. By clicking on the gear symbol you can choose ‘console’ to start your virtual console.
Setting rDNS¶
You can set rDNS records via our control panel
https://my.virtualhosts.de/cloud/
Via ‘cloud’ you can see all your current services. Click on the gear symbol and choose ‘server-information’. Below you can edit your rDNS entries.
Additional IP Address¶
Additional IP addresses are available at 1.50 EUR/month (without VAT). You can get two additional IP addresses for each VPS. To order a new IP address you need to send us a mail with your VPS main IP address.
Please Note the following:
A justification for the additional IP address is needed. Without valid justification we cannot assign additinal IP addresses.
Upgrading your VPS¶
Can be done anytime via e-mail. You need to chose any higher plan from our website
respectively
https://www.providerservice.com/
first. You probably need to resize your partition (/dev/vdb) and filesystem afterwards, see here.
Cancelling your VPS¶
Please use our control panel
https://my.virtualhosts.de/services/
to cancel your VPS. Via ‘Services’ you will get an overview on your current and cancelled services. By clicking on the gear symbol you can choose ‘service information’. There you can click on ‘actions’ and choose to cancel your service.
Network Problems¶
We need a bidirectional MTR log to help you analyse or detect network problems.
How can I install MTR?¶
See below.
Windows¶
Windows packages can be found here: https://www.google.com/search?q=winmtr
MTR usage¶
On Linux or MacOS you can use the following command to start the trace:
mtr -n -r --report-cycles 500 $IP
A trace looks like this:
# mtr -n -r --report-cycles 500 www.providerdienste.de
HOST: my.computer.net Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 500 27.5 27.3 0.4 40.2 1.7
2. 217.0.117.1 0.0% 500 27.3 27.8 26.7 187.2 7.6
3. 217.237.155.4 0.0% 500 28.7 28.9 26.7 32.9 1.2
4. 62.154.33.62 0.0% 500 36.4 37.9 35.6 40.3 1.2
5. 62.157.249.78 0.0% 500 36.0 35.7 35.0 61.6 2.2
6. 4.69.161.138 0.0% 500 39.4 40.7 38.8 59.5 1.9
7. 212.162.17.190 0.0% 500 39.9 54.4 39.0 295.8 41.4
8. 130.255.184.86 0.0% 500 39.4 39.1 38.7 43.6 0.3
In this case the latency and package loss is fine. In case of an error the result might look like this:
# mtr -n -r --report-cycles 500 www.providerdienste.de
HOST: my.computer.net Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 500 27.5 27.3 0.4 40.2 1.7
2. 217.0.117.1 0.0% 500 27.3 27.8 26.7 187.2 7.6
3. 217.237.155.4 0.0% 500 28.7 28.9 26.7 32.9 1.2
4. 62.154.33.62 0.0% 500 36.4 37.9 35.6 40.3 1.2
5. 62.157.249.78 0.0% 500 36.0 35.7 35.0 61.6 2.2
6. 4.69.161.138 0.0% 500 39.4 40.7 38.8 59.5 1.9
7. 212.162.17.190 83.0% 500 268.9 274.4 239.0 295.8 41.4
8. 130.255.184.86 90.0% 500 299.4 299.1 248.7 313.6 60.3
From hop 7 to the last hop massive packetloss is visible. There seems to be a problem with the network connection. If you see looses on any hop but the last one, this doesn’t necessarily mean that there is a problem with your connection.
Relevant for the quality of the connection are the values for the last hop.
Asymmetrical routing¶
Routing can be asymmetrical: outgoing packets might not use the same route as incoming packets from the same connection. This is why we always need a bidirectional MTR log. In above example, the disturbance on Hop 7 / 8 the underlying cause might as well be in the other direction.