On Thu, Jul 4, 2013 at 6:16 PM, pablo fernandez
wrote:
> Leandro, Brano,
I wrote the previous mail in a hurry.. I hope this one might clarify it a bit
1) DFM dataset metadata
Folsom driver is using DFM to store Project id (tenant) together with
the volume. Essex driver did not do that, so his v
Cool, thanks one more time Lean and Brano, you guys rock.
On Thu, Jul 4, 2013 at 2:26 PM, Leandro Reox 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 tab
Yep thats right pablo !
On Thu, Jul 4, 2013 at 2:02 PM, pablo fernandez
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 d
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 p
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
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
On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
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
Hey Lean,
Thanks a ton, I would have totally missed the block_device_mapping table
(because on Folsom it lives on the nova db, not cinder's).
Seems you guys already did this stuff? or something similar?
Pablo
On Thu, Jul 4, 2013 at 9:57 AM, Leandro Reox wrote:
> Pablo,
>
> All the logic for
Pablo,
All the logic for device mappings its on the database, so be sure to
replicate (carefull no to overlap volumes id) all your volume data from the
table :
- volumes
- volumes metadata
An the most important one:
- block_device_mappings
On this tables is where actually resides the conection
Hi list!
I'm working on a company that has 2 openstack clouds, an essex installation
and a folsom one. I'm trying to migrate a netApp volume from one to the
other, checking the required fields in the database to copy the metadata.
Obviously both volumes would be detached.
Any advice on this? Has
10 matches
Mail list logo
