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 [email protected]
-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
