Rick, Thanks for your response. I make another testing to upload my iso to my ESXi host directly, the speed is much faster now, avg is more than 40 MB/s. By the way, 200.21.0.99 is my vcenter server.
I will keep you update if I have some new found. Thanks a lot. Best Regards -- Ray On Thu, Jan 9, 2014 at 1:09 AM, Rick Jones <rick.jon...@hp.com> wrote: > On 01/07/2014 06:30 PM, Ray Sun wrote: > >> Stackers, >> I tried to create a new VM using the driver VMwareVCDriver, but I found >> it's very slow when I try to create a new VM, for example, 7GB Windows >> Image spent 3 hours. >> >> Then I tried to use curl to upload a iso to vcenter directly. >> >> curl -H "Expect:" -v --insecure --upload-file >> windows2012_server_cn_x64.iso >> "https://administrator:root123.@200.21.0.99/folder/ >> iso/windows2012_server_cn_x64.iso?dcPath=dataCenter&dsName=datastore2" >> >> The average speed is 0.8 MB/s. >> >> Finally, I tried to use vSpere web client to upload it, it's only 250 >> KB/s. >> >> I am not sure if there any special configurations for web interface for >> vcenter. Please help. >> > > I'm not fully versed in the plumbing, but while you are pushing via curl > to 200.21.0.99 you might check the netstat statistics at the sending side, > say once a minute, and see what the TCP retransmission rate happens to be. > If 200.21.0.99 has to push the bits to somewhere else you should follow > that trail back to the point of origin, checking statistics on each node as > you go. > > You could, additionally, try running the likes of netperf (or iperf, but I > have a natural inclination to suggest netperf...) between the same pairs of > systems. If netperf gets significantly better performance then you > (probably) have an issue at the application layer rather than in the > networking. > > Depending on how things go with those, it may be desirable to get a packet > trace of the upload via the likes of tcpdump. It will be very much > desirable to start the packet trace before the upload so you can capture > the TCP connection establishment packets (aka the TCP SYNchronize segments) > as those contain some important pieces of information about the > capabilities of the connection. > > rick jones > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
