Open Stack

Leandro, Brano,

I'm effectively migrating only the openstack installation, the DFM remains
the same. However, if I read Brano's email correctly, besides migrating the
information on openstack DB I also have to change metadata that DFM, is
that right?

Here's an example of a volume I have on Essex right now:

https://gist.github.com/fernandezpablo85/fd4340f0150bdf574bbb

And here's what DFM returns for that volume's LUN:

https://gist.github.com/fernandezpablo85/219f78545166f0c030b3

Is moving the data just from Essex db to Folsom safe in this case?



On Thu, Jul 4, 2013 at 12:08 PM, Leandro Reox <leandro.reox at gmail.com>wrote:

> Pablo,
>
> On folsom the block_device_mappings table its on novadb too, i totally
> miss the Brano's recommendation of uuid conversion and metadata, asumming
> that you hit the same dfm.
> We had to do that a couple of times, but generally as all our vms are
> stateless, we create them on the "new" cloud, and replicate the content,
> via sharding replicas or other mechanism, without intervention
>
> Saludos
>
>
> On Thu, Jul 4, 2013 at 11:27 AM, Brano Zarnovican <zarnovican at gmail.com>wrote:
>
>> On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
>> <fernandezpablo85 at gmail.com> wrote:
>> > Hi list!
>> >
>> > Any advice on this? Has somebody already tried it (and hopefully
>> succeeded).
>>
>> We did this migration "in-place". On day D, we dumped Essex
>> Openstack/DFM DB and restored in Folsom. I have created a patch for
>> Folsom Netapp driver to recognize Essex volumes/snapshots.
>>
>> I assume that both your clouds are hitting the same DFM. Otherwise,
>> you would have to migrate entries not only between Openstack DB, but
>> DFM DB, too. Would be painful..
>>
>> Folsom Netapp driver has added some meta-data to Openstack datasets
>> (in DFM), so Folsom will not recognize DFM datasets created in Essex
>> (and hence all Essex LUNs would be invisible). I have added that
>> meta-data manually with the attached script.
>>
>> Volume is identified by (host, provider_location). Host is the one
>> running nova-volume, provider_location is an object id in DFM db.. eg
>> ("mgmt-netapp.example.com", 7574).
>>
>> So if you are using the same DFM, provider_location won't change, but
>> you host probably would.
>>
>> Problem would be that you need to migrate id from decimal to UUIDs. In
>> my case, this was done in Openstack DB as part of that in-place
>> migration. The mapping is stored in new table "volume_id_mappings".
>> Same comments apply also to snapshots. However, because of this UUID
>> change, volumes names (LUNs on Netapp) are expected in different
>> format.
>>
>> Essex:
>> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-000009a4/vol-000009a4
>> Folsom:
>>
>> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e
>>
>> That was the reason for driver patch, so I did not have to rename
>> existing LUNs on Netapp and DFM.
>>
>> It's almost easier to create all volumes in Folsom and dd the content ;-)
>>
>> Regards,
>>
>> BranoZ
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130704/d6bb1428/attachment.html>