[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>
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>
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
This failed due to a RAW -> QCOW2 conversion (again).
The current code still makes to much assumptions about everything always
being QCOW2 while that is not always true.
CLOUDSTACK-4457:
CLOUDSTACK-4459:
harden kvm getvolume. It's possible that one volume created on other kvm host, won't show up on another host, try more times to refresh storage pool if volume won't shown up
(cherry picked from commit a0de0d0177)
Signed-off-by: animesh <animesh@apache.org>
CLOUDSTACK-4457:
CLOUDSTACK-4459:
harden kvm getvolume. It's possible that one volume created on other kvm host, won't show up on another host, try more times to refresh storage pool if volume won't shown up
Kelven Yang
frank
Edison Su
Chiradeep Vittal
Wei Zhou
Sateesh Chodapuneedi
Mike Tutkowski
Dave Cahill
Wido den Hollander
Bharat Kumar
Min Chen
Wido den Hollander
Animesh Chaturvedi
Anthony Xu