Re: Template Download - No route to host
If you can ping the peer public IP, but not the gateway IP (assuming your gateway IP is pingable - not blocked for pings) - then the issue is probably somewhere on the physical networking side. On that note, you should NOT modify absolutely anything inside the SSVM in order to get it to work. Your networking might be set in a wrong way - so please check your SSVM default routes - if it's pointing to your external public IP of your router which is connecting your public IP space to the external world (internet). If your routes are not correct, that means some ACS networking (physical, traffic types, labels, etc) issue which cased ACS to misconfigure SSVM. Best, On Thu, 13 May 2021 at 18:07, Hean Seng wrote: > You need someone understand network to help you on designing the network > for the Cloudstack , and some system knowledge to get this up and running. > > On Thu, May 13, 2021 at 11:12 PM Corey, Mike > wrote: > > > Hi, > > > > > > > > I’m not a Linux guy by trade so please forgive my ignorance. The default > > template is not downloading and I’m getting the “no route to host” from > ACS > > and inside my SSVM. The SSVM cannot ping it’s public IP gateway either. > > And obviously it can’t hit the web… > > > > > > > > root@s-2-VM:~# curl http://www.shapeblue.com > > > > curl: (7) Failed to connect to www.shapeblue.com port 80: No route to > host > > > > > > > > Google suggests I check the IPTABLES; however, as mentioned I’m not all > > that familiar with Linux family. I certainly don’t want to open up > > everything to the www. > > > > > > > > Default route is the public IP gateway as expected… default via > > dev eth2 > > > > > > > > SSVM can ping the public IP of the Console System VM. > > > > > > > > Should I even have to do anything with IPTables on the SSVM? My physical > > network is the same as I have on the previous 4.14 ACS lab on VMware and > > the same public ip scope. > > > > > > > > Many thanks! > > > > > > > > > > > > > > > > *Mike Corey* > > > > > > Technology Senior Consultant, IT CS CTW Operation & Virtualization > Service > > US > > > > > > *SAP AMERICA, INC.* 3999 West Chester Pike, Newtown Square, 19073 United > > States > > > > > > T +1 610 661 0905, M +1 484 274 2658, E mike.co...@sap.com > > > > > > > > > > > > > > > > > -- > Regards, > Hean Seng > -- Andrija Panić
Re: Template Download - No route to host
You need someone understand network to help you on designing the network for the Cloudstack , and some system knowledge to get this up and running. On Thu, May 13, 2021 at 11:12 PM Corey, Mike wrote: > Hi, > > > > I’m not a Linux guy by trade so please forgive my ignorance. The default > template is not downloading and I’m getting the “no route to host” from ACS > and inside my SSVM. The SSVM cannot ping it’s public IP gateway either. > And obviously it can’t hit the web… > > > > root@s-2-VM:~# curl http://www.shapeblue.com > > curl: (7) Failed to connect to www.shapeblue.com port 80: No route to host > > > > Google suggests I check the IPTABLES; however, as mentioned I’m not all > that familiar with Linux family. I certainly don’t want to open up > everything to the www. > > > > Default route is the public IP gateway as expected… default via > dev eth2 > > > > SSVM can ping the public IP of the Console System VM. > > > > Should I even have to do anything with IPTables on the SSVM? My physical > network is the same as I have on the previous 4.14 ACS lab on VMware and > the same public ip scope. > > > > Many thanks! > > > > > > > > *Mike Corey* > > > Technology Senior Consultant, IT CS CTW Operation & Virtualization Service > US > > > *SAP AMERICA, INC.* 3999 West Chester Pike, Newtown Square, 19073 United > States > > > T +1 610 661 0905, M +1 484 274 2658, E mike.co...@sap.com > > > > > > > -- Regards, Hean Seng
Re: Template - Download file size is too large
Nitin Mehta Nitin.Mehta@... writes: You can upload data volumes into CS and this config is used for defining the max size of the volume you can upload. Hi 1) So storage.max.volume.upload.size config is used for defining the max size of the volume that we can upload. Is this same for uploading template and ISO? 2) If not, max.template.iso.size config will define the max size of the template and ISO that we can upload? 3) What about storage.max.volume.size ? will this config play role while uploading volume, template and ISO? -Rahul
Re: Template - Download file size is too large
Hello Harikrishna, Thank you very much :) I would like to discuss one more question. Process of uploading volume, template and ISO will copy files to Secondary Storage. So what do you think about, what parameter may cause timeout before completion of process apart from network related issues? I do not think so. what do you say? -Rahul On Wed, Aug 20, 2014 at 2:28 PM, Harikrishna Patnala harikrishna.patn...@citrix.com wrote: Hi, answers inline. -Harikrishna On 20-Aug-2014, at 11:48 am, rahul cloudrahu...@gmail.com wrote: Nitin Mehta Nitin.Mehta@... writes: You can upload data volumes into CS and this config is used for defining the max size of the volume you can upload. Hi 1) So storage.max.volume.upload.size config is used for defining the max size of the volume that we can upload. Is this same for uploading template and ISO? No, this parameter is used only for volumes 2) If not, max.template.iso.size config will define the max size of the template and ISO that we can upload? Yes, this is used while registering template, copying template. 3) What about storage.max.volume.size ? will this config play role while uploading volume, template and ISO? No, this parameter is used while creating disk offering and creating virtual machine to check the disk size parameter value provided as a parameter. -Rahul
Re: Template - Download file size is too large
Looks like that resolved the issue. Thank you. Strange that the ISO setting would control a VHD registered as a template (and not an ISO). Thank you very much. - Bret On Sun, Jun 15, 2014 at 10:43 PM, Shweta Agarwal shweta.agar...@citrix.com wrote: I think its better if you change the value of max.template.iso.size (The maximum size for a downloaded template or ISO (in GB)) parameter . Its value is set to 50 by default. And then try to register your template. Thanks Shweta -Original Message- From: Bret Mette [mailto:bret.me...@dbihosting.com] Sent: Saturday, June 14, 2014 10:44 PM To: users@cloudstack.apache.org Subject: Template - Download file size is too large Hey Everyone, I keep getting this error when CloudStack attempts to download a template I have registered. The template file itself is 50GB and my storage.max.volume.upload.size is set to 500, which it states is in GBs according to the global settings. I have plenty of secondary and primary storage space (not that primary should matter in this case). Anyone else experienced this? How did you resolve it? The last time this happened it was during time crunch and I ended up doing everything (including the db entries) by hand. However, now that I have the time to resolve this properly I would like to do so (also doing it by hand again sound miserable). Thank you in advance - Bret
RE: template download
We can also restart management server which will trigger template sync . If there are any templates which are not in DOWNLOADED state MS will try to download them again. -Sanjeev -Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: Friday, June 13, 2014 4:28 PM To: users@cloudstack.apache.org Subject: Re: template download Sebastien, if stop-start does not work just (force) remove the SSVM, the ACS/HA thread will kick in and start new SSVM(s) which should work. Hope this helps. On Thu, Jun 12, 2014 at 2:32 PM, sebgoa run...@gmail.com wrote: Hi folks, If a template fails to download (network issues on ssvm) and I then fix my problems. how do I kick off a new attempt at downloading the template ? thanks -sebastien
Re: template download
Sebastien, if stop-start does not work just (force) remove the SSVM, the ACS/HA thread will kick in and start new SSVM(s) which should work. Hope this helps. On Thu, Jun 12, 2014 at 2:32 PM, sebgoa run...@gmail.com wrote: Hi folks, If a template fails to download (network issues on ssvm) and I then fix my problems. how do I kick off a new attempt at downloading the template ? thanks -sebastien
RE: template download
ssvm stop-start should help thanks prashant -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, June 12, 2014 2:32 PM To: users@cloudstack.apache.org Subject: template download Hi folks, If a template fails to download (network issues on ssvm) and I then fix my problems. how do I kick off a new attempt at downloading the template ? thanks -sebastien
Re: template download
Yeah, so I can answer myself to RTFW: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM,+templates,+Secondary+storage+troubleshooting Item #5 did it, on the ssvm: service cloud stop, service cloud start (fwiw the restart did not restart) then the download will re-kick. On Jun 12, 2014, at 11:15 AM, Prashant Kumar Mishra prashantkumar.mis...@citrix.com wrote: ssvm stop-start should help thanks prashant -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, June 12, 2014 2:32 PM To: users@cloudstack.apache.org Subject: template download Hi folks, If a template fails to download (network issues on ssvm) and I then fix my problems. how do I kick off a new attempt at downloading the template ? thanks -sebastien
Re: template download
which version of cloudstack are you using? I have a similar issue with cs4.3 On Thu, Jun 12, 2014 at 11:18 AM, sebgoa run...@gmail.com wrote: Yeah, so I can answer myself to RTFW: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM,+templates,+Secondary+storage+troubleshooting Item #5 did it, on the ssvm: service cloud stop, service cloud start (fwiw the restart did not restart) then the download will re-kick. On Jun 12, 2014, at 11:15 AM, Prashant Kumar Mishra prashantkumar.mis...@citrix.com wrote: ssvm stop-start should help thanks prashant -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, June 12, 2014 2:32 PM To: users@cloudstack.apache.org Subject: template download Hi folks, If a template fails to download (network issues on ssvm) and I then fix my problems. how do I kick off a new attempt at downloading the template ? thanks -sebastien -- Centralway Factory AG | Konstantinos Karampogias, DevOps | LinkedIn | + 41 44 578 40 00
Re: template download
I had a similar issue with cs4.3 were I pulled down the wrong version of the ssvm's. 4.2 versions instead of 4.3 versions. Even though I kept kicking off a re-download it never actually happened for me. Since this is just a test instance of cloudstack and I don't really care about the data I went extreme. This is what I did I disabled my zone. Destroyed systemvms and router Destroyed all templates Destroyed primary and secondary storage. rm -fr /secondary/* /primary/* Recreated primary and secondary storage Pulled down the Jenkins template with cloud-install-sys-tmplt and finally have full template. I don't think you will actually need to destroy the primary and secondary storage If you can just figure out what vdi's belong to the templates and system vms' and rm those. Since my was a new setup I did not care about the data and went extreme. On Thu, Jun 12, 2014 at 11:19 AM, Konstantinos Karampogias konstantinos.karampog...@centralway.com wrote: which version of cloudstack are you using? I have a similar issue with cs4.3 On Thu, Jun 12, 2014 at 11:18 AM, sebgoa run...@gmail.com wrote: Yeah, so I can answer myself to RTFW: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM,+templates,+Secondary+storage+troubleshooting Item #5 did it, on the ssvm: service cloud stop, service cloud start (fwiw the restart did not restart) then the download will re-kick. On Jun 12, 2014, at 11:15 AM, Prashant Kumar Mishra prashantkumar.mis...@citrix.com wrote: ssvm stop-start should help thanks prashant -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, June 12, 2014 2:32 PM To: users@cloudstack.apache.org Subject: template download Hi folks, If a template fails to download (network issues on ssvm) and I then fix my problems. how do I kick off a new attempt at downloading the template ? thanks -sebastien -- Centralway Factory AG | Konstantinos Karampogias, DevOps | LinkedIn | + 41 44 578 40 00 -- Derek Page Operations Engineer KAYAK
RE: Template download stuck at 1%
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) loLink 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.netmailto: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.orgmailto:users@cloudstack.apache.org Subject: Re: Template download stuck at 1% Stop firewall and see if it helps. Original message From: CK cloudw...@gmail.commailto:cloudw...@gmail.commailto:cloudw...@gmail.commailto:cloudw...@gmail.com Date: To: users@cloudstack.apache.orgmailto:users@cloudstack.apache.orgmailto:users@cloudstack.apache.orgmailto: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 3 ms, template=CentOS 6.3 at host nfs://192.168.2.12/export/secondaryhttp://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/24http://192.168.122.0/24 ! -d 192.168.122.0/24http://192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24http://192.168.122.0/24 ! -d 192.168.122.0/24http://192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24http://192.168.122.0/24 ! -d 192.168.122.0/24http://192.168.122.0/24 -j MASQUERADE -A POSTROUTING -s 192.168.122.0/24http
Re: Template download stuck at 1%
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%
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 3 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
Re: Template download stuck at 1%
Stop firewall and see if it helps. Original message From: CK cloudw...@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 3 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
RE: Template download stuck at 1%
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.commailto:cloudw...@gmail.com Date: To: users@cloudstack.apache.orgmailto: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 3 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
