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.
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>
This PR introduces console access support for instances deployed using Orchestrator Extensions, available via either VNC or a direct URL.
- CloudStack queries the extension using the getconsole action.
- For VNC-based access, the extension must return host/port/ticket details. CloudStack then forwards these to the Console Proxy VM (CPVM) in the instance’s zone. It is assumed that the CPVM can reach the specified host and port.
- For direct URL access, the extension returns a console URL with the protocol set to `direct`. The URL is then provided directly to the user.
- The built-in Proxmox Orchestrator Extension now supports console access via VNC. The extension calls the Proxmox API to fetch console details and returns them in the required format.
Also, adds changes to send caller details to the extension payload.
```
# cat /var/lib/cloudstack/management/extensions/Proxmox/02b650f6-bb98-49cb-8cac-82b7a78f43a2.json | jq
{
"caller": {
"roleid": "6b86674b-7e61-11f0-ba77-1e00c8000158",
"rolename": "Root Admin",
"name": "admin",
"roletype": "Admin",
"id": "93567ed9-7e61-11f0-ba77-1e00c8000158",
"type": "ADMIN"
},
"virtualmachineid": "126f4562-1f0f-4313-875e-6150cabeb72f",
...
```
Documentation PR: https://github.com/apache/cloudstack-documentation/pull/560
---------
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
* api,server,extensions: allow updating extension resource map details
This PR makes changes for allowing updating details for an extension resource mapping.
Currently, extensions only support Cluster to be registered therefore changes has been added to updateCluster functionality.
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
The Extensions Framework in Apache CloudStack is designed to provide a flexible and standardised mechanism for integrating external systems and custom workflows into CloudStack’s orchestration process. By defining structured hook points during key operations—such as virtual machine deployment, resource preparation, and lifecycle events—the framework allows administrators and developers to extend CloudStack’s behaviour without modifying its core codebase.
Wei Zhou
Marco Sinhoreli
Suresh Kumar Anaparti
Daan Hoogland
Abhishek Kumar
Erik Böck
Harikrishna Patnala