Companion to the NIC-level URI override -- when an extension declares
vif.binding=lswitch, the Network row itself should advertise
``broadcast_domain_type=Lswitch`` and ``broadcast_uri=ovn://cs-net-<id>``
so listNetworks / details views are consistent with what the OVN
control plane represents.
Without this hook the GuestNetworkGuru still allocated a VLAN at
design time, which leaks back into the UI:
VLAN/VNI: 138
Broadcast URI: vlan://138
Apply the override on a successful ``implement-network`` script return
in NetworkExtensionElement.implement(). The VLAN that the guru
allocated stays as a ghost in op_dc_vnet_alloc -- it is never used on
the wire because the VIF attaches to br-int and traffic flows through
OVN's logical pipeline over geneve. Releasing the VLAN back to the
pool would require intercepting the design phase and is out of scope
for this hook.
Verified end-to-end: i-2-27-VM on network 216 now lists
networks.broadcast_uri = ovn://cs-net-216
networks.broadcast_domain_type = Lswitch
nics.broadcast_uri = ovn://cs-net-216
nics.isolation_uri = ovn://cs-net-216
The OVN NB LSP / OVS iface-id / OVN SB Port_Binding remain bound, as
before.
Delta 1 already overrides nic.setBroadcastType(Lswitch) on the
NicProfile during prepare() so the KVM agent picks the OVS Lswitch
path. But the underlying nics row still carried the cosmetic
``vlan://<id>`` URI allocated by GuestNetworkGuru at design-time, which
is misleading on listNics / DB queries: a NIC sitting on an OVN
logical switch should not advertise a VLAN URI.
Override broadcast_uri and isolation_uri on the NicProfile to
``ovn://cs-net-<networkId>`` (the convention used by the legacy
ovn-plugin) and persist the same on the nics row via nicDao.update.
The VLAN that the guru allocated stays as a ghost in
op_dc_vnet_alloc -- it is never used on the wire because the VIF
attaches to br-int and traffic flows through OVN's logical pipeline
over geneve. Releasing the VLAN back to the pool would require
intercepting the design phase, which is out of scope for this hook.
Verified end-to-end: i-2-24-VM on network 214 now lists
broadcast_uri = ovn://cs-net-214
isolation_uri = ovn://cs-net-214
and the OVN NB LSP / OVS iface-id / OVN SB Port_Binding remain
correctly bound to the chassis, as before.
CloudStack's existing OvsVifDriver already binds NICs correctly when the
NicProfile's BroadcastDomainType is Lswitch: it emits libvirt
<virtualport type='openvswitch' interfaceid='<nic.getUuid()>'/> and
libvirt sets external_ids:iface-id atomically with tap creation. No
agent patch is required for OVS-backed extensions to consume this path
-- they just need (a) a way to opt in, and (b) nic.getUuid() carried in
per-NIC script commands so the SDN-side port identifier can match.
Add the framework hooks to enable this without any KVM agent change:
* ExtensionHelper.VIF_BINDING_DETAIL_KEY ("vif.binding") -- new
top-level extension detail. Currently supported value: "lswitch".
* NetworkExtensionElement.prepare(...) -- when the extension owning the
NIC's network declares vif.binding=lswitch in its extension_details,
override nic.setBroadcastType(Networks.BroadcastDomainType.Lswitch).
OvsVifDriver on the KVM agent then picks the existing Lswitch path
unchanged. Without the opt-in, the previous default (typically Vlan)
is preserved -- existing reference extensions like network-namespace
are unaffected.
* NetworkExtensionElement.getNicUuidArgs(network, nic) -- helper that
returns ["--nic-uuid", "<uuid>"] only when vif.binding=lswitch is
declared. Wired into add-dhcp-entry, remove-dhcp-entry,
add-dns-entry, save-vm-data, save-password, save-userdata,
save-sshkey, and save-hypervisor-hostname. Extensions that do not
declare the hint never see --nic-uuid, so backwards-compatible.
* README -- new section "VIF Binding for OVS-backed Extensions"
documenting the contract end-to-end: cmk createExtension snippet,
what prepare() does, how --nic-uuid flows, why the extension never
writes iface-id remotely on the boot path. Also notes the new
argument in the add-dhcp-entry table.
Result: an OVN extension (or any future OVS-backed extension) gets
correct VIF binding by adding a single detail key at extension creation
time. No host-side agent patch, no libvirt patch, no OVS schema
change.
* PowerFlex/ScaleIO client initialization, authentication and command execution improvements
* Migrate VM with volume not supported yet for PowerFlex/ScaleIO
* review changes
Adds a new request parameter for create/updateExtension API to allow
operator to provide detail names for the extension resources which will be reserved to be used by the extension. The end user won't be able to view or add details with these details names for the resource.
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
* 4.22:
Fix issue when restoring backup after migration of volume (#12549)
Usage: Heartbeat should not schedule usage job when a job is already running (#12616)
Allow limit queries without random ordering (#12598)
engine/schema: fix cluster/zone settings with encrypted values (#12626)
Fix injection of preset variables into the JS interpreter (#12515)
Fix issue with multiple KVM Host entries in host table (#12589)
Add a Prometheus metric to track host certificate expiry (#12613)
ssvm: delete temp directory while deleting entity download url (#12562)
* 4.22:
fix install path for systemvm templates when introducing new sec storage (#11605)
fix Sensitive Data Exposure Through Exception Logging in OVM Hypervis… (#12032)
Fix snapshot physical size after migration (#12166)
ConfigDrive: use file absolute path instead of canonical path to create ISO (#11623)
Add log for null templateVO (#12406)
snapshot: fix listSnapshots for volume which got delete and whose storage pool got deleted (#12433)
Notify user if template upgrade is not required (#12483)
Fix: proper permissions for systemvm template registrations on hardened systems (#12098)
Allow modification of user vm details if user.vm.readonly.details is empty (#10456)
NPE fix while deleting storage pool when pool has detached volumes (#12451)
This PR introduces several configuration settings using which an operator can mark certain cryptographic algorithms and parameters as excluded or obsolete for VPN Customer Gateway creation for Site-to-Site VPN.
Cloud providers following modern security frameworks (e.g., ISO 27001/27017) are required to enforce and communicate approved cryptographic standards. CloudStack currently accepts several weak or deprecated algorithms without guidance to users. This PR closes that gap by giving operators explicit control over what is disallowed vs discouraged, improving security posture without breaking existing deployments.
These settings are:
1. vpn.customer.gateway.excluded.encryption.algorithms
2. vpn.customer.gateway.excluded.hashing.algorithms
3. vpn.customer.gateway.excluded.ike.versions
4. vpn.customer.gateway.excluded.dh.group
5. vpn.customer.gateway.obsolete.encryption.algorithms
6. vpn.customer.gateway.obsolete.hashing.algorithms
7. vpn.customer.gateway.obsolete.ike.versions
8. vpn.customer.gateway.obsolete.dh.group
Wei Zhou
Marco Sinhoreli
Suresh Kumar Anaparti
Daan Hoogland
Henrique Sato
Abhishek Kumar
julien-vaz
John Bampton
Fabricio Duarte
Pearl Dsilva
Erik Böck
Vishesh
Harikrishna
Abhisar Sinha