Re: [proposal] allow mac address to be specified for vm and nic creation

[Nathan Johnson]

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 very much appreciate independent testing!

Nathan

>
> Thanks, Remi
>
> _
> From: Nathan Johnson  
> >
> Sent: Tuesday, June 13, 2017 3:26 PM
> Subject: [proposal] allow mac address to be specified for vm and nic  
> creation
> To: >
>
>
> 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 Engineer
> Education Networks of America

Re: [proposal] allow mac address to be specified for vm and nic creation

[Remi Bergsma]

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 >
Sent: Tuesday, June 13, 2017 3:26 PM
Subject: [proposal] allow mac address to be specified for vm and nic creation
To: >


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 Engineer
Education Networks of America

Re: [proposal] allow mac address to be specified for vm and nic creation

[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 docs would pick this up.

>
> 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 circumvent a  
> legal agreement seems like a bad idea.
>

This would do nothing to make cloudstack more difficult to install, and  
that is quite a leap to assume that this is circumventing any legal  
requirement.  Specifying mac addresses is available at the OS level for  
practically all operating systems, it’s allowed by most virtualization  
platforms, this is simply exposing an optional feature.   We happen to have  
a specific use case for it.  This does nothing to increase complexity for  
the operator, if you don’t use this feature then existing behavior is  
preserved.  It does add a marginal amount of complexity to the networking  
codebase, but the added bits do have unit and integration test coverage.

> Ron
>
> On 13/06/2017 9:49 AM, Nathan Johnson wrote:
>> 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 a cloudstack concern as the
>> users of cloudstack.
>>
>>> It adds more complexity to a part of Cloudstack that already seems to be
>>> a barrier to entry.
>> This feature is actually to address a current barrier to entry for one of
>> our customers.
>>
>> Nathan
>
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102

Re: [proposal] allow mac address to be specified for vm and nic creation

[Ron Wheeler]

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 circumvent a 
legal agreement seems like a bad idea.


Ron

On 13/06/2017 9:49 AM, Nathan Johnson wrote:

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 a cloudstack concern as the
users of cloudstack.


It adds more complexity to a part of Cloudstack that already seems to be
a barrier to entry.

This feature is actually to address a current barrier to entry for one of
our customers.

Nathan



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [proposal] allow mac address to be specified for vm and nic creation

[Nathan Johnson]

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 a cloudstack concern as the  
users of cloudstack.

> It adds more complexity to a part of Cloudstack that already seems to be  
> a barrier to entry.

This feature is actually to address a current barrier to entry for one of  
our customers.

Nathan

Re: [proposal] allow mac address to be specified for vm and nic creation

[Ron Wheeler]

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 Engineer
Education Networks of America




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

[proposal] allow mac address to be specified for vm and nic creation

[Nathan Johnson]

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 Engineer
Education Networks of America