When I add a security group rule with cidr like 1.1.1.1/24, the rule is not applied on kvm hypervisor.
Ths issue does not exist in 4.13.0.0 and previous versions.
After commit fbf488497fb863c13fc0908281e3f4f86906df43, admin need to specify an ipv4 or ipv6 addresses when add IP to nic which breaks backward compatibity. If IP is not specified, a IPv4 address should be returned.
When I add a secondary IP to a nic on shared network in advanced zone with security groups, the network rules for new IP are not applied on KVM hypervisors.
It is because "--action -A" cannot be recognized in security_group.py after commit ac73e7e671ba107830f96b9fb534eb716956e405. changing to "--action=-A" will fix it.
When add a acl rule with protocol number, the iptables rules in vpc vr is not applied correctly.
for example, when add an ingress acl rule (protocol number:50, cidr: 2.2.2.2/32), we expect to have a iptables rule: "-A ACL_INBOUND_eth2 -s 2.2.2.2/32 -p esp -j ACCEPT"
the actual rule is "-A ACL_INBOUND_eth2 -j DROP"
It is because the rules in json are not correct.
network_acl.json.a8c52dca-0278-4e1c-b72b-987ca7121f4f.gz:{"device":"eth2","mac_address":"02:00:7d:27:00:02","private_gateway_acl":false,"nic_ip":"192.168.11.12","nic_netmask":"28","ingress_rules":[{"type":"protocol","protocol":50,"cidr":"ACCEPT","allowed":false},{"type":"all","cidr":"0.0.0.0/0","allowed":true},],"egress_rules":[],"type":"networkacl"}
Fixes: #3602
Fixes issue #3590 by using the last element on the array from the snapshot "path" String for retrieving the snapshot id. Additionally, it uses the volumePath as the volume id which should always be the correct value. The error raised on issue #3590 was related to the wrong use of variable "path" where in some cases had a different set of substrings.
The proposed change has been tested and evaluated. The values used for openning the RBD connection and executing the rollback were stable on the tests. Runned rollback on multiple snapshots and could start the VM with the content matching the ROOT reverted snapshot.
In case an older SSVM is removed without changing it's state from Up
to Destroyed/Removed etc, the SSVM may be randomly selected for image
store related operations. This fix ensures that endpoints for an image
store are found only from a set of SSVM hosts that are not removed.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
While searching for existing route, don't use the throw keyword when
using the cmd with `ip route show`.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
On a Cloudstack instance with log verbosity set to INFO, there are 2 messages generated every 10 seconds about cleaning up expired async jobs. This makes the log messages much noisier than they need to be.
This PR reduces that message to trace level, since there are actually useful messages at INFO level in that class.
KVM is supported on arm64 Linux (https://www.linux-kvm.org/page/Processor_support#ARM:).
For a small (IoT) platform such as the new Raspberry Pi 4 that uses armv8 processor
(cortex-a72) it's possible to run Linux host with `/dev/kvm`
accleration. This adds support for IoT IaaS in CloudStack.
This PR is from a fun weekend project where:
- I set up a Raspberry Pi 4 - 4GB RAM model with 4 CPU cores @ 1.5Ghz, 128GB SD samsung evo plus card
- Installed Ubuntu 19.10 raspi3 base image: http://cdimage.ubuntu.com/releases/19.10/release/ubuntu-19.10-preinstalled-server-arm64+raspi3.img.xz
- Build a custom Linux 5.3 kernel with KVM enabled, deb here: http://dl.rohityadav.cloud/cloudstack-rpi/kernel-19.10/ and install the linux-image and linux-module
- Then install/setup CloudStack on it (fix some issues around jna, by manually installing newer libjna-java to /usr/share/cloudstack-agent/lib)
- Since the host processor is not x86_64, I had to build a new arm64 (or aarch64) systemvmtemplate: http://dl.rohityadav.cloud/cloudstack-rpi/systemvmtemplate/
I could finally get a 4.13 CloudStack + Adv zone/networking to run on it
and deployed a KVM based Ubuntu 19.10 environment and NFS storage.
Deployed a test vm with isolated network, VR works as expected. Console
proxy works as well, for this tested against arm64 openstack Debian 9/10
templates.
I raised the issue of enabling KVM in upstream Ubuntu arm64 build: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1783961
Ubuntu kernel team has come back and future arm64 releases may have
KVM enabled by default.
Limitation: on my aarch64 env, it did not support IDE, therefore all
default bus type for volumes are SCSI by default. With VIRTIO it fails
sometimes.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Diagnostics are hard when a snapshot fails if a null pointer occurs. This is because no stack trace or location of the error is logged. I.E.
2019-10-21 12:55:00,056 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] (Work-Job-Executor-131:ctx-80420156 job-10033827/job-10033828 ctx-4864e2f5) (logid:21454564) copy snasphot failed: java.lang.NullPointerException
* kvm: Use 'ip' instead of 'brctl'
The command 'brctl' is deprecated and should no longer be used.
iproute2 supports all the features we need and therefor we should use
this instead of the old commands.
Feature wise this does not change anything. It just makes the code more
robust towards the future.
Signed-off-by: Wido den Hollander <wido@widodh.nl>
* kvm/modifyvlan: Use 'ip' instead of 'brctl'
brctl is deprecated and by using iproute2 we are future-proof
Signed-off-by: Wido den Hollander <wido@widodh.nl>
* Increase lease time to infinite
Lease time set to effectively infinite (36000+ days) since we fully control VM lifecycle via CloudStack
Infinite time helps avoid some edge cases which could cause DHCPNAK being sent to VMs since
(RHEL) system lose routes when they receive DHCPNAK
When VM is expunged, it's active lease and DHCP/DNS config is properly removed from related files in VR.
* desc fix
in agent.log on a host running with cloudstack 4.14.0.0-SNAPSHOT, it gives error
root@node212:~# /usr/share/cloudstack-common/scripts/vm/network/security_group.py get_rule_logs_for_vms
Traceback (most recent call last):
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", line 1272, in <module>
get_rule_logs_for_vms()
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", line 758, in get_rule_logs_for_vms
vms = virshlist(state)
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", line 104, in virshlist
alldomains = [d for domain in map(conn.lookupByID, conn.listDomainsID())]
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py", line 104, in <listcomp>
alldomains = [d for domain in map(conn.lookupByID, conn.listDomainsID())]
NameError: name 'd' is not defined
We've encountered a corner case where bridge -o link show returned two lines per bridge instead of one. get_bridge_physdev in security_group.py returned bond0.701\nbond0.701.
Although this may very well be something on the hypervisor, we should limit the lines returned.
I therefore added a mere | head -1 to the function.
This reverts "9ee129ae6a08935645734ad520bec72bf5f22217" from #3525, as
the solution is not optimal and would cause a single Link to be added
in the Map if management server is behind a LB.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Every time a client connects, the NioServer will retain the link against
the InetSocketAddress object. If the same agent/client reconnects, it
will grow older links over time and in case of denial of service attack
or a client/script/monitoring-service reconnecting aggressively against
port 8250 will cause the `_links` weak hashmap to grow over time and
very quickly.
The fix will ensure that only one Link gets weakly retained for an
incoming client based on its address string.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
* server: Do NOT cleanup dhcp and dns when stop a vm
According comment in PR #3608, dhcp and dns entries are cleaned up only when a VM is expunged.
Revert part of commit 8fb388e9312b917a8f36c7d7e3f45985a95ce773.
* server: cleanup dns/dhcp entries in removeNic instead of finalizeExpunge
* kvm/security_group: Make Security Group Python 3 compatible
This script only runs on the KVM Hypervisors and these all support
Python 3.
As Python 2 is deprecated at the end of 2019 we need to fix these
scripts to work under Python 3.
CentOS 7, 8 and Ubuntu 16.04 and 18.04 all have Python 3 installed
by default.
Ubuntu 20.04 will no longer have Python 2 installed and therefor
this script needs to be modified to work with Python 3.
Signed-off-by: Wido den Hollander <wido@widodh.nl>
* Add dependency of python3 in packaging/centos7/cloud.spec
This fixes a behaviour to not cleanup DHCP and DNS rules for NICs of a
VM in the VR when it is stopped, but instead when VM is expunged because
stopped VMs in CloudStack still retain the IPs and records.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
In case of null guest OS found for a template, don't fail prioritisation
completely (could still work based on HVM etc).
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Refactor: Cleanup duplicate code
Make use of Java 8 default implementation in interfaces,
to remove code duplication between XxxCmd and XxxCmdAsAdmin.
Refactor checkFormat by pre-calculating the supported
extensions. Also make use of this in ImageStoreUtil.
Makes it easier to add new file and compression formats.
Logrotate should only touch security_group.log and resizevolume.log
as the agent.log is already rotated by log4j inside the Agent.
Having two systems trying to rotate agent.log leads to all kinds of
issues like having binary (compressed) data in the middle of a plain-text
log file.
In addition we do not have to rotate the logs every day, only when they
grow larger than 10M. On fairly idle hypervisors this should not cause
those logs to rotate every day.
Signed-off-by: Wido den Hollander <wido@widodh.nl>
- Removes CentOS6/el6 packaging (voting thread reference https://markmail.org/message/u3ka4hwn2lzwiero)
- Add upgrade path from 4.13 to 4.14
- Enable live storage migration support for KVM by default as el6 is deprecated
- PRs using live storage migration
#2997 KVM VM live migration with ROOT volume on file storage type
#2983 KVM live storage migration intra cluster from NFS source and destination
#2298 CLOUDSTACK-9620: Enhancements for managed storage
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Using this tool on a hypervisor admins can query KVM Instances running
on that hypervisor if they have the Qemu Guest Agent installed.
All System VMs have this and they can be queried.
For example:
$ cloudstack-guest-tool i-2-25-VM
This will print some information about network and filesystem status.
root@hv-138-a05-23:~# ./cloudstack-guest-tool s-11-VM --command info|jq
{
"network": [
{
"ip-addresses": [
{
"prefix": 8,
"ip-address": "127.0.0.1",
"ip-address-type": "ipv4"
}
],
"name": "lo",
"hardware-address": "00:00:00:00:00:00"
},
{
"ip-addresses": [
{
"prefix": 16,
"ip-address": "169.254.242.169",
"ip-address-type": "ipv4"
}
],
"name": "eth0",
"hardware-address": "0e:00:a9:fe:f2:a9"
},
...
...
"filesystem": [
{
"mountpoint": "/var",
"disk": [
{
"bus": 0,
"bus-type": "virtio",
"target": 0,
"unit": 0,
"pci-controller": {
"slot": 7,
"bus": 0,
"domain": 0,
"function": 0
}
}
],
"type": "ext4",
"name": "vda6"
},
Signed-off-by: Wido den Hollander <wido@widodh.nl>
Since version 10.0.0 of Debian has become stable, the URL of the Debian 9.9.0 ISO files has changed from current to archive.
The old URL returns a 404 and crash the build of systemvm templates.
is not used; probably it is a legacy code/table.
Therefore, remove the verification that counts the IPs from
UserIpv6AddressVO in order to check if it can use the network for
deploying new VMs in UI [1].
[1] com.cloud.network.NetworkModelImpl.canUseForDeploy(Network).
Fixes NPE when trying to find suitable storage pools for a volume
when the volume is not attached to a VM.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
