Data Backup and Recovery

VIBE plug-in failing to identify VMFS LUN.

parrizas
4,034 Views

Hello,

We are trying to backup a DB2 database inside a VM over a VMFS datastores. We are using VIBE plug-in + DB2 plug-in.

VM is using two datastores over two iSCSI LUNs with LUN IDs 101 and 102.

SnapCreator is version 3.6p1

We get the following error when VIBE tries to identify the NetApp LUNs for the VMFS datastores:

[Mon Oct 15 12:54:51 2012] DEBUG: Parsing list of VMs for list of datastore names ...

[Mon Oct 15 12:54:51 2012] DEBUG: VM DB2-CentOS.6.2 stored on datastore DB2.ISCSI.FDEMO6.LUNID.101 ...

[Mon Oct 15 12:54:51 2012] DEBUG: VM DB2-CentOS.6.2 also stored on datastore DB2.ISCSI.FDEMO6.LUNID.102, creating new entry ...

[Mon Oct 15 12:54:51 2012] DEBUG: Searching for Datastore DB2.ISCSI.FDEMO6.LUNID.101 ...

[Mon Oct 15 12:54:51 2012] DEBUG: Requested Datastore (DB2.ISCSI.FDEMO6.LUNID.101) is available.

[Mon Oct 15 12:54:51 2012] DEBUG: Collecting LUN information ...

[Mon Oct 15 12:54:51 2012] DEBUG: Already collected LUN serial numbers for storage controller/vserver 10.68.49.206 ...

[Mon Oct 15 12:54:51 2012] DEBUG: Searching for matching disk name naa.60a9800043346472534a6d78412d2d77 ...

[Mon Oct 15 12:54:52 2012] DEBUG: Checking host system 10.68.49.22 ...

[Mon Oct 15 12:54:52 2012] DEBUG: Name = naa.60a9800043346472534a6e314a427339, UUID = 43346472534a6e314a427339.

[Mon Oct 15 12:54:52 2012] DEBUG: Name = naa.60a9800043346472534a6d78412d2d77, UUID = 43346472534a6d78412d2d77.

[Mon Oct 15 12:54:52 2012] DEBUG: Found LUN with UUID 43346472534a6d78412d2d77, host 10.68.49.206, path /vol/SAN_DB2_PRO_DATOS_N/SAN_DB2_PRO_DATOS_N_01/SAN_DB2_PRO_DATOS_N_01.LUN.

[Mon Oct 15 12:54:52 2012] INFO: Collecting VM information on VMFS Datastore DB2.ISCSI.FDEMO6.LUNID.101.

[Mon Oct 15 12:54:52 2012] DEBUG: Searching for Datastore DB2.ISCSI.FDEMO6.LUNID.102 ...

[Mon Oct 15 12:54:53 2012] DEBUG: Requested Datastore (DB2.ISCSI.FDEMO6.LUNID.102) is available.

[Mon Oct 15 12:54:53 2012] DEBUG: Searching for matching disk name naa.60a9800043346472534a6e31505a7561 ...

[Mon Oct 15 12:54:54 2012] DEBUG: Checking host system 10.68.49.21 ...

[Mon Oct 15 12:54:54 2012] DEBUG: Name = naa.60a9800043346472534a6e314a427339, UUID = 43346472534a6e314a427339.

[Mon Oct 15 12:54:54 2012] DEBUG: Name = naa.60a9800043346472534a6d78412d2d77, UUID = 43346472534a6d78412d2d77.

[Mon Oct 15 12:54:54 2012] DEBUG: Name = naa.60a9800043346472534a6e31505a7561, UUID = 43346472534a6e31505a7561.

[Mon Oct 15 12:54:54 2012] ERROR: [vmw-00006] Could not find identifying LUN on any storage controller/vserver for VMFS datastore!

We read the following thread https://communities.netapp.com/thread/15918 where a similar error is described, but the fix was not really clear for us...

Thanks a lot for your help!

4 REPLIES 4

ktenzer
4,034 Views

Hi,

You have two ways you can do the backup

1) Mount DB2 database using RDMs or NFS and backup VM and DB2 database separate (this is the recommendation as it is more granular backup / restore for both and simplest to setup)

2) Backup DB2 database and VM together. For this the DB2 database must be installed in the VM partition itself. So if the VM has a C: drive you would install DB2 DB directly there.

What we dont support and what we know has issues is using virtual disks which is my guess to above problem. We also dont support backing up app + vm together when app is installed on separate disks RDMs, NFS, or virtual disks.

Regards,

Keith

parrizas
4,035 Views

Thanks Keith,

Would this feature (VM+App backup over several VMDKs) be supported in any future release?

We have a big customers with hundreds of DB2 deployments on VmWare and they are trying to move away from RDMs.

Regards,

Alfonso

ktenzer
4,035 Views

This is one of the biggest things we are looking at, supporting VMDKs and handling it not just for individual VMs but for VM + Apps

However this is very complex and difficult so that is why its taking so long but we are working on it.

I guess this was me trying to give you feeling for importance but cover my but from providing a commitment.

Still I would expect within the next year to see a lot happen in this area

For now I still think until the backup software supports VMDKs across stack it isnt a good idea to move away from RDMS as your backup and restore will be a nightmare.

Regards,

Keith

parrizas
4,035 Views

Thanks Keith, got it

We'll go with the RDM way....

Public