Thanks. I've tested the vlan stuff and it seems to work. Now I'm stuck on the traffic labels. My config deploys but my traffic labels all show 'Use default network'. My script generated the following:
{ "zones": [ { "localstorageenabled": "true", "name": "testzone", "guestcidraddress": "10.1.1.0/24", "dns1": "8.8.8.8", "physical_networks": [ { "broadcastdomainrange": "Zone", "vlan": "3900-4000", "name": "eth0", "traffictypes": [ { "xen": "Pool-wide network associated with eth0", "typ": "Management" }, { "xen": "Pool-wide network associated with eth0", "typ": "Guest" } ], "providers": [ { "broadcastdomainrange": "ZONE", "name": "VirtualRouter" }, { "broadcastdomainrange": "ZONE", "name": "VpcVirtualRouter" } ] }, { "broadcastdomainrange": "Zone", "name": "eth1", "traffictypes": [ { "xen": "Pool-wide network associated with eth1", "typ": "Public" } ], "providers": [ { "broadcastdomainrange": "ZONE", "name": "VirtualRouter" } ] } ], "ipranges": [ { "startip": "10.0.3.100", "endip": "10.0.3.199", "netmask": "255.255.255.0", "vlan": "untagged", "gateway": "10.0.3.2" } ], "networktype": "Advanced", "pods": [ { "endip": "192.168.56.249", "name": "testpod", "startip": "192.168.56.200", "netmask": "255.255.255.0", "clusters": [ { "clustername": "testcluster", "hypervisor": "XenServer", "hosts": [ { "username": "root", "url": "http://192.168.56.10/", "password": "password" } ], "clustertype": "CloudManaged" } ], "gateway": "192.168.56.1" } ], "internaldns1": "8.8.4.4", "secondaryStorages": [ { "url": "nfs://192.168.56.10:/opt/storage/secondary" } ] } ], "dbSvr": { "dbSvr": "127.0.0.1", "passwd": "cloud", "db": "cloud", "port": 3306, "user": "cloud" }, "logger": [ { "name": "TestClient", "file": "/var/log/testclient.log" }, { "name": "TestCase", "file": "/var/log/testcase.log" } ], "mgtSvr": [ { "mgtSvrIp": "192.168.56.10", "port": 8096 } ] } and my networks look like: root@devcloud:~/marvin# xe network-list uuid ( RO) : 4f17b2b8-f7a8-0c2f-12b2-45bddeb63744 name-label ( RW): Host internal management network name-description ( RW): Network on which guests will be assigned a private link-local IP address which can be used to talk XenAPI bridge ( RO): xenapi uuid ( RO) : 4948968a-3e67-fe53-29ad-099d74bac81c name-label ( RW): cloud_link_local_network name-description ( RW): link local network used by system vms bridge ( RO): xapi0 uuid ( RO) : f1b661c0-d3a0-7e94-0302-9a306f798787 name-label ( RW): Pool-wide network associated with eth0 name-description ( RW): bridge ( RO): xenbr0 uuid ( RO) : 585cc9f4-e11e-51eb-9b4b-bed2f71a8658 name-label ( RW): Pool-wide network associated with eth1 name-description ( RW): bridge ( RO): xenbr1 uuid ( RO) : c1dbdb4c-16cb-5ce5-9026-5908e2463d20 name-label ( RW): VLAN-f1b661c0-d3a0-7e94-0302-9a306f798787-165 name-description ( RW): bridge ( RO): xapi1 uuid ( RO) : b1e55bef-fe46-3a0b-ab0a-549121f42249 name-label ( RW): VLAN-f1b661c0-d3a0-7e94-0302-9a306f798787-149 name-description ( RW): bridge ( RO): xapi2 On Sun, Jan 13, 2013 at 2:04 AM, Prasanna Santhanam <t...@apache.org> wrote: > I've fixed the problem of the same vlan applied to all the physical > networks with CLOUDSTACK-968 [1]. The vlan attribute went back-and-forth > b/w zone and phy. network when the physical-network concept was > introduced. Looks like I failed to fix marvin then. > > Also while fixing this I noticed our ZoneResponse still carries the > legacy 'vlan' that was given at zone level in 2.2. This is ending up > in marvin's response class too in createZoneResponse. Not sure if this > is still reqd because I didn't find any usage of that vlan. Posted > CLOUDSTACK-969 [2] > > The wiki documentation is also corrected along with the examples in > the sandbox which now show the use of traffic labels. > > Lastly, I've also committed a config generator script for devcloud-kvm > extending from the config you shared [3] > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-968 > [2] https://issues.apache.org/jira/browse/CLOUDSTACK-969 > [3] http://s.apache.org/rrZ > > Thanks, > > On Fri, Jan 11, 2013 at 01:05:55PM -0500, Prasanna Santhanam wrote: > > Marcus - Thanks for bringing these up: > > > > On Fri, Jan 11, 2013 at 12:41:08PM -0500, Marcus Sorensen wrote: > > > Let me verify that everything is working first :-) > > > > > > I've had a chance to play with some of the marvin stuff a bit, and am > > > running into a few issues. Per the example on > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Testing+with+Python > > > under > > > 'how do I generate it', if I copy that python script into devcloud and > run > > > it, I end up with the following broken globalConfig: > > > > > > "globalConfig": [ > > > { > > > "name": "name", > > > "value": "value" > > > }, > > > { > > > "name": "name", > > > "value": "value" > > > } > > > ], > > > > I'll fix this. The documentation is wrong. That should just be a > dictionary. > > You can check tools/marvin/marvin/sandbox/advanced/advanced_env.py on > how you > > can simply get the config out of a properties file. > > > > > > > > If I delete that then the 431 goes away. > > > > > > Also, I don't see a way to edit the traffic labels on the advanced > network > > > stuff in marvin, that would be extremely useful. > > > > This can be done as follows: > > > > for eg: > > from tools/marvin/marvin/configGenerator.py:describe_setup_in_eip_mode() > > > > 418 pn = physical_network() > > 419 pn.name = "test-network" > > 420 pn.traffictypes = [traffictype("Guest", {"xen": > "cloud-guest"}), traffictype("Management"), traffictype("Public", { "xen": > "cloud-public"} )] > > 421 pn.providers.extend([sgprovider, nsprovider]) > > 422 z.physical_networks.append(pn) > > > > > > > > Lastly, It seems that if I set a vlan range for a zone, marvin > attempts to > > > set that vlan range for every physical network defined for the zone. > So the > > > first one succeeds, the second one fails. The vlan property should be > moved > > > up to be a member of the physical network as far as marvin is > concerned. > > > We're in the process of making changes that allow you to use the same > vlan > > > numbers on different physical networks anyway, since it's possible > that you > > > can have completely separate infrastructure on each nic. > > > > > You're right - I'll have the vlan move down to physical_network. > > > > > > > > On Fri, Jan 11, 2013 at 10:09 AM, John Kinsella <j...@stratosec.co> > wrote: > > > > > > > very cool - hoping I can get a chance to test this out and give some > > > > feedback within the next week or so. Thanks! > > > > > > > > On Jan 10, 2013, at 10:53 AM, Marcus Sorensen <shadow...@gmail.com> > wrote: > > > > > > > > > Guys, > > > > > I'm writing up basic instructions on how to run a devcloud-kvm > virtual > > > > > machine, for KVM development. The setup is complete, but I've run > into a > > > > > few things as far as configuration that I'd like some help on. > > > > > > > > > > 1) running services. In the past I've just built rpms and > installed them > > > > in > > > > > the devcloud-kvm. Not only does this not work on master right now, > but it > > > > > takes an extra 60 seconds. With devcloud we run "mvn -P > > > > developer,systemvm > > > > > clean install && mvn -pl :cloud-client-ui jetty:run", I'm assuming > I'll > > > > > have to start the agent as well... or I guess my question is how > that's > > > > > handled when a normal zone creation expects the agent to be > installed on > > > > > the KVM host. > > > > > > > > > > 2) how to go about configuration. I'd like to have a marvin config > that > > > > > does two physical networks and an advanced zone, but I wasn't able > to get > > > > > anything but a 431 error when trying anything custom with a marvin > cfg > > > > file > > > > > (both in the standard devcloud and here). I played with the sandbox > > > > example > > > > > at > > > > > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Testing+with+Pythonas > > > > > well as trying to create my own cfg file, and both resulted in 431 > when > > > > > connecting to the management server for configuration. > > > > > > > > Stratosec - Secure Infrastructure as a Service > > > > o: 415.315.9385 > > > > @johnlkinsella > > > > > > > > > > > > -- > > Prasanna., > > -- > Prasanna., >