<div dir="ltr"><div>I can speak to the networking bits...</div><div><br></div>In OpenStack, DHCP doesn't imply inconsistent IP addresses. If you boot a VM without a specific IP address, it keeps the IP chosen for it until you destroy the VM. If you boot a VM with a specific (static) IP address, DHCP serves that IP to the VM. You can disable DHCP, but that tends to break the IP metadata service and therefore requires implementing config drive. The provider network scenarios in the networking guide assume use of config drive.<div><br></div><div>You don't need to consider DVR unless you intend to use private/internal/project networks (i.e., virtual networks that reside completely within OpenStack) in addition to public/external/provider networks and require higher performance and redundancy for private-to-public and private-to-private network routing. If you intend to use private networks, but only for internal communication between two or more VMs on the same private network, you can easily augment the provider networks scenario to support conventional private networks. Alternatively, L3HA provides redundancy for private-to-public and private-to-private network routing, but exchanges the performance increases of DVR for a simpler architecture.</div><div><br></div><div>Also, if you plan to keep your virtual networking simple, did you consider the Linux bridge agent?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 15, 2015 at 5:15 PM, Tyler Couto <span dir="ltr"><<a href="mailto:tcouto@certain.com" target="_blank">tcouto@certain.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
We are moving from vsphere to openstack. Currently I¹m trying to figure<br>
out the easiest way to move my vmdk files over. They are already<br>
integrated directly into our internal network.<br>
<br>
Option 1:<br>
Use provider networks (ie.<br>
<a href="http://docs.openstack.org/networking-guide/scenario_provider_ovs.html" rel="noreferrer" target="_blank">http://docs.openstack.org/networking-guide/scenario_provider_ovs.html</a>) for<br>
VMs with static ip addressing. This way I think I should be able to move<br>
the instances directly over, since they already have IP and MAC info.<br>
<br>
Option2:<br>
Use legacy (or DVR) architecture (ie.<br>
<a href="http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html" rel="noreferrer" target="_blank">http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html</a>),<br>
convert vmdks to qcow2s (?), remove ip, mac, uuid, other unique info,<br>
install acpi, install cloud-init, and boot.<br>
<br>
I would also like to avoid using the provider networks scenario with dhcp,<br>
because I want IPs to be consistent.<br>
<br>
Questions:<br>
Is it possible to use the provider network with static addressing?<br>
Is there a way to programatically modify images (vmdk or qcow2) with the<br>
steps described in number 2 above?<br>
<br>
Thanks,<br>
Tyler<br>
<br>
The opinions expressed herein are expressly my own and not necessarily the<br>
opinions of Certain, Inc.<br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</blockquote></div><br></div>