Page History

Currently, defining an affinity or anti-affinity rule works only at hosts level. I would like to have more detail on the affinity group, extending it at different levels (cluster, pod, zone,..) and also within the same level, being able to add or remove resources from the group.

For hosts and storage pools, administrators can make use of host tags or storage tags to get a similar result. However, the extension of affinity/anti-affinity groups would make the administration easier.

Size of the project: Medium (~175hs)

With regards to IP info reporting, Cloudstack relies entirely on it's DHCP data bases and so on. When this is not available (L2 networks etc) no IP information is shown for a given VM.

I propose we introduce a mechanism for "IP autodetection" and try to discover the IPs used inside the machines by means of querying the hypervisors. For example with KVM/libvirt we can simply do something like this:

            root@fedora35 ~]# virsh domifaddr win2k22 --source agent  
            Name MAC address Protocol Address 
            ------------------------------------------------------------------------------- 
            Ethernet 52:54:00:7b:23:6a ipv4 192.168.0.68/24 
            Loopback Pseudo-Interface 1 ipv6 ::1/128 - - ipv4 127.0.0.1/8 

The above command queries the qemu-guest-agent inside the Windows VM. The VM needs to have the qemu-guest-agent installed and running as well as the virtio serial drivers (easily done in this case with virtio-win-guest-tools.exe ) as well as a guest-agent socket channel defined in libvirt.

Once we have this information we could display it in the UI/API as "Autodetected VM IPs" or something like that.

I imagine it's very similar for VMWare and XCP-ng.

Thank you

An infrastructure outage can take out several or all VMs. In the aftermath it's not always possible to know which VMs were supposed to be ON or OFF, especially if HA is not enabled. People keep powered off VMs around all the time for many reasons.

I propose we add a feature where Cloudstack keeps track of the "last known state" of a VM and after an outage either enforce it (ie start the VM or leave it off) or at least show some information to the operator in the UI/API so they can do it themselves; perhaps make this behaviour configurable in the global settings.

Thanks

Background

CloudStack allows users/operators to perform various operations on the Virtual Machines (VMs). When multiple operations are performed on a VM at the same time, these operations are maintained and sync-ed using the sync queues. Any long running job (eg. volume snapshot) of a VM keeps other jobs in waiting/pending state, and only be picked once the active job is finished. Currently, it is not possible for an operator to list the pending jobs on a VM, cancel or re-prioritise any job if needed.

Requirement

Provision to admin/operator, to the list the pending jobs of a VM, cancel or re-prioritise a job if needed. Also, allow to clear all the pending jobs of a VM.

Add API (and/or UI) support to

• List the active jobs for a VM
• List all the pending jobs of a VM (in queue, by their order of execution)
• Re-prioritise a job from the pending jobs (if possible)
• Cancel any job from the pending jobs

Background

CloudStack allows users/operators to perform various operations on the Virtual Machines (VMs). When multiple operations are performed on a VM at the same time, these operations are maintained and sync-ed using the sync queues. Any long running job (eg. volume snapshot) of a VM keeps other jobs in waiting/pending state, and only be picked once the active job is finished. Currently, it is not possible for an operator to list the pending jobs on a VM, cancel or re-prioritise any job if needed.

Requirement

Provision to admin/operator, to the list the pending jobs of a VM, cancel or re-prioritise a job if needed. Also, allow to clear all the pending jobs of a VM.

Add API (and/or UI) support to

• List the active jobs for a VM
• List all the pending jobs of a VM (in queue, by their order of execution)
• Re-prioritise a job from the pending jobs (if possible)
• Cancel any job from the pending jobs
• Clear all the pending jobs of a VM

Relevant Skills

• Java, MySQL
• Vue.js (for UI)
• Some knowledge of CloudStack and its Job framework

Difficulty

Medium

Potential Mentors

• Suresh Kumar Anaparti
• Any Developer from CS Community

Project Scope/Duration

Large / 350hrs (can be Medium / 175 hours - with reduced scope of API/UI work)

References

• http://docs.cloudstack.apache.org/en/latest/adminguide/index.html#working-with-virtual-machines
• https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+VMSync+improvement
• https://cwiki.apache.org/confluence/display/CLOUDSTACK/Snapshot+throttling+FShttps://FS
• https://cloudstack.apache.org/api/apidocs-4.16/

Future Extensions

This can be extended for other resources (hosts, primary storage, network, etc).
[APIs should take resource type as a param for generic implementation]