Remi Bergsma wrote:
> Hi Nathan,
>
> Great feature! I've also been in situations where we had to keep the mac
> adress the same. Until now hacked the DB to make it happen, so this is
> way better. Will see if I can test it in the coming days.
Thanks Remi! Would
Hi Nathan,
Great feature! I've also been in situations where we had to keep the mac adress
the same. Until now hacked the DB to make it happen, so this is way better.
Will see if I can test it in the coming days.
Thanks, Remi
_
From: Nathan Johnson
Ron Wheeler wrote:
> Does the PR include the documentation changes required to use it?
Currently this is API only, and the API annotations have been updated to
show how it is used. Automatic documentation generation that is currently
used to generate API
Does the PR include the documentation changes required to use it?
Networking is one of the areas where Cloudstack is hard to understand
and difficult to get setup properly.
Anything that adds another option increases the complexity.
Making Cloudstack more difficult to install in order to
Ron Wheeler wrote:
> 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.
>
Possibly, but I don’t think that is so much
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
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