openstack team mailing list archive

[pablo fernandez <fernandezpablo85@xxxxxxxxx>]

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
<fernandezpablo85@xxxxxxxxx>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.reox@xxxxxxxxx>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@xxxxxxxxx>wrote:
>>
>>> On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
>>> <fernandezpablo85@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>