VSC 2.0: bug with rapid cloning

[rubinsed1]

When I rapid clone from template, RCU places all vmdk's in a single location. for example:

template is setup as follows (for smvi)

vm config files: LUN: "datastore1"

vm vmdk1 file: LUN: "datastore1"

vm vmdk2 file: LUN: "datastore1swap" (independent persistent)

During cloning, I select advanced and ensure all files are kept on the same datastores listed above. final result:

vm config files: LUN: "datastore1"

vm vmdk1 file: LUN: "datastore1swap"

vm vmdk2 file: LUN: "datastore1swap"

If I do a regular deploy from template, the target clone is configured correctly (vmdks in the right location. Now I have to figure out a way to move vmdk1 back to datastore1, which renders the whole rapid cloning useless.

I guess one solution would be to remove the vmdk2 file from the original template, re-rapid-clone the template, and then individually add 5/10g independent vmdks to each vm for guest swap.

Anyone know why RCU works this way? is this intended?

-Ed

[costea]

This certainly looks like a bug.  If you tell RCU to place a VMDK in a certain datastore, we ought to do that.  Could you please open a case and send us the logs?

Thanks.

[darren_hedges]

Same problem happened to me.

It seems to put hard disc 1 on the wrong datastore even after ensuring the correct datastores are selected in the overview before telling it to proceed.

I ended up moving the pagefile back onto the same datastore for the template.  I will then just do a migrate between datastores for that vmdk once deployed.

Costea, I noticed a few other bugs too, where do we file bug reports as I haven't done one of them before.  Also, where do we keep track of the status of any we file?

[glowe]

Hi Darren--

    Typically, in order to get bugs filed with a product, you must first open a support case with Netapp Global Support.  Once you have a case open, the proper data will be collected and provided to the engineering team responsible for that product.

[rubinsed1]

Thanks. I'll go ahead and submit a ticket. Hopefully we can get this fixed.

-Ed