Infrastructure Software

Hi Gianluca,

since OVS can't live migrate guests between different storage repos anyway, you could setup the new storage repo on the NetApp filer and have OVS perform the migration for you. You will have to schedule a maintenance downtime anyway, regardless on how you're approaching this issue. What you won't be able to do it to somewhat copy/dd the entire LUN over from the IBM SAN to the NetApp SAN.

Cheers,

budy

The problem is about PoolFS.

I already configured a new VM repository form my VMs on Netapp and almost migrated all VMs with shutdown/clone.

During migration I will release ownership of this new VM repository (already on Netapp) and do the destroy server pool step and then the take ownership step in the new phase

The problem is that when re-creating the PoolFS I should use a physical disk that is the clone of the original one, so that all the setting of the old server pool will be preserved (and the nw server pool has to be named the same as the old).

The problem is the correct way to clone this 100Gb LUN from IBM to Netapp SAN when all Oracle VM is placed down

Hope I have clarified

Gianluca

HI Gianluca,

sorry, but that won't work. You will have to move your OVS manually from one server pool to the other. Even if you managed to clone the contents of the LUN itself, you can't clone it's SCSI-ID, which will remain different, since it's part of the LUN and not the contents of the LUN. OVMM will not recognize - and your OVS won't either, the new LUN as being the same volume as the old one.

You can start messing around with that, but you will have to schedule a downtime anyway, so why bother? There is a way to force OVMM, but that will involve to mess with the OCFS2 file system on the poolfs. You want to serach this forum for the posts dealing with HA and DR scenarios. I remember, that this had been discussed way back and that there are even some kind of walk throughs for that.  However, the way I did that last time, went something like this:

• stop all running guests
• move all guests from their servers to the resp. repo
• unpresent repo from all OVS
• move all OVS to new server pool
• present repo(s) on OVS
• move all guests back to their designated OVS
• start up the guests again

As for the moving, you can use ovmcli to script that, which makes it quite comfortable and fast, too.

Cheers,

budy

I successfully followed what detailed in the pdf article attached to doc id 1919855.1, with small differences to adapt to my situation and needs

I could tolerate several small downtime for VMs (many of them in app HA) and then a total downtime on Sunday (this last one took 3 hours; see later)

The initial situation had a total of 4 luns: 2 luns used as physical disks attached to 2 distinct VMs (for Oracle ASM datafiles); 1 lun used as vm repository; 1 100Gb lun used for poolFS

The first part of the job was to give access to both storage arrays (IBM and Netapp) through SAN and do a rescan. This was hot done.

Then I created a new Netapp based VM repository.

Then one by one, by steps in several days, I began to shutdown and clone VMs transferring their storage to the Netapp based repository.

I preferred this way to take anyway a copy on the old storage, just for fast rollback in case of needs.

I also hot attached the 2 new Netapp physical disks to the 2 VMs and hot move ASM storage without giving downtime.

The final total downtime took 3 hours: it comprised activity of cloning of disks of a production VM I could not stop before (350Gb of storage) and the copy through dd executed on one Oracle VM server, to clone the 100Gb poolFS lun when in the step it was dismounted.

It would be nice to have live storage vmotion in Oracle VM, not only for local based storage..

At the end I created the new server pool using the copied Netapp Lun for the pool FS and then took ownership of the Netapp Vm repository and the other described steps.

Finally I deleted the old 4 IBM luns from Oracle VM Manager, so that I don't see them as multipath device now and today they should also be unpresented at SAN level.

All went good.

As test bed I used an Intel nuc6i7kyk box with Fedora 29, where I used virt-manager to configure 4 qemu/kvm based VMs:

- Oracle VM Manager

- Oracle VM Server

- Oracle VM Server

- VM with CentOS, used as software target iSCSI with targetcli

This last step necessary as I didn't find a way to use shared scsi of the VMs to use a sort of SAN in Oracle VM.

So to simulate the block based SAN I decided to use iSCSI.

I didn't find a way to simulate a SAN....

All the poolFS migration steps were executed on this nested virtualized environment to acquire a sort of confidence and verify all was ok.

Only differences:

- version in the nested env was 3.4.5 instead of the production 3.4.4 because of problems with Oracle VM Servers boot in Qemu/kvm (see  How to test Oracle Vm on qemu-kvm  ) and that the SAN was an ISCSI based one instead of FC-SAN one.

HIH, in case any other needs something similar

Gianluca