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 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>> Date: To: 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 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 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 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 -p udp -m state --state NEW -m udp --dport 111 -j ACCEPT -A INPUT -s 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 -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT -A INPUT -s 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 -p udp -m state --state NEW -m udp --dport 32769 -j ACCEPT -A INPUT -s 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 -p udp -m state --state NEW -m udp --dport 892 -j ACCEPT -A INPUT -s 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 -p udp -m state --state NEW -m udp --dport 875 -j ACCEPT -A INPUT -s 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 -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 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 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 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 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 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 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>> 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? >
