Hi,
+1
Same exact issue here. This seems to be a behavior change from 1.5 to 5.1. Any suggestions are appreciated.
What version of VCD are you using and is this an Appliance or the full blown install inside RHEL ?
I'm seeing the same issue with a customer I'm working with but its in their PoC environment.
Hi Gary,
we are using RHEL and not the appliance. I have tried this in vCD version 5.1.1.868405 and in version 5.1.0.810718 and both gives me the same result.
I am in the same boat. 5.1.1 upgraded from 1.5 if that matters. Seems like a bug to me.
Hi all,
Yes, the fact that IP allocation method is not saved on capture (you can see that if you open properties of VM inside the template) and later is not selected as default in "Add to My Cloud..." wizard (for "Customize VM settings" case) looks to me like a bug. We'll log it into our internal database.
While for "Customize VM settings" there is an easy UI workaround (which is to use "Switch to the advanced networking flow" flag in the "Add to My Cloud..." wizard), I don't think there is a simple one for the "Identical" case. Fixing that would require to run "update" statements against database.
//Andrii
Thanks for recognizing it is a bug. Can you please let me know if there is a workaround (even if it means updating the database) to set those captured machine's IP Mode?
We start up a number of machines via the API and we are expecting the network adapter to be in Static Pool mode so we can't rely on the wizard to be able to change that setting.
Thanks
Rich
Hi Rich,
I believe you have two options:
1) Since you use API anyway, you could provide additional sections which would set IP Mode. This is of course ugly, but doesn't require touching database
2) You could follow approach similar to what's described in http://kb.vmware.com/kb/2038286 (same kind of issue with guest customization)
I very quickly put these queries together, so those aren't tested much. Please make sure you backup your database and apply those VM by VM doing additional checks similar to what's described in that KB.
Here it goes:
-- I'm not 100% sure about this join, but it seems to work
select nic.nic_id, nic.mac_address, nic.ip_addressing_mode from network_interface as nic
inner join vapp_vm as vm on nic.netvm_id = vm.nvm_id
where vm.name='cap-vm';
-- based on results of the above
select * from network_interface as nic
where nic_id = 0x1033801D07904696B93AC03456D67722
update network_interface
set ip_addressing_mode = 1
where nic_id = 0x1033801D07904696B93AC03456D67722
0 - None
1 - Static Pool
2 - Static Manual
4 - DHCP
Hope that helps!
//Andrii
One correction: "Identical" case seems to be working fine without workaround. So it's only issue with "Customize VM settings".
//Andrii
Thanks Andrii. I will check out solution 2 since there are some legitimate cases for a vAppTemplate to be set to use DHCP. I will update with any issues I find. Thanks for the quick reply. This issue had the potential to derail our development efforts and you came through.
Rich
Just an update. Between the KB and the query you have provided, I am able to update the nic on the VM's in the vAppTemplate to use Static Pool. Here is the final sequence of queries that I executed:
select id from catalog where name='<catalogName>';
select entity_id from catalog_item where name='<vAppTemplateName>' and catalog_id=<id>;
select * from vapp_vm where vapp_id=<entity_id> and name='<vmName>'
select nic.nic_id, nic.mac_address, nic.ip_addressing_mode from network_interface as nic
inner join vapp_vm as vm on nic.netvm_id = vm.nvm_id
where svm_id=<svm_id>
(this is not really necessary) select * from network_interface as nic
where nic_id = <nic_id>
update network_interface set ip_addressing_mode = 1 where nic_id = <nic_id>
Thanks again for your help!
update network_interface set ip_addressing_mode = 1 where nic_id = <nic_id>
Thanks again for your help!
Yes, that looks correct. Is it working fine for you now?
//Andrii
Yes things work great now. Is this bug entered into your system or should I take an additional step to log this? (if so how?)
Rich
Anyone who encounters this issue should file an SR
I did not have this issue in 1.5 either but any vApp Template created/moved/copied in 5.1.0.810718 does. I'll file an SR today.
I've changed the query above for MSSQL to use variables in order to update the DB easier. Here's what I used to update our DB:
DECLARE @Catalog varchar(80)
DECLARE @vAppTemplate varchar(80)
SET @Catalog = 'catalogName'
SET @vAppTemplate = 'templateName' -- May need % at the end in case vApp Template was copied/moved. May get multiple returns though so be careful.
update network_interface set ip_addressing_mode = 1
where nic_id = (select nic.nic_id from network_interface as nic inner join vapp_vm as vm on nic.netvm_id = vm.nvm_id where svm_id=(select svm_id from vapp_vm where vapp_id=(select entity_id from catalog_item where name like @vAppTemplate and catalog_id=(select id from catalog where name = @Catalog))))
Eric
This bug will be fixed in the next maintenance release which will come in a few months. For anyone who needs the fix sooner, there will soon be a hotpatch available that fixes this issue. To get the hotpatch, you need to file an SR and request the hotpatch.
This bug has been fixed in the vCloud Director version 5.1.2