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
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 wrote: > > > 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
Hi, answers inline. -Harikrishna On 20-Aug-2014, at 11:48 am, rahul wrote: > 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
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
You can upload data volumes into CS and this config is used for defining the max size of the volume you can upload. On 16/06/14 1:51 PM, "Bret Mette" wrote: >I changed it and it worked. But what is the >storage.max.volume.upload.size setting for? > > >- Bret > >> On Jun 16, 2014, at 1:41 PM, Nitin Mehta wrote: >> >> storage.max.volume.upload.size
Re: Template - Download file size is too large
I changed it and it worked. But what is the storage.max.volume.upload.size setting for? - Bret > On Jun 16, 2014, at 1:41 PM, Nitin Mehta wrote: > > storage.max.volume.upload.size
Re: Template - Download file size is too large
This setting is for both iso and template. As Shweta mentioned this param is used to control maximum size of template OR iso you can register in CS. Hope it clarifies it. On 15/06/14 11:13 PM, "Bret Mette" wrote: >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 > >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 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 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 file size is too large
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 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 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
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 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
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 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 > 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
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 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
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 stuck at 1%
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/%3cf992dc73cb61244fa00bf67dd648caf0d479253...@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 UG0 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 UG0 0 0 cloudbr0 On 17 May 2013 19:31, Musayev, Ilya 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: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:Lo
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 mailto:imusa...@webmd.net>> wrote: I would also check that MTU is properly set across the board and no packets are dropped on the switch or elsewhere. From: Musayev, Ilya Sent: Wednesday, May 15, 2013 10:02 PM To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org> Subject: Re: Template download stuck at 1% Stop firewall and see if it helps. Original message From: CK mailto:cloudw...@gmail.com><mailto:cloudw...@gmail.com<mailto:cloudw...@gmail.com>>> Date: To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org><mailto:users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>> Subject: Re: Template download stuck at 1% Running wget to download a template as a test on the SSVM starts off fine and then after several seconds (10+) the download grinds down to 0Kb/s - the ETA starts to go up. Doing the same wget download from the MS host works fine the template is downloaded in full - no timeouts. Looking in the log I noticed this line: 2013-05-16 02:30:26,123 DEBUG [storage.download.DownloadListener] (Timer-6:null) Scheduling timeout at 3 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 19
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 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 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 > 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 CH
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 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 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 -
Re: Template download stuck at 1%
Stop firewall and see if it helps. Original message From: CK 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 REJECT --reject-with
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 FORWA
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?
