Okay we have been allowed to purchase ESX Foundation as a test project for proof of concept before investing more into the Enterprise edition. As such we are stuck with using the simple single host VI Client and not virtual center at this time. What I would to do is create an NFS share on FreeNAS which I have done, to store the ISO's as well as OS Images. I was previously uploading the ISO's to the ESX host through the browse data store manager utility and I can install an OS by using an ISO shared on the NFS share. What I am looking for is the easiest method to do the following:
1) Create an OS image on the ESX host and then store that template image on the NFS share instead of taking up space on the esx host. If we want to make a VM based on that image I will make a copy of it from the NAS back over to the ESX server and rename it approrpriately.
I know virtual center can do all this with much more ease and functionality but we cannot bring it in to our environment yet so I have to make due a different way.
Thoughts on the easiest way to accomplish this?
**EDIT **
I found that i can copy a VM folder from the one datastore to the other using the datastore browser. HOWEVER its taking about 1:45 to copy 10gb?? This is across a 1gb switch, 1gb cards and ca5e cables. This should take about 5 MAYBE 10 minutes. Is this to be expected? I know I have heard about slow copy performance from the console or something but I cant believe it should be this slow in this scenario?! MTU is still 1500 but I cant see needing to run jumbo frames in this case.
I've experinced the same thing. I was using freenas in my case although i think i had problems using nfs with openfiler as well if my memory serves me correctly. It has to do with the implemenation of nfs on the hosts as some of the san vendors supplying nfs as an option for connectivity have no problems with performance or reliability.
I have done this from the command line for both NFS and VMDK datastores. Generally, if I want to copy a "template" VM w/o VirtualCenter, I go through the process of creating a new VM through the VIC, then replace the VMDK file it creates with a copy of the VMDK from my "template" using vmkfstools:
If my new VM is /vmfs/volumes/MY_datastore/myNewVM, and my template is /vmfs/volumes/NFS_datastore/myTemplateVM
#remove the vmdk that was created during VM creation
rm /vmfs/volumes/MY_datastore/myNewVM/myNewVM.vmdk
#copy the template VMDK to the new VM
vmkfstools -i /vmfs/volumes/NFS_datastore/myTemplateVM/myTemplateVM.vmdk /vmfs/volumes/MY_datastore/myNewVM/myNewVM.vmdk
This generally takes a minimal amount of time -- depending on the size of the VMDKs, of course -- and seems to be a clean way to do it.
Thanks for the suggestion Doug, I will give that a try. I find the datastore browser is a nice easy way to do it but the slow performance makes/made it impossible. That brings me to my second thing.
Did some reading and I found many others were experiencing pathetically slow transfer performance with NFS as well. Well I tried setting up and using iSCSI. Low and behold a night and day difference. Needless to say I will be concentrating on using an iscsi target for storage.
I would just like to confirm that iscsi is now officially supported in the Foundation edition as well as standard and enterprise? I know it didnt use to be.
Thanks
I'm wondering if this is more of an issue with the NFS target vs. the ESX implementation... but it is interesting to hear.
As for Foundation, my information shows that it differs from the old Starter in the following:
1. No CPU, RAM, or storage restrictions
2. Virtual SMP
3. VCB
4. VMware Update Manager
5. Choice of ESX Server 3 or 3i
So, I'd say you are cool to go with iSCSI
I've experinced the same thing. I was using freenas in my case although i think i had problems using nfs with openfiler as well if my memory serves me correctly. It has to do with the implemenation of nfs on the hosts as some of the san vendors supplying nfs as an option for connectivity have no problems with performance or reliability.
Thanks for the feedback and information guys.