From functionality point of view following will be changes.
-> Threshold will not be applied for vms undergoing HA process (say during host going down event).
-> Threshold will not be applied for vms undergoing maintenance.
-> Threshold will apply for stop-start vm "after" the skip.counting.hours
(time till which we reserve the capacity for the stopped vm).
Reason being stop-start is a user initiated action and we are giving a time
window (skip.counting.hours) till which its guaranteed to start in the same
cluster.
After that time, threshold check applies bcz we still want to reserve the
capacity for urgent situations like HA, putting host into maintenance rather than get it consumed in such user
initiated actions.
Signed off by : nitin mehta<nitin.mehta@citrix.com>
I don't think host kernel version has any bearing on it. Original code
was tested with CentOS 6.3 and 6.4, but it seems to succeed or fail per-host,
e.g. a fast host might work and a slow host might not. I was getting intermittent
failures with ubuntu 12.04.3 prior to this patch.
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
[VMware] [upgrade] system VM not coming up after upgrade from 3.0.4 to 4.2
(cherry picked from commit f21c8fa998)
Signed-off-by: animesh <animesh@apache.org>
[VMware] [upgrade] system VM not coming up after upgrade from 3.0.4 to 4.2
(cherry picked from commit c5139d6bc9)
Signed-off-by: animesh <animesh@apache.org>
The code is excessively complicated and convoluted.
DisassociateIP ->
Revoke Rule -> {FW, PF{incl SNAT}, LB, RA VPN} ->
-> Send IpAssoc (false) to VR
Send all config to VR again
-> Send IpAssoc(false) to VR again <---- fails here since it cannot find the VLAN for the IP since it is already gone
-> Mark Ip as released
The workaround fix would be to not throw an exception in CitrixResourceBase if it is disassociate and the VLAN does not exist on the XS host.
Signed-off-by: Chiradeep Vittal <chiradeep@apache.org>
(cherry picked from commit a98eb12549)
Signed-off-by: animesh <animesh@apache.org>
Nitin Mehta
amogh.vasekar
Sheng Yang
Anthony Xu
Anshul Gangwar
Min Chen
Marcus Sorensen
Frank.Zhang
Kelven Yang
animesh
Wei Zhou
Edison Su
Devdeep Singh
Chiradeep Vittal