Open Stack

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/bcf28497/attachment.html>