Got it, my bad…I saw the previous comments about "convenience builds" but didn't' fully gather the ramifications.
On Jul 26, 2012, at 8:06 AM, Kevin Kluge wrote: My understanding is that the "convenience builds" can include KVM support enabled. The source release will include the code with the build option off. So most users won't notice any changes. -kevin -----Original Message----- From: John Kinsella [mailto:j...@stratosec.co] Sent: Thursday, July 26, 2012 7:46 AM To: <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.org>> Subject: Re: KVM code will be moved to plugin folder So basically for a good portion of CloudStack users, we're removing functionality that they're currently using. Do we have any idea what percentage of CS users compile from source vs use packaged versions? How many users of the packaged product will decide to switch to a different platform where they don't have to jump through hoops to get it to work? If we go this route, and some third party happens to be packaging CS builds with kvm support enabled, would/could the Apache CloudStack download page provide a link to that? I know this has been discussed from a legal/engineering POV, but I'm envisioning some amount of teeth gnashing, just wondering the best way to handle it...I don't want to see headlines "CloudStack removes support for KVM" which is what the more dramatic will say. John On Jul 25, 2012, at 6:00 PM, Edison Su wrote: As kvm code depends on libvirt-java, which is incompatible with Apache license. I want to move it to plugin folder as we already did for other hypervisors, and add a compile option to turn on/off KVM compilation. By default, it's turned off. If you have any patches against agent/kvm code, please check them in ASAP. I want to start the moving in Friday. Any comments? Stratosec<http://stratosec.co> - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella<http://twitter.com/johnlkinsella>