Hi Leo,
Just checking this from master with the same version of marvin.
For whatever reason marvin doesn't seem to be setting the tags on the
network interfaces.
The following and deployDataCenter should be setting them:
"traffictypes": [
{
"xen": "GUEST",
"typ": "Guest"
},
{
"xen": "MGMT",
"typ": "Management"
},
{
"xen": "PUBLIC",
"typ": "Public"
}
],
Assuming possible marvin issue or a change on the API side of things since
i'm seeing the following in the logs:
INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-2:ctx-7d1f3c4f job-2)
Remove job-2 from job monitoring
WARN [c.c.a.d.ParamGenericValidationWorker]
(66988863@qtp-580960970-0:ctx-2907b805
ctx-4ac83e7b ctx-a48b5480) Received unknown parameters for command
addTrafficType. Unknown parameters : xennetworklabel
INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-3:ctx-9bb4a8c7 job-3)
Add job-3 into job monitoring
WARN [c.c.a.d.ParamGenericValidationWorker]
(API-Job-Executor-3:ctx-9bb4a8c7 job-3 ctx-c36450e0) Received unknown
parameters for command addTrafficType. Unknown parameters : xennetworklabel
INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-3:ctx-9bb4a8c7 job-3)
Remove job-3 from job monitoring
WARN [c.c.a.d.ParamGenericValidationWorker]
(66988863@qtp-580960970-0:ctx-8f797173
ctx-115c4ef1 ctx-d988b655) Received unknown parameters for command
addTrafficType. Unknown parameters : xennetworklabel
INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-4:ctx-3370b3b8 job-4)
Add job-4 into job monitoring
WARN [c.c.a.d.ParamGenericValidationWorker]
(API-Job-Executor-4:ctx-3370b3b8 job-4 ctx-27bd2c08) Received unknown
parameters for command addTrafficType. Unknown parameters : xennetworklabel
Downgrading the version of marvin doesn't fix the issue either. Based on
our API docs this should be correct:
http://cloudstack.apache.org/docs/api/apidocs-4.4/root_admin/addTrafficType.html
I set the values manually through the UI, destroyed the system vms, waited
for them to come up and had a system that had internet access.
The agent on the ssvm and console proxy failed to come up....
root@s-4-VM:/usr/local/cloud/systemvm# ./ssvm-check.sh
================================================
First DNS server is 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 48 data bytes
56 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=5.642 ms
56 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=5.559 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.559/5.601/5.642/0.042 ms
Good: Can ping DNS server
================================================
Good: DNS resolves download.cloud.com
================================================
nfs is currently mounted
================================================
Management server is 192.168.56.1. Checking connectivity.
Good: Can connect to management server port 8250
================================================
ERROR: Java process not running. Try restarting the SSVM.
Thanks,
Ian
On 9 October 2014 00:13, Ian Duffy <i...@ianduffy.ie> wrote:
> 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
>>
>>
>
