ilpapabuono's picture
ilpapabuono - Fri, 2013/12/13 - 18:37

Hi all, I'm a newbie of the cloud services so I'm sorry for the possibly silly question.

I've done a try with a micro server (LAPP) and all went well. I've configured and tailored the machine, loaded my software etc.

Now I need to:

1) Download the VM so obtained in order to give it to a customer. The customer will create an account by itself on turnkey hub and will start to use that machine, uploading the downloaded one to its account or

2) I need to transfer that machine, or a snapshot, on its account

How can I make one or both of these things? I'll have to use backup services?

Thanks in advance

Forum: 
Support
Jeremy Davis's picture

Jeremy Davis - Sat, 2013/12/14 - 01:08

This is somethng of a rephrased/adjusted version of a recent post I made...

TKL Hub (aka The Hub) is the preferred front end for managing TKL instances on AWS and it also allows you to configure TKLBAM (TKL Backup And Migration - TKL's smart backup and migration system) as well as view previous backups. The Hub is much more user friendly (than the AWS control panel - IMO) and allows you access to the v13.0 release appliances (they are coming to AWS marketplace but as yet are not available).

So I would recommend that you use TKLBAM to migrate your data to a new appliance (owned/controlled by your customer). My recommended migration process would look something like this:

  1. Set up TKLBAM (if you haven't already) and run a (full) TKLBAM backup of your current LAPP appliance. Don't do anything else with your original/current server for now!
  2. Get your customer to launch a v13.0 LAPP appliance (via TKL Hub) of the desired size and config (e.g. x64 m1.medium or whatever... I'd definately recommend x64 though...). Ensure that your customer gives you their root username and their TKL Hub API key
  3. Apply your TKL Hub/TKLBAM API key to the new server: 
    tklbam-init --force YOUR_HUB_APIKEY
    You May need to remove their existing key: 
    rm -rf /var/lib/tklbam
    Note: I haven't tested these commands recently (these relate to TKLBAM v1.2; versions 1.3 & 1.4 were released recently in quick succession and I am not sure what changes have been made in this regard)
  4. Restore your TKLBAM backup to this new server (documenting as you go for 'best practice')
  5. Test your new server, ensuring everything works (again documenting as you go, particularly any adjustments, tweaks and modifications you need to make, theoretically there should be very few, hopefully none!)
  6. Once happy with the results, repeat step 3, except this time apply your customers API key (so future backups go to their account, not yours)
  7. Run a full TKLBAM backup (so if your customer messes something up you can assist them to restore to the starting point)
  8. Once you are 100% happy that everything is good and working well (and not a moment sooner!), destroy your old server (if you want to...)

Also if I were you I'd encourage your customer to change their root password (after you've finished) so that you don't have it. Even if they trust you, unless you are going to manage it for them (which if you are then IMO you are probably better off keeping it on your account and just pass on the hosting charges too) then it reduces/eliminates the possibility of you being blamed for anything that goes wrong in the future...

ilpapabuono's picture

ilpapabuono - Sun, 2013/12/15 - 01:53

...it's COMPLEX. I must say that to have a copy of a virtual machine customized by me would me more peaceful; and idem for the possibility og uploading it as a new VM.

Many thanks, in every case, I'll try to follow your instructions.

Jeremy Davis's picture

Jeremy Davis - Sun, 2013/12/15 - 04:02

I've just explained it in minute detail. Here is the abridged version:

  1. Backup your customised machine
  2. Restore the backup to the customer's (new) VM
  3. Replace your TKL Hub key with your customer's
  4. Test and assuming that all is well, run a full backup for the customer...

What you are doing in effect is copying the customisations you have made across to the customer's (clean, fresh) machine.

And the beauty of this system is that you can do your development on a local VM if you'd prefer and then migrate it to the cloud whenever you like (and back again if you choose). Also if you do a lot of work for different customers and there are some specific customisations you like to make then you can keep a 'base' or 'master' VM with just those and whenever you need to setup a new machine for a customer you can restore that backup as a starting point, tweak further as required then once happy migrate it to the customer...

Add new comment