You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by CK <cl...@gmail.com> on 2013/05/15 01:40:47 UTC

Template download stuck at 1%

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.

Here is an extract of the systemvm.log on SSVM :
2013-05-14 23:39:16,722 DEBUG [cloud.agent.Agent] (UgentTask-5:) Sending
ping: Seq 4-43:  { Cmd , MgmtId: -1, via: 4, Ver: v1, Flags: 11,
[{"PingStorageCommand":{"changes":{},"hostType":"Storage","hostId":4,"wait":0}}]
}
2013-05-14 23:39:16,764 DEBUG [cloud.agent.Agent] (Agent-Handler-5:)
Received response: Seq 4-43:  { Ans: , MgmtId: 279278805450810, via: 4,
Ver: v1, Flags: 100010,
[{"PingAnswer":{"_command":{"hostType":"Storage","hostId":4,"wait":0},"result":true,"wait":0}}]
}
2013-05-14 23:39:24,275 DEBUG [cloud.agent.Agent] (agentRequest-Handler-5:)
Request:Seq 4-1002701101:  { Cmd , MgmtId: 279278805450810, via: 4, Ver:
v1, Flags: 100011,
[{"storage.DownloadProgressCommand":{"jobId":"5b01ccd2-5139-48db-8e67-1fcd7b04d234","request":"GET_STATUS","hvm":false,"description":"CentOS
5.5(64-bit) no GUI
(KVM)","checksum":"ed0e788280ff2912ea40f7f91ca7a249","maxDownloadSizeInBytes":53687091200,"id":4,"resourceType":"TEMPLATE","url":"
http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2
","format":"QCOW2","accountId":1,"name":"centos55-x86_64","secUrl":"nfs://
192.168.2.22/export/secondary","wait":0}}] }
2013-05-14 23:39:24,275 DEBUG [cloud.agent.Agent] (agentRequest-Handler-5:)
Processing command: com.cloud.agent.api.storage.DownloadProgressCommand
2013-05-14 23:39:24,275 DEBUG [cloud.agent.Agent] (agentRequest-Handler-5:)
Seq 4-1002701101:  { Ans: , MgmtId: 279278805450810, via: 4, Ver: v1,
Flags: 10,
[{"storage.DownloadAnswer":{"jobId":"5b01ccd2-5139-48db-8e67-1fcd7b04d234","downloadPct":1,"errorString":"
","downloadStatus":"DOWNLOAD_IN_PROGRESS","downloadPath":"/mnt/SecStorage/9cf54ebb-4221-35ee-97ce-3ff3348c0e02/template/tmpl/1/4/dnld3836401611117167093tmp_","templateSize":0,"templatePhySicalSize":0,"checkSum":"ed0e788280ff2912ea40f7f91ca7a249","result":false,"details":"
","wait":0}}] }
2013-05-14 23:39:34,361 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:)
Request:Seq 4-1002701102:  { Cmd , MgmtId: 279278805450810, via: 4, Ver:
v1, Flags: 100011,
[{"storage.DownloadProgressCommand":{"jobId":"5b01ccd2-5139-48db-8e67-1fcd7b04d234","request":"GET_STATUS","hvm":false,"description":"CentOS
5.5(64-bit) no GUI
(KVM)","checksum":"ed0e788280ff2912ea40f7f91ca7a249","maxDownloadSizeInBytes":53687091200,"id":4,"resourceType":"TEMPLATE","url":"
http://download.cloud.com/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2
","format":"QCOW2","accountId":1,"name":"centos55-x86_64","secUrl":"nfs://
192.168.2.22/export/secondary","wait":0}}] }
2013-05-14 23:39:34,361 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:)
Processing command: com.cloud.agent.api.storage.DownloadProgressCommand
2013-05-14 23:39:34,362 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:)
Seq 4-1002701102:  { Ans: , MgmtId: 279278805450810, via: 4, Ver: v1,
Flags: 10,
[{"storage.DownloadAnswer":{"jobId":"5b01ccd2-5139-48db-8e67-1fcd7b04d234","downloadPct":1,"errorString":"
","downloadStatus":"DOWNLOAD_IN_PROGRESS","downloadPath":"/mnt/SecStorage/9cf54ebb-4221-35ee-97ce-3ff3348c0e02/template/tmpl/1/4/dnld3836401611117167093tmp_","templateSize":0,"templatePhySicalSize":0,"checkSum":"ed0e788280ff2912ea40f7f91ca7a249","result":false,"details":"
","wait":0}}] }


Any idea why it is stopping and not fully downloading the template?

Regards

Re: Template download stuck at 1%

Posted by CK <cl...@gmail.com>.
Netstat output below.

Btw I have come across a thread that had the same problem I am having:
http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201206.mbox/%3CF992DC73CB61244FA00BF67DD648CAF0D479253849@LONPMAILBOX01.citrite.net%3E
Following this thread I change the routing order so eth2 was first and the
wget directly on the SSVM works! I then rebooted the SSVM and the Template
download on the CS MGMT started this time it got 38% and stopped. I have
checked the SSVM and wget works fine so is there anything on the CS MGMT
that needs tweaking as well?

On SSVM:
root@s-4-VM:~# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0
eth2
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0
eth3
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0
eth1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0
eth0
0.0.0.0         192.168.2.1     0.0.0.0         UG        0 0          0
eth2

On CS MGMT Host:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0
cloudbr0
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0
virbr0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0
cloud0
0.0.0.0         192.168.2.1     0.0.0.0         UG        0 0          0
cloudbr0




On 17 May 2013 19:31, Musayev, Ilya <im...@webmd.net> wrote:

>  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:cloudwizz@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 <im...@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
> Subject: Re: Template download stuck at 1%****
>
> Stop firewall and see if it helps.
>
>
> -------- Original message --------****
>
> From: CK <cl...@gmail.com>>
> Date:
> To: users@cloudstack.apache.org<ma...@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.childers@sungard.com<mailto:
> chip.childers@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?
> >****
>
> ** **
>

RE: Template download stuck at 1%

Posted by "Musayev, Ilya" <im...@webmd.net>.
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:cloudwizz@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 <im...@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<ma...@cloudstack.apache.org>
Subject: Re: Template download stuck at 1%
Stop firewall and see if it helps.


-------- Original message --------
From: CK <cl...@gmail.com>>>
Date:
To: users@cloudstack.apache.org<ma...@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 <ch...@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?
>


Re: Template download stuck at 1%

Posted by CK <cl...@gmail.com>.
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 <im...@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
> Subject: Re: Template download stuck at 1%
>
> Stop firewall and see if it helps.
>
>
> -------- Original message --------
> From: CK <cl...@gmail.com>>
> Date:
> To: users@cloudstack.apache.org<ma...@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.childers@sungard.com<mailto:
> chip.childers@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?
> >
>

RE: Template download stuck at 1%

Posted by "Musayev, Ilya" <im...@webmd.net>.
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 <cl...@gmail.com>>
Date:
To: users@cloudstack.apache.org<ma...@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 <ch...@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?
>

Re: Template download stuck at 1%

Posted by "Musayev, Ilya" <im...@webmd.net>.
Stop firewall and see if it helps.


-------- Original message --------
From: CK <cl...@gmail.com>
Date:
To: 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 <ch...@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?
>

Re: Template download stuck at 1%

Posted by CK <cl...@gmail.com>.
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 <ch...@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?
>

Re: Template download stuck at 1%

Posted by Chip Childers <ch...@sungard.com>.
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?