I've seen in past when webserver and CS MGMT on the same network, the download will fail - but that was due to explicit router and/or firewall settings. This may not apply to you since you at least get 1%, but I'm curious.
Try stopping the SSVM iptables firewall to see if this issue still persists. If your web server and CS MGMT host are on the same network, paste the output of "netstat -nr" From: CK [mailto:cloudw...@gmail.com] Sent: Friday, May 17, 2013 8:35 AM To: users@cloudstack.apache.org Cc: Musayev, Ilya Subject: Re: Template download stuck at 1% My SSVM interfaces are as follows...As a test I dropped eth1 and eth3 and the wget works - it doesn't stop - so it looks like a routing issue. I am not an networking expert, but are there any routing or iptable rules I need to put in place on the SSVM or the KVM host. I have am using the ACS quick install guide - I have my KVM host running on my management server (Centos 6.4). Any help is appreciated. eth0 Link encap:Ethernet HWaddr 0e:00:a9:fe:02:35 inet addr:169.254.2.53 Bcast:169.254.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:224 errors:0 dropped:0 overruns:0 frame:0 TX packets:138 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:18285 (17.8 KiB) TX bytes:34246 (33.4 KiB) eth1 Link encap:Ethernet HWaddr 06:9a:0a:00:00:0b inet addr:192.168.2.40 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15859 errors:0 dropped:0 overruns:0 frame:0 TX packets:16324 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2591611 (2.4 MiB) TX bytes:10644780 (10.1 MiB) eth2 Link encap:Ethernet HWaddr 06:ca:96:00:00:0c inet addr:192.168.2.50 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9765 errors:0 dropped:0 overruns:0 frame:0 TX packets:5734 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14660830 (13.9 MiB) TX bytes:376972 (368.1 KiB) eth3 Link encap:Ethernet HWaddr 06:8d:ae:00:00:06 inet addr:192.168.2.35 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:65 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4032 (3.9 KiB) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:18 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1236 (1.2 KiB) TX bytes:1236 (1.2 KiB) On 16 May 2013 04:21, Musayev, Ilya <imusa...@webmd.net<mailto:imusa...@webmd.net>> wrote: I would also check that MTU is properly set across the board and no packets are dropped on the switch or elsewhere. From: Musayev, Ilya Sent: Wednesday, May 15, 2013 10:02 PM To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org> Subject: Re: Template download stuck at 1% Stop firewall and see if it helps. -------- Original message -------- From: CK <cloudw...@gmail.com<mailto:cloudw...@gmail.com><mailto:cloudw...@gmail.com<mailto:cloudw...@gmail.com>>> Date: To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org><mailto:users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>> Subject: Re: Template download stuck at 1% Running wget to download a template as a test on the SSVM starts off fine and then after several seconds (10+) the download grinds down to 0Kb/s - the ETA starts to go up. Doing the same wget download from the MS host works fine the template is downloaded in full - no timeouts. Looking in the log I noticed this line: 2013-05-16 02:30:26,123 DEBUG [storage.download.DownloadListener] (Timer-6:null) Scheduling timeout at 30000 ms, template=CentOS 6.3 at host nfs://192.168.2.12/export/secondary<http://192.168.2.12/export/secondary> What is the storage.download.DownloadListener and what is the 30s timeout - could this be causing this issue? My iptables is as follows - does it look ok? *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -s 192.168.122.0/24<http://192.168.122.0/24> ! -d 192.168.122.0/24<http://192.168.122.0/24> -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24<http://192.168.122.0/24> ! -d 192.168.122.0/24<http://192.168.122.0/24> -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24<http://192.168.122.0/24> ! -d 192.168.122.0/24<http://192.168.122.0/24> -j MASQUERADE -A POSTROUTING -s 192.168.122.0/24<http://192.168.122.0/24> ! -d 192.168.122.0/24<http://192.168.122.0/24> -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24<http://192.168.122.0/24> ! -d 192.168.122.0/24<http://192.168.122.0/24> -j MASQUERADE -A POSTROUTING -s 192.168.122.0/24<http://192.168.122.0/24> ! -d 192.168.122.0/24<http://192.168.122.0/24> -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24<http://192.168.122.0/24> ! -d 192.168.122.0/24<http://192.168.122.0/24> -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24<http://192.168.122.0/24> ! -d 192.168.122.0/24<http://192.168.122.0/24> -j MASQUERADE COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill COMMIT *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -p tcp -m tcp --dport 9090 -j ACCEPT -A INPUT -p tcp -m tcp --dport 8250 -j ACCEPT -A INPUT -p tcp -m tcp --dport 7080 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 8096 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 1798 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 16509 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 5900:6100 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 49152:49216 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p udp -m state --state NEW -m udp --dport 111 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p tcp -m state --state NEW -m tcp --dport 32803 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p udp -m state --state NEW -m udp --dport 32769 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p tcp -m state --state NEW -m tcp --dport 892 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p udp -m state --state NEW -m udp --dport 892 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p tcp -m state --state NEW -m tcp --dport 875 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p udp -m state --state NEW -m udp --dport 875 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p tcp -m state --state NEW -m tcp --dport 662 -j ACCEPT -A INPUT -s 192.168.2.0/24<http://192.168.2.0/24> -p udp -m state --state NEW -m udp --dport 662 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -d 192.168.122.0/24<http://192.168.122.0/24> -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.122.0/24<http://192.168.122.0/24> -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -d 192.168.122.0/24<http://192.168.122.0/24> -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.122.0/24<http://192.168.122.0/24> -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -d 192.168.122.0/24<http://192.168.122.0/24> -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.122.0/24<http://192.168.122.0/24> -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable COMMIT Regards On 15 May 2013 15:30, Chip Childers <chip.child...@sungard.com<mailto:chip.child...@sungard.com><mailto:chip.child...@sungard.com<mailto:chip.child...@sungard.com>>> wrote: > On Wed, May 15, 2013 at 12:40:47AM +0100, CK wrote: > > Running a fresh install of ACS on Centos 6.4 with KVM as the host. Having > > setup a basic zone the CentOS 5.5(64-bit) no GUI (KVM) template is stuck > at > > 1% downloaded. > > > > I have run through the SSVM troubleshooting guide and everything appears > to > > be running fine on the SSVM - secstorage nfs mount, public access, etc. > > > > I tried: wget > > > http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2in > > the SSVM a couple of times and it starts saving the template, but each > > time is gets as far as around 7MB (eg.7,479,075, 7,173,935) = 1% it just > > stops downloading. > > This doesn't sound like a CloudStack issue exactly, but more like a > local connectivity problem (since wget is failing as well). Are you > having problems pulling the file down to your local machine? >
