Prometeus - Your 'net consultants !

Hello !

Thank you for choosing our storage plans and thank you for your choice of IPv6 !

A few words about these plans:
Bad news:
-There is no raid (redundancy), if a haed drive fails, the data is lost because there are no backups of backups either. Hopefully, this failure will not happen exactly when you need the backup. Chances for this to happen considering a 99% uptime during a year is 1 in 10.000. It still exists, but not very likely.
-The machines are equipped with one atom D525 processor dual core with hyperthreading which means 4 logical cores.
-Due to those limitations these machines will be used solely for backups.
-Port speed is 100 mbps only.
-Obviously IPv6 only, so legacy connection people will not be able to control the machine from home otherwise than through VNC/console. These are meant for backing up your Prometeus boxes or to mount as extra partitions or drives into them. Since all our VPSes have IPv6, that will be absolutely no problem.

Good news:
-Virtualization is Xen-PV which means you can run not only almost any backup software, but also control the kernel, even compile your own if you take care and include the necessary Xen bits in it. Some images support iSCSI out of the box, same as NFS, Samba, etc, but you can install and tweak them as you wish on any image. You can run IPSec or any kind of VPN without the need of fancy modules, can have your own firewall, can encrypt the filesystem...
-Each machine comes with at least one /64 of IPv6 addresses and a separate one for control.
-The largest plan offers the opportunity to have two machines, each with own /64 and own IPv6 control IP. You can divide the resources between them as you wish. Or you can make a single big VM.
-While the port is limited to 100 mbps, the density of machines per node will be really low since it cant hold lots with that kind of CPU. Depending on size and how they sell, will be 10-20 VMs sharing the port. In comparison, big 128 GB nodes with 48 cores host as many as 200+ VMs sharing one 1 gbps port, so the proportion here will be about the same.
-These machines will be mostly idle since we do not allow running anything else than back-up software on them and that doesnt happen non-stop compared to a busy website. As such, even tho the disks are far from the performance of the high IOPS SAS2 or SSD raids, they will be enough for the purpose. Even at full 100 mbps port transfer, the write speed will far outweight the network speed, so the drives will not suffer at all.

Now, for the real HowTo.

The control panel is Cloudmin GPL. This means things are a bit different from SolusVM, it is meant to offer resources which you partition as you please, not machines ready-made.
The credentials you receive will be for an account and not a machine. When you login the first time, you will see this:

As you see, the plan has 1 GB more set aside for swap, you may or may not create the swap, in case you dont wish to use it, you can use the whole 51 GB for storage.
Now let's proceed to create a vm

We'll now choose the machine's characteristics:

Internet hostname: put something like test. It will be added to the node hostname, so will be in this case test.atomic02.prometeus.net
System description: anything you like.
Cloudmin system image: Select one of the images there, atm there are Centos 6.3 amd64/i386, Ubuntu 10.04 amd64/i386 and Debian squeeze amd64 since i386 is incompatible with Xen-PV in this case. More can be added upon request. These images have the correct and closest repositories set, for Centos we have even own mirror.
SSH login mode: select your ssh password. Key authentication can be enabled in case you do not allow password authentication, but that you will need to setup later once you have the keys in. This tutorial does not cover that, it is supposed you know what you are doing. The password you input there will be set to your machine during creation. You can change it later or set authentication with key only.
Memory allocated for instance: in this case, 128 MB. You can select less for testing purposes, but more will result in an error and the machine will not be created. The kernel memory is deducted so the free -m command in the machine will show you less RAM.
Disk space allocated for instance: since this is a 50 GB plan, we select 50 GB, if you do not wish to use swap below, you can put 51 here and select no swap below. Maximum swap will be 1 GB, do not put more than your plan allows as the machine will not be created.
Maximum CPU use: select your plan's maximum, in this case 100% which means one shared core. 200% means 2 shared cores at max, but do not put more than the plan allows, you will get an error and will have to start over. Also, while you can set lower level than the maximum allowed, this only makes sense for the 200 GB plan where you can create 2 machines, in the other cases, it is simply a waste.
Maximum bw can be left untouched, we do not limit bw per plan, only traffic, so bw will be fair share of the 100 mbps port, most likely you will use it fully since there are few people on the same node and unlikely that 2 are doing backups in the same time. To avoid that I suggest you set your backup crons at odd numbers such as 15:21 or 03:15 to avoid even that small chance. If everyone would put backup at 00:00 italy time it will be slow as the port will remain 100 mbps at all times.
If you wish to further tweak your network, click the below network settings. The defaults should be fine, just dont start to make up IPs...
Now, we can click create !
It will take a while, and it will show you the progress like this: Congratulations, you VM is up and ready (I chose a debian here)

Let's take a look at the expanded menu on the left:

-Reset from image is like reinstall in Solus, the system will be initialized with a fresh system.
-Graphical console is the equivalent of VNC, same is text console, but a bit more rudimentary and easier on resources
-Manage disks opens a powerful menu where you can destroy your data if you dont know what you are doing. The other people dont need explanations
-Resource limits make sense only if you have multiple systems (we are investigating the possibility to allow that in the future), but for now you can only limit yourself artificially so not a very good idea to play with those, unless you want to see how the system will go with less CPU and ram eventually
-Network interfaces is not very useful now, but we are investigating the possibility to allow multiple ifs, but for a backup plan, that is not needed.
The other options are either self explanatory, or not needed.

A few caveats:
The new machine gets an available IP fromt he pool. The first one available is served. This means the first few can be redistributed if your machine is down for a reason and someone else creates another in that time.
So you will be given a different IP at the restart. This is the control IP which you can fix. In all nodes I will give IPs in the 1000-1999 range. These are much more than 999 because you can use letters a-f also. So looking above: That is the IP that was assigned by the system for control purposes and you can put it manually in the network settings when you create the VM, but dont try to use the one you got at creation, make up something like 2a00:dcc0:eda:3748:247:48:25:1abc or 2a00:dcc0:eda:3748:247:48:25:1a00 by variating those 4 last symbols in the interval 0-9 and a-f. Write it down and use it when you create the machine so it remains the same. Destroy and recreate the machine as many times as you please, but if you want to keep the IP do as I tell you.
One other thing is the fact that you get automatically a /64 which is derived from the random MAC that it is generated when the machine is created. If you recreate the VM (not reset from image), it will get another MAC, so another /64, this is why it is important to keep the control IP (or never recreate the machine, just reset from image and you will have the same /64)
I understand these things are new and seem alien for many, but this is the beginning of the IPv6 era and many things are to be learned.
I will add to the guide keeping in mind your suggestions.
For now, should be enough to get you running.

Also, if you are running Debian and change the mirror, you'll realize that most mirrors are not IPv6. You have to specify this manually:
http://mi.mirror.garr.it/mirrors/debian/

Yes, that is the closest, however, it is already setup in the debian template for Xen storage plans.
In KVM cases, tho, you need to put it by hand, but, unlike Ubuntu, Debian has IPv6 in the default repositories in US.

http://mi.mirror.garr.it/mirrors/debian/ stopped working. Now the only one which routes OK is All the others first try IPv4 and get stuck there. This is IPv6 only and thus works. security. works well for some reason, although it's a v4/v6.

Ooops... I hope it is a temporary problem, otherwise will have to modify the templates. It is strange since garr.it has a very good record.

I dont know, but if you wish to store and sync files for yourself, you probably would do better with owncloud.