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
