cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Angus <>
Subject RE: KVM CloudStack Agent Hacking proposal
Date Tue, 23 Oct 2018 06:55:48 GMT
Hi Ivan,

I think that this may already have been added in 4.12 by ShapeBlue

if nothing else it sounds like you want to build upon this rather than rewrite it.

Amadeus House, Floral Street, London  WC2E 9DPUK

-----Original Message-----
From: Wido den Hollander <> 
Sent: 23 October 2018 07:46
Subject: Re: KVM CloudStack Agent Hacking proposal

On 10/22/18 8:02 PM, Ivan Kudryavtsev wrote:
> Hello, Devs.
> I would like to introduce a feature and decided to consult with you 
> about its design before implementation. The feature is connected with 
> KVM CloudStack agent. We have found it beneficial to be able to launch 
> custom scripts upon VM start/stop. It can be done using Qemu hook but 
> it has several drawbacks:
> - the hook is deployed by CS and adding additional lines into it leads 
> to extra efforts when ACS package is updated.
> - it leads to deadlocks as you cannot effectively and easy to 
> communicate with libvirt from hook even with "fork & exec" because 
> and agent also participate and as a result it causes deadlocks.
> Now, in the code, we have a call for "":
> Start:
> 117efc0248a5/plugins/hypervisors/kvm/src/main/java/com/cloud/hyperviso
> r/kvm/resource/wrapper/
> Stop:
> 117efc0248a5/plugins/hypervisors/kvm/src/main/java/com/cloud/hyperviso
> r/kvm/resource/wrapper/
> I would like is to introduce a more generic approach, so the 
> administrator can specify additional scripts in the, 
> which will be called the same way "" called.
> custom.vm.start=/path/to/script1,path/to.script2
> custom.vm.stop=/path/to/script3,path/to.script4
> So, this feature will help users to do custom hotplug mechanisms. E.g. 
> we have such implementation which adds per-account VXLAN as a hotplug 
> ethernet device. So, even for a Basic Zone, every VM gets automatic 
> second NIC which helps to build a private network for an account.
> Currently, we do the job thru adding lines into, 
> which is not a good approach, especially for end users who don't want 
> to hack the system.
> Also, I'm thinking about changing /etc/libvirt/hooks/qemu the same 
> way, so it was just an entry point to  /etc/libvirt/hooks/qemu.d/* located scripts.
> Let me know about this feature proposal and if its design is good, we 
> start developing it.

Seems like a good thing! It adds flexibility to the VM.

How are you planning on getting things like the VM name and other details to the scripts?


> Have a good day.
View raw message