Cool, thanks one more time Lean and Brano, you guys rock.

On Thu, Jul 4, 2013 at 2:26 PM, Leandro Reox <leandro.r...@gmail.com> wrote:

> Yep thats right pablo !
>
>
> On Thu, Jul 4, 2013 at 2:02 PM, pablo fernandez <
> fernandezpabl...@gmail.com> wrote:
>
>> Guys,
>>
>> I also found that the blocking_device_mapping table only contains entries
>> for the volumes that are "in-use".
>>
>> Since we're planning a less transparent cloud migration, with detached
>> volumes seems I don't have to copy this information. The only change needed
>> is to copy the volumes_* info and perform the id translation in between
>> (from ints to UUIDs). Am I right?
>>
>> Thank you!
>>
>>
>> On Thu, Jul 4, 2013 at 1:16 PM, pablo fernandez <
>> fernandezpabl...@gmail.com> wrote:
>>
>>> 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.r...@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 <zarnovi...@gmail.com
>>>> > wrote:
>>>>
>>>>> On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
>>>>> <fernandezpabl...@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@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to