Hey Leo,
> I’m confident I had all this working before, and I don’t recall this
being needed with devcloud4 before, but tonight I had to twiddle the routes:
Yes this is definitely new and I have not experienced it before.
There should be no need to touch the SSVM.
> default via 192.168.57.5 dev eth2
This should of given your machine internet access.
I've a feeling this might be related to some of your virtualbox interface
configurations. I will test just to be sure.
Thanks,
Ian
On 8 October 2014 20:57, Leo Simons <lsim...@schubergphilis.com> wrote:
> Hey Ian,
>
> So, I upgraded my devcloud4 to latest and rebuilt all the things. For the
> advanced profile, after bringing it all up, the tiny linux template wasn’t
> becoming ready, sticking to status "No route to host”.
>
> After a bunch of head-scratching and debugging, it turned out I had to run
>
> [vagrant@localhost ~]$ sudo /etc/init.d/iptables stop
>
> on the xenserver to allow the secondary storage VM to go out and reach the
> management server. With that out of the way, downloading the tiny linux VM
> starts, but
>
> 2014-10-08 17:22:45,307 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Seq 2-6307009803155669001:
> { Ans: , MgmtId: 4278190080, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.storage.DownloadAnswer”:
> {"jobId":"80b02ebf-db7f-4582-97a3-c38426be1fc5","downloadPct":0,
> "errorString":"No route to host","downloadStatus":"DOWNLOAD_ERROR”,
>
>
> "downloadPath":"/mnt/SecStorage/ec84292d-0e04-339d-b095-2649738a410f/template/tmpl/1/5/dnld486207062222241560tmp_”,
> "installPath":"template/tmpl/1/5","templateSize":0,
> "templatePhySicalSize":0,"checkSum":"046e134e642e6d344b34648223ba4bc1”,
> "result":true,"details":"No route to host","wait":0}}] }
>
> and after that, furthermore, surprisingly,
>
> root@s-3-VM:~# /etc/init.d/iptables-persistent flush
>
> that solved DNS lookups and pings but not yet http downloads. This
> reminded me of what we have in our own CIT environment where we do some
> trickery to rewire the SSVM after creation.
>
> I’m confident I had all this working before, and I don’t recall this being
> needed with devcloud4 before, but tonight I had to twiddle the routes:
>
> $ vagrant ssh xenserver
> [vagrant@localhost ~]$ sudo /sbin/ip route list
> 10.0.2.0/24 dev xenbr0 proto kernel scope link src 10.0.2.15
> 192.168.56.0/24 dev xenbr1 proto kernel scope link src 192.168.56.10
> 169.254.0.0/16 dev xapi0 scope link src 169.254.0.1
> default via 10.0.2.2 dev xenbr0
> [vagrant@localhost ~]$ sudo ssh -i /root/.ssh/id_rsa.cloud
> root@169.254.2.27 -p 3922
> root@s-3-VM:~# ip route list
> default via 192.168.57.5 dev eth2
> 8.8.8.8 via 192.168.56.5 dev eth1
> 169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.2.27
> 192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.107
> 192.168.56.0/24 dev eth3 proto kernel scope link src 192.168.56.115
> 192.168.57.0/24 dev eth2 proto kernel scope link src 192.168.57.100
> root@s-3-VM:~# ip route delete default dev eth2
> root@s-3-VM:~# ip route add default via 192.168.56.5 dev eth1
>
> after that, template downloads work (you know, we should really not use
> people.a.o for this……). So I’m happy with my setup again, but its obviously
> a bit fiddly. I’m not entirely sure what your intentions are for this
> network setup — did you look into this yet / did you find a way to do this
> stuff without modifying the SSVM?
>
>
> cheers,
>
>
> Leo
>
>
