Description of problem: When migrating Vmware to OSP, if I have selected a security group different from `default` during migration plan creation, migrated instance still gets the default security group. Version-Release number of selected component (if applicable): 5.10.0.27 How reproducible: Believe 100% Steps to Reproduce: 1.Configure the OSP and VMware provider for migration 2.Create Infra mapping and Migration plan(select security group different than `default` while creating plan) 3.Execute plan Actual results: Migration plan finishes and if you check the security group assigned to OSP instance it is `default` even if I had selected different security group Expected results: Security group should be assigned correctly. Additional info: Looking at the snippet from wrapper logs below, I can see security group a8ed95a2-ecd1-4790-b98f-481bf472a902(this was the one I selected) was assigned but when checked the instance in Horizon UI I could see it was not assigned, `default` was assigned which has a different uuid. 2018-11-29 15:30:42,308:DEBUG: Volume at index 1 has id='b5421f99-9d31-47fe-8b8e-de94a92d86cc' (virt-v2v-wrapper:899) 2018-11-29 15:30:57,327:INFO: virt-v2v terminated with return code 0 (virt-v2v-wrapper:1031) 2018-11-29 15:30:57,329:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/ v3', u'--os-project-name=migration', u'--os-password=*****', 'token', 'issue'], environment: {} (virt-v2v-wrapper:1123) 2018-11-29 15:31:03,322:INFO: Transfering volume: b5421f99-9d31-47fe-8b8e-de94a92d86cc (virt-v2v-wrapper:217) 2018-11-29 15:31:03,323:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/ v3', u'--os-project-name=migration', u'--os-password=*****', 'volume', 'transfer', 'request', 'create', '--format', 'json', u'b5421f99-9d31-47fe-8b8e-de94a92d86cc'], environment: {} (virt-v2v-wrapper:1123) 2018-11-29 15:31:10,641:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/v3', u'--os-project-name=migration', u'--os-password=*****', u'--os-project-id=5247facd0f454778a0a1b1dae554efcf', 'volume', 'transfer', 'request', 'accept', '--auth-key', u'3d81a6a0b5d22a3c', u'ca4c6055-7afc-4c09-a565-7bd76d8ee44f'], environment: {} (virt-v2v-wrapper:1123) 2018-11-29 15:31:17,934:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/v3', u'--os-project-name=migration', u'--os-password=*****', u'--os-project-id=5247facd0f454778a0a1b1dae554efcf', 'port', 'create', '--format', 'json', '--network', u'1b39625c-221e-4aad-ace3-a09685ac2634', '--mac-address', u'00:50:56:a5:01:2e', '--enable', u'env-ubuntu16.04-tpl_port_0', '--fixed-ip', u'ip-address=10.19.2.89'], environment: {} (virt-v2v-wrapper:1123) 2018-11-29 15:31:25,511:INFO: Created port id=5a72dab2-312d-40e3-a304-0c8684f7d5aa (virt-v2v-wrapper:255) 2018-11-29 15:31:25,512:INFO: Executing command: ['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://controller.v2v.bos.redhat.com:5000/v3', u'--os-project-name=migration', u'--os-password=*****', u'--os-project-id=5247facd0f454778a0a1b1dae554efcf', 'server', 'create', '--flavor', u'c2fd118e-0cc1-4997-932b-e2f420369335', '--security-group', u'a8ed95a2-ecd1-4790-b98f-481bf472a902', '--volume', u'b5421f99-9d31-47fe-8b8e-de94a92d86cc', '--nic', u'port-id=5a72dab2-312d-40e3-a304-0c8684f7d5aa', u'env-ubuntu16.04-tpl'], environment: {} (virt-v2v-wrapper:1123) 2018-11-29 15:31:36,620:INFO: Removing password files (virt-v2v-wrapper:1350) 2018-11-29 15:31:36,621:INFO: Finished (virt-v2v-wrapper:1372) (END)
In my tests, I also saw that behavior when using the command line. Apparently, when you create an instance with a pre-created port, the security groups are those of the network port, even though you specify another one. So, the fix would probably be to set the security group on the port.
https://github.com/oVirt/ovirt-ansible-v2v-conversion-host/pull/15
https://github.com/oVirt/ovirt-ansible-v2v-conversion-host/pull/14
Yes the security groups are tied to the network which is connected to the host. So it makes sense that the port which gets attached to the instance overrides the security groups before it. I will try and do some lab tests around this as well though.
With CFME 5.10.0.32 ovirt-ansible-v2v-conversion-host-1.9.1-1.el7ev.noarch virt-v2v-1.38.2-12.28.lp.el7ev.x86_64 # Wrapper version VERSION = "12" I was able to successfully migrate an Instance and assign it other than `default` security group, during migration plan wizard, which then was correctly assigned to migrated instance.