Gandi Kitchen

Home > Hosting > Storage Migration

Storage Migration

On the French side, an inevitable migration was required in order to arrive at a standardised platform to utilise the new functionalities.  Here, however, the problem is different and a little more complicated, with the coexistence of two different storage solutions.  In reality, we were confronted with a number of challenges so that the machines hosting the servers could happily play ball with two different storage platforms at the same time.  The opening of our US datacenter was already a few months ago, and so a large proportion of our efforts have been dedicated to this migration.  This is, of course, proceeding and certainly takes [a lot of] time, and will soon be available to all of our customers.  We will thus be in a position to run the two storage platforms together in order to perform the migrations efficiently.

Once active, all new disk creations will take place on the new storage platform.  At this point we will enter the migration phase, and specifically the phase which directly impacts you since it also means the migration of your disks.

There are a number of ways to perform the migration:

  • Create a new disk:

The creation of this new disk will be on the new platform.

Next, simply attach this new disk to your server and copy the relevant data to the new disk.  This would be a good occasion to do some housekeeping and get rid of any old data that you no longer need.  Such commands as 'cp' or 'rsync' would do the job nicely.

  • Create a new disk from the image of an existing one:

This function has been available through the API for several months:  disk.create_from(apikey, disk_spec, src_disk_id) -- see the API documentation for more details at

The next Gandi Website update will include the ability to create a new disk from and existing one to make life easier for you if you are not a user of our API.  This method, nevertheless, requires either that the server that has the original disk attached be stopped, or that the disk be detached from the server.

Please note that the time take to make the copy will be directly dependent upon the size of the disk, so you should have some patience and/or a good coffee break, if you decide to employ this method on a comparatively large disk.

If the new disk is to be a system disk, then you will need to define the disk as a boot-disk either via the web interface ("Boot Disk" in the server details) or using the API :  vm.disk_attach(apikey, vm_id, disk_id {'position' : 0} )  ( see )

This migration will enable you, among other things, to make use of the new storage features such as snapshots, resizing, and rapid-copy, which will be available in the coming weeks.  Aside from the platform which is seeing new features every month, we hope to soon be able to talk to you about these new functions which may change the way you use your servers.