cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Duffy <...@ianduffy.ie>
Subject Re: devcloud4 advanced -- xenserver&/SSVM iptables/routes
Date Thu, 09 Oct 2014 00:28:28 GMT
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 <ian@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 <LSimons@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
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message