2013-01-03 04:53 AM
First of all, happy new year!
I said the problem in my subject, but I will try to provide as much info as I can about it.
It's been 2-3 weeks that I'm working on my lab and it was time to add the NetApp simulator. I installed the simulator and the first thing I noticed is that I couldn't access the http://<ip-simulator>/na_admin , I reinstalled it, but again it didn't work, so I decided to keep going and add the licences that I found on another post here, I added NFS and iSCSI licences from latter version and it recognized the licences. So that's the only reason I ended with to explain why it's taking so long to do a storage vMotion. Since I am not sure that this is actually the reason I decided to post here to get some ideas.
About the environment:
Since I have an isolated network, every NIC is host-only, I created a W7 machine to connect to my ESXi hosts and to use OnCommand.
Since this is for lab only, I added everything within the same subnet, all the machines, ESX hosts, SAN, etc (192.168.0.*) the gateway is 192.168.0.254 (but there isn't a machine there yet, I hope that this is not the problem aswell). This is a screenshot with more info:
* The forest I'm using has my company name so I blurred it
** This was like the 10th time I was trying to the storage vMotion from the local datastore of the hostA to an iSCSI datastore from VSIM. As you can see I mapped the lun from NetApp and then added it through vCenter, this was OK.
My VSIM has 28 4G SATA disks (type 33) and 28 4G FC disks (type 31). The FC aggregate has 28 disks with RaidDP without spare and the SATA aggregate has 28 disks with RaidDP with one spare. The root vol is on SATA (aggr0) and the mapped lun used in the vMotion is on the FC disks (aggr1).
This is config from the VSIM (I increased the memomry, because I thought that this might be the problem)
The machine I am using is a MSI notebook, i7, 16GB RAM. It also has 230GB free on HD.
Any suggestion is appreciated,
2013-01-03 07:55 AM
Hi Fabio and welcome to the Community!
Storage vMotion is a rather heavy operation & takes a while even when using a 'real' filer - if the VM in question is large, this may be actually normal behaviour.
2013-01-03 11:02 AM
Hello Radek, thanks!
The VM is from vCloud Director and has 8GB of used storage space. The storage vMotion took almost 5 hours and a half to complete (not to mention the many other attempts it's failed):
I was thinking about what you have said and indeed it is a intensive operation that may take a while, specially because the vMotion is happening from a datastore of a VM inside an emulated ESXi that is residing in my workstation on top of my laptop, but still 5 hours is too much, ain't it?
2013-02-17 03:31 AM
The sim has around 250GB of storage provisioned but fresh out of the box the sim is only using about 200MB. Netapp ships the sim with preallocated (thick) disks, convert them to thin and storage vmotion will go a lot faster and you will waste less storage.
To solve first convert the sim's disk files (there are four vmdk files) to thin single extent vmdks (http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=2036572&sliceId=1&docTypeID=DT_KB_1_1&dialogID=448358018&stateId=1%200%...). Next, storage vMotion the sim either to the same or different data store (this will take a long time). Once complete storage vMotions will take a lot less time because the ESXi server will only need to send the "real" data across the network verses the data plus a whole bunch of zeros.
If you use sims a lot for testing do this process once then make the sim a template and clone it.