<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Guys,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">

I also found that the blocking_device_mapping table only contains entries for the volumes that are "in-use".</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">

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?</div>

<div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Thank you! </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Thu, Jul 4, 2013 at 1:16 PM, pablo fernandez <span dir="ltr"><<a href="mailto:fernandezpablo85@gmail.com" target="_blank">fernandezpablo85@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Leandro, Brano,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">


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?</div>


<div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Here's an example of a volume I have on Essex right now:</div><div class="gmail_default" style="font-family:verdana,sans-serif">


<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><a href="https://gist.github.com/fernandezpablo85/fd4340f0150bdf574bbb" target="_blank">https://gist.github.com/fernandezpablo85/fd4340f0150bdf574bbb</a><br>

</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">And here's what DFM returns for that volume's LUN:</div><div class="gmail_default" style="font-family:verdana,sans-serif">


<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><a href="https://gist.github.com/fernandezpablo85/219f78545166f0c030b3" target="_blank">https://gist.github.com/fernandezpablo85/219f78545166f0c030b3</a><br>

</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Is moving the data just from Essex db to Folsom safe in this case?</div><div class="gmail_default" style="font-family:verdana,sans-serif">


 </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 4, 2013 at 12:08 PM, Leandro Reox <span dir="ltr"><<a href="mailto:leandro.reox@gmail.com" target="_blank">leandro.reox@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Pablo, <br><br>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.<div>


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<br>
<br>Saludos</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Thu, Jul 4, 2013 at 11:27 AM, Brano Zarnovican <span dir="ltr"><<a href="mailto:zarnovican@gmail.com" target="_blank">zarnovican@gmail.com</a>></span> wrote:<br>



</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez<br>
<<a href="mailto:fernandezpablo85@gmail.com" target="_blank">fernandezpablo85@gmail.com</a>> wrote:<br>
> Hi list!<br>
><br>
<div>> Any advice on this? Has somebody already tried it (and hopefully succeeded).<br>
<br>
</div>We did this migration "in-place". On day D, we dumped Essex<br>
Openstack/DFM DB and restored in Folsom. I have created a patch for<br>
Folsom Netapp driver to recognize Essex volumes/snapshots.<br>
<br>
I assume that both your clouds are hitting the same DFM. Otherwise,<br>
you would have to migrate entries not only between Openstack DB, but<br>
DFM DB, too. Would be painful..<br>
<br>
Folsom Netapp driver has added some meta-data to Openstack datasets<br>
(in DFM), so Folsom will not recognize DFM datasets created in Essex<br>
(and hence all Essex LUNs would be invisible). I have added that<br>
meta-data manually with the attached script.<br>
<br>
Volume is identified by (host, provider_location). Host is the one<br>
running nova-volume, provider_location is an object id in DFM db.. eg<br>
("<a href="http://mgmt-netapp.example.com" target="_blank">mgmt-netapp.example.com</a>", 7574).<br>
<br>
So if you are using the same DFM, provider_location won't change, but<br>
you host probably would.<br>
<br>
Problem would be that you need to migrate id from decimal to UUIDs. In<br>
my case, this was done in Openstack DB as part of that in-place<br>
migration. The mapping is stored in new table "volume_id_mappings".<br>
Same comments apply also to snapshots. However, because of this UUID<br>
change, volumes names (LUNs on Netapp) are expected in different<br>
format.<br>
<br>
Essex:<br>
/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-000009a4/vol-000009a4<br>
Folsom:<br>
/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e<br>
<br>
That was the reason for driver patch, so I did not have to rename<br>
existing LUNs on Netapp and DFM.<br>
<br>
It's almost easier to create all volumes in Folsom and dd the content ;-)<br>
<br>
Regards,<br>
<br>
BranoZ<br>
<br></div></div><div>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>