This would seem to violate the license agreement. The license is supposed to be tied to specific hardware not a VM. This sounds like something to be addressed legally rather than technically.
It adds more complexity to a part of Cloudstack that already seems to be a barrier to entry.
Ron On 13/06/2017 9:25 AM, Nathan Johnson wrote:
The title pretty much says it all. Currently mac addresses are automagically generated based on the guru that is responsible for the network type. This would allow that behavior to be overridden by the API on deployVirtualMachine and addNicToVirtualMachine . One potential issue is that if the specified mac address was in the same range of potentially auto-generated mac addresses, there could be a collision, however this could be pretty easily mitigated by just testing for a mac already defined by that network and asking for the next getNextAvailableMacAddressInNetwork. The primary driver for this is to be able to import VMs from other hypervisors / environments where the mac address of the guest would need to stay the same, for instance if a piece of commercial software was tied to the MAC address. I have a working PR here: https://github.com/apache/cloudstack/pull/2143 minus the logic around avoiding collisions where manually specified mac addresses for a network in the same range as those generated by the guru, and the guru generating a collision sometime later. Nathan Johnson R&D Engineer Education Networks of America
-- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
