There still exist two issues after Edison's commits.
(1) Migration from new hosts to old hosts failed.
The bridge name on old host is set to cloudVirBr* if network.bridge.name.schema is set to 3.0 in /etc/cloudstack/agent/agent.properties, but the actual bridge name is breth*-* after running cloudstack-agent-upgrade.
(2) all ports of vms (Basic zone, or Advanced zone with security groups) on old hosts are open, because the iptables rules are binding to device (bridge) name which is changed by cloudstack-agent-upgrade.
After this, the KVM upgrade steps :
a. Install 4.2 cloudstack agent on each kvm host
b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing bridge name to new bridge name, and update related firewall rules.
c. install a libvirt hook:
c1. mkdir /etc/libvirt/hooks
c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu
c3. chmod +x /etc/libvirt/hooks/qemu
c4. service libvirtd restart
c5. service cloudstack-agent restart
Signed-off-by: Wei Zhou <w.zhou@leaseweb.com>
When 'security_group.py cleanup_rules' is called by the KVM Agent it will clean up all Instances
not in the "running" state according to libvirt.
However, when a snapshot is created of a Instance it will go to the "paused" state while the snapshot
is created.
This leads to Security Rules being removed when a Instance is being snapshotted and the cleanup process
is initiated.
Detail: Added exception handling around iptables chain flushing, along
with a call to default_network_rules() to re-initialize.
Testing:
On agent, ls /var/run/cloud and pick one of the VMs to test with. Make a
backup of it's logfile (eg cp /var/run/cloud/i-2-1722.log /tmp )
Destroy the firewall ruleset for that VM with
/usr/lib64/cloud/common/scripts/vm/network/security_group.py destroy_network_rules_for_vm --vmname i-2-1722-VM --vif vnet10
Now copy the log file back, edit the file and decrement the last field by 1
ACS should notice the out-of-date sequence ID and push a new ruleset for
the VM within 60 seconds.
BUG-ID: CLOUDSTACK-1685
Bugfix-for: John Kinsella
Reviewed-by:
Reported-by:
Signed-off-by: John Kinsella <jlk@stratosec.co> 1363286927 -0700
Detail: A grep in security_group.py wasn't defined well enough, could
potentially delete rules for VMs other than intended
BUG-ID: CLOUDSTACK-309
Bugfix-for: master
Reviewed-by:
Reported-by: Francois Scala
Signed-off-by: John Kinsella <jlk@stratosec.co> 1363222521 -0700
Detail: Code was attempting to concatinate an exception to a string.
Updated to convert to text and concatinate that.
BUG-ID: CLOUDSTACK-1052
Bugfix-for: master
Reported-by: Noa Resare
Signed-off-by: John Kinsella <jlk@stratosec.co> 1363218769 -0700
Checks the args length, doesn't throw IndexError when no args
passed. Also logs to security_group.log when executed with no args or unknown
command.
Review: https://reviews.apache.org/r/9588
Reviewed-by: Rohit Yadav <bhaisaab@apache.org>
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Since we're always getting the first from the list, use head -1 to get the first
of the results instead of processing again
- Remove unecessay pop (why was it even there)
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
The default_network_rules_systemvm method in security_group.py only created the appropriate rules for
just one bridge.
This however leads to traffic not being forwarded to the virtual machine in the case of the system VMs
both (console & storage) having different bridges in basic networking.
This patch makes sure rules are generated for all target devices based on their source device/bridge
It however excludes the LinkLocalBridge since no filtering is needed on that bridge.
Changes :
- Fixing API doc +response name + errorMessage
- Adding seperate events to Egress rules
- Egress rules Using the same database table as that of ingress with new column type.
Pending Tasks:
- db upgrade
- database table rename from security_ingress_rule to generic name, renaming some of the jave class from ingress to generic name.
- Retesting on kvm
Description :
API's:
- Two new api's authorizeSecurityGroupEgress,revokeSecurityGroupEgressCmd are added. These two API's are similer to ingress rule API's.
- authorizeSecurityGroupEgress :Authorizes a particular egress rule for this security group . Usageof API is very similer to that of authorizeSecurityGroupIngress except that instead of source cidr there will be destination cidr. By default like ingress, all the outgoing flows are blocked.
- revokeSecurityGroupEgress : It is similer to revokeSecurityGroupIngress api, It removes the egress rule.
- listSecurityGroup API's response changed. It include's egress list apart from the existing ingress rules in the output of the API.
Hypervisors :
- It is implemented in Xen and KVM.
Pending Tasks : Blocking using destination security groups.
Previous commits: c9fda641673df7701f44963ef27e1d488f121219 , 24e4e44b8f0712a37147a3777833de3f9e24829e
