Hey Marcus, Is the latest devcloud-kvm image you shared via the wiki
up to date? I'll try it out and see why traffic labels failed to
configure. Thanks,
On 15 January 2013 06:55, Marcus Sorensen <shadow...@gmail.com> wrote:
> I've now got a config for regular devcloud in
> tools/devcloud/devcloud-advanced.cfg, this works for me to deploy a fully
> working advanced network zone, except for the traffic labels. If I go in
> and manually fix the traffic labels to be as shown in the config, then
> restart management server/system vms, everything works. This is given a
> default virtualbox install where the nat is 10.0.3.2. Public VMs end up on
> the 10.0.3 network, and isolated networks carve out new tagged
> vlans/bridges on the 192.168.56.0 network.
>
> I've also got a version for my devcloud-kvm that needs the same labels
> settings to work, once that's done I'll update the docs and the
> devcloud-kvm should be ready to go.
>
> On Mon, Jan 14, 2013 at 11:53 AM, Marcus Sorensen <shadow...@gmail.com>wrote:
>
>> 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.,
>>>
>>
>>
