[
https://issues.apache.org/jira/browse/CLOUDSTACK-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561761#comment-13561761
]
Marcus Sorensen commented on CLOUDSTACK-1043:
---------------------------------------------
I wasn't really thinking about network HA when migrating a VM between networks,
but that's an interesting idea to think about.
I think we cut out a lot of the usefulness of the feature if we limit migration
to within a single VPC. One of the key uses is to migrate old VMs on a shared
network into a VPC. Or maybe a user/account has 3 VPCs, and for some reason
decides that they want to give one back and migrate down to two. When I
discussed the add/remove NIC feature in one of my presentations at the
cloudstack conference, I had several people extremely excited about the
prospect of being able to add a nic in order to 'fix' an oversight or rearrange
something in their initial design.
One set of guys had hundreds of VMs that they simply needed to add a network
to, and they had not been looking forward to templating each VM and recreating
it.
Another guy wanted to take advantage of VPCs, but had an existing environment
and no way to easily migrate VMs in.
I think AWS has great ideas, but I think they're focused exclusively on the
cloud model, where the lifecycle of an instance is finite. Many people are
still uncomfortable or unable to leverage such a model, and many CloudStack
deployments are a hybrid model where the lifecycle of a VM is more like a
traditional server.
I think if the security groups apply to the nic, and not the VM, then so long
as the user has proper permissions to use the network and the NIC we should let
them.
As an aside, I worry a bit that many of the feature requests focus too much on
parity with AWS. I see a lot of "AWS style" this or that. It's great to be able
to implement the same features, but I wouldn't want to see cloudstack's
innovation wane and just become a clone of the big guys. Then we limit our user
base to their subset as well and compete more directly, when we could be
capturing interest of those who aren't into the AWS model as well. We can go
ahead and use them as a model in many respects, but when we're building
functional specs let's look at how people will want to use it and improve where
we can.
> Add AWS Style NIC support
> -------------------------
>
> Key: CLOUDSTACK-1043
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1043
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: Future
> Reporter: Simon Waterhouse
>
> The issue is to expose a virtual network interface card (NIC) as a standalone
> entity in the CloudStack API that may be explicitly created/deleted and
> attached/detached from a virtual machine. The intention is to follow the
> pattern pioneered by Amazon with their Elastic Network Interface.
> A desgin document may be found at
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS+Style+NIC+support
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
