~ubuntu-branches/ubuntu/saucy/nova/saucy-proposed

« back to all changes in this revision

Viewing changes to plugins/xenserver/doc/networking.rst

  • Committer: Package Import Robot
  • Author(s): Chuck Short
  • Date: 2012-05-24 13:12:53 UTC
  • mfrom: (1.1.55)
  • Revision ID: package-import@ubuntu.com-20120524131253-ommql08fg1en06ut
Tags: 2012.2~f1-0ubuntu1
* New upstream release.
* Prepare for quantal:
  - Dropped debian/patches/upstream/0006-Use-project_id-in-ec2.cloud._format_image.patch
  - Dropped debian/patches/upstream/0005-Populate-image-properties-with-project_id-again.patch
  - Dropped debian/patches/upstream/0004-Fixed-bug-962840-added-a-test-case.patch
  - Dropped debian/patches/upstream/0003-Allow-unprivileged-RADOS-users-to-access-rbd-volumes.patch
  - Dropped debian/patches/upstream/0002-Stop-libvirt-test-from-deleting-instances-dir.patch
  - Dropped debian/patches/upstream/0001-fix-bug-where-nova-ignores-glance-host-in-imageref.patch 
  - Dropped debian/patches/0001-fix-useexisting-deprecation-warnings.patch
* debian/control: Add python-keystone as a dependency. (LP: #907197)
* debian/patches/kombu_tests_timeout.patch: Refreshed.
* debian/nova.conf, debian/nova-common.postinst: Convert to new ini
  file configuration
* debian/patches/nova-manage_flagfile_location.patch: Refreshed

Show diffs side-by-side

added added

removed removed

Lines of Context:
48
48
How it works - Long
49
49
===================
50
50
 
51
 
Any time an underprivileged domain or domU is started or stopped, it gets a
52
 
unique domain id (dom_id).  This dom_id is utilized in a number of places, one
53
 
of which is it's assigned to the virtual interface (vif).  The vifs are attached
54
 
to the bridge that is attached to the physical network.  For instance, if you
55
 
had a public bridge attached to eth0 and your domain id was 5, your vif would be
56
 
vif5.0.  
 
51
Any time an underprivileged domain or domU is started or stopped, it
 
52
gets a unique domain id (dom_id).  This dom_id is utilized in a number
 
53
of places, one of which is that it is assigned to the virtual
 
54
interface (vif).  The vifs are attached to the bridge that is attached
 
55
to the physical network.  For instance, if you had a public bridge
 
56
attached to eth0 and your domain id was 5, your vif would be vif5.0.
57
57
 
58
58
The networking rules are applied to the VIF directly so they apply at the lowest
59
59
level of the networking stack.  Because the VIF changes along with the domain id
85
85
ebtables -A FORWARD -p 0800 -o vif1.0 --ip-dst 10.1.135.22 -j ACCEPT 
86
86
ebtables -I FORWARD 1 -s ! 9e:6e:cc:19:7f:fe -i vif1.0 -j DROP
87
87
 
88
 
Typically when you see a vif, it'll look like vif<domain id>.<network bridge>.
89
 
vif2.1 for example would be domain 2 on the second interface.
 
88
Typically when you see a vif, it'll look like
 
89
vif<domain id>.<network bridge>.  vif2.1 for example would be domain 2 on the
 
90
second interface.
90
91
 
91
92
The vif_rules.py script needs to pull information about the IPs and MAC
92
93
addresses assigned to the instance.  The current implementation assumes that
121
122
            "gateway":"10.177.10.1"}],
122
123
 "mac":"40:40:23:21:c9:b8"}
123
124
 
124
 
The key is used for two purposes.  One, the vif_rules.py script will read from
125
 
it to apply the rules needed after parsing the JSON.  The second is that because
126
 
it's put into the xenstore-data field, the xenstore will be populated with this
127
 
data on boot.  This allows a guest agent the ability to read out data about the
128
 
instance and apply configurations as needed.  
 
125
The key is used for two purposes.  First, the vif_rules.py script
 
126
reads from it to apply the rules needed after parsing the JSON.
 
127
Second, because it is put into the xenstore-data field, the xenstore
 
128
is populated with this data on boot.  This allows a guest agent the
 
129
ability to read out data about the instance and apply configurations
 
130
as needed.
129
131
 
130
132
Installation
131
133
============