xs 6.1/6.2 introduce the new virtual platform, so there are two virtual platforms, windows PV driver version must match virtual platforms,
this patch tracks PV driver versions in vm details and template details.
Anthony
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>
when secondary storage is mounted as read-only, changing permission of files on it will fail. But we should still stick to current mount point instread of
returning a wrong mount point /mnt/sec
(cherry picked from commit db2d9703c1)
Signed-off-by: animesh <animesh@apache.org>
Since introducing pool of session contexts we no more have a dedicated context for each VMware hypervisor host.
Hence vsm credentials stored in session context cannot be retrieved always correctly. Fix is to register the vsm credentials after fetching context and the context gets recycled after use.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
(cherry picked from commit eaea8f8c5f)
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>
when secondary storage is mounted as read-only, changing permission of files on it will fail. But we should still stick to current mount point instread of
returning a wrong mount point /mnt/sec
Since introducing pool of session contexts we no more have a dedicated context for each VMware hypervisor host.
Hence vsm credentials stored in session context cannot be retrieved always correctly. Fix is to register the vsm credentials after fetching context and the context gets recycled after use.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
A recent code change in NetworkManager causes NullPointerExceptions when DHCP
capability list is null.
The commit which made the NetworkManager change also changed the VirtualRouter
to not use null for the capabilitylist, but didn't make this change for other
network devices, causing DHCP to fail on MidoNet.
This change also updates the MidoNet plugin to use the most recent MidoNet API.
Signed-off-by: Sheng Yang <sheng.yang@citrix.com>
(cherry picked from commit a55c75bbd2)
Signed-off-by: animesh <animesh@apache.org>
Disk images are not always in the QCOW2 format, so don't assume that the
filename will always and in .qcow2
(cherry picked from commit 93b40b0ca6)
Signed-off-by: animesh <animesh@apache.org>
A recent code change in NetworkManager causes NullPointerExceptions when DHCP
capability list is null.
The commit which made the NetworkManager change also changed the VirtualRouter
to not use null for the capabilitylist, but didn't make this change for other
network devices, causing DHCP to fail on MidoNet.
This change also updates the MidoNet plugin to use the most recent MidoNet API.
Signed-off-by: Sheng Yang <sheng.yang@citrix.com>
Libvirt reports:
org.libvirt.LibvirtException: Storage volume not found: no storage vol
with matching name
in some cases, if the volume is created on one kvm host, while accessed
from other host.
It's possible due to concurrent access(read/write) storage.
The current fix is to try serveral times, and wait for 30 seconds for
each retry.
If the issue still there, then need to sync the storage pool access
Libvirt reports:
org.libvirt.LibvirtException: Storage volume not found: no storage vol
with matching name
in some cases, if the volume is created on one kvm host, while accessed
from other host.
It's possible due to concurrent access(read/write) storage.
The current fix is to try serveral times, and wait for 30 seconds for
each retry.
If the issue still there, then need to sync the storage pool access
Frank.Zhang
Anthony Xu
Nitin Mehta
amogh.vasekar
Sheng Yang
Anshul Gangwar
Min Chen
Marcus Sorensen
Kelven Yang
animesh
Wei Zhou
Edison Su
Devdeep Singh
Chiradeep Vittal
Sateesh Chodapuneedi
Mike Tutkowski
Dave Cahill
Wido den Hollander
Bharat Kumar