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