<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 2:50 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Dec 05, 2018 at 01:18:49PM +0100, Fabien Dupont wrote:<br>
> On Wed, Dec 5, 2018 at 12:01 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>><br>
> wrote:<br>
> <br>
> > On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote:<br>
> > > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones wrote:<br>
> > > > This patch is just for discussion.  There are still a couple of issues<br>
> > > > that I'm trying to fix.<br>
> > ><br>
> > > Sorry if I missed the original discussion on that, but why is copying<br>
> > > the static IP configuraition even considered to be a good thing?<br>
> > ><br>
> > > For one, it's unlikely that the IP address will remain valid in the<br>
> > > target environment.<br>
> ><br>
> > For our v2v conversions (generally from VMware to oVirt or OpenStack)<br>
> > we're trying to maintain a near-identical network configuration on<br>
> > both sides.  So for example a guest will have the same MAC addresses<br>
> > before and after and, if using DHCP, will pick up the exact same IP<br>
> > address (probably served by the same DHCP server) and be able to<br>
> > access the same set of services etc.<br>
> ><br>
> > Also we're doing like 1000s of VMs in one go, so manual<br>
> > reconfiguration of anything is a non-starter.<br>
> ><br>
> > However let me describe the problem we're seeing, as it is a bit more<br>
> > general and might even apply in some cloud scenarios.  If you have a<br>
> > Windows guest which starts out with a static IP address (no DHCP) it<br>
> > might be configured like this on VMware:<br>
> ><br>
> >   00:50:56:01:02:03   192.168.128.10   vmxnet3  "Ethernet0"  EnableDHCP=0<br>
> ><br>
> > After conversion we preserve the MAC address and add virtio drivers,<br>
> > but the new netkvm.sys driver just adds a new network interface so<br>
> > it'll end up like this:<br>
> ><br>
> >   (no hardware)       192.168.128.10   vmxnet3  "Ethernet0"  EnableDHCP=0<br>
> >   00:50:56:01:02:03   (no address)     netkvm   "Ethernet1"  EnableDHCP=1<br>
> ><br>
> > It has no address in the second case because this is a non-DHCP<br>
> > network.  (The DHCP situation is better because the second network<br>
> > will be assigned the right IP address because of the preserved MAC<br>
> > address, although it still has the unnecessary network adapter.)<br>
> ><br>
> > Note that Windows < 10 doesn't have a concept of persistent network<br>
> > names like we do in Linux which mostly solves this problem.  (Windows<br>
> > 10 on the other hand does save the MAC address in the Registry, but I<br>
> > haven't fully investigated yet what it's doing.)<br>
> ><br>
> > Anyway if you have another suggestion how to solve this, I'm all ears ...<br>
> > For other areas we'd fix things up using an Ansible post-copy script,<br>
> > but in this case we can't do that since Ansible cannot reconfigure a<br>
> > guest that has no working network.<br>
> ><br>
> <br>
> As you mention, using Ansible means that the IP address of the VM is<br>
> correctly set.<br>
> In another discussion, you mentioned using transient DHCP, but would mean<br>
> that we reconfigure one of the NICs before conversion to use DHCP. That<br>
> would alter the original VM.<br>
<br>
No I don't think so.  The newly added netkvm NIC seems to come up with<br>
EnableDHCP=1 (although NB I did not test in the end to end case<br>
whether this means the Windows guest will get an address if a DHCP<br>
server is available).<br>
<br>
> And in the case of multiple NICs, how do we know which one to reconfigure.<br>
<br>
The current patch has the same problem.  In the multiple NIC case for<br>
Windows < 10 we don't know how the NICs were assigned to guest<br>
hardware on the source and it seems hard to know without looking at<br>
PCI address assignments which opens up a whole can of worms.<br>
<br>
In Windows >= 10 it looks as if Windows is finally storing the<br>
hardware MAC in the registry associated with each interface, so maybe<br>
this problem will disappear in future.<br>
<br>
> That would be quite specific to each customer, meaning customized<br>
> playbook / role.<br>
<br>
This is correct.<br>
<br>
> And IIRC, there's a good chance that it breaks WinRM configuration with<br>
> regards to certificates, meaning reconfiguring WinRM after DHCP and after<br>
> conversion.<br>
<br>
What is “WinRM configuration”?<br></blockquote><div><br></div><div>I have limited experience with WinRM, but AFAIK it works with SSL certs and they are generated when service is first configured. So, I suspect that if we change the IP address the certificate might become invalid. To be confirmed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> But maybe I'm too pessimistic ;)<br>
> <br>
> <br>
> > > For two, in a typical cloud setup static IP addresses are configured by<br>
> > > some sort of a cloud-specific management agent, and bypassing it is<br>
> > > likely to cause conflicts.<br>
> ><br>
> <br>
> In the case of OpenStack, we keep the MAC address by creating the network<br>
> ports with it and the IP address pre-allocated. This allows neutron to have<br>
> working security groups.<br>
> As Richard says, we're looking at the case of a massive migration where<br>
> adapting the VM is out of scope. It's a mainly a 1:1 relationship. Anyway,<br>
> we're still looking at more complex scenarios with tenant networks and<br>
> floating IPs. It promises to be fun :)<br>
> <br>
> <br>
> > > For three, network configuration is a notoriously complex thing.  I<br>
> > > think I can recall a dozen of network configuration systems in Linux<br>
> > > that claimed to provide the ultimate solution to all problems and none<br>
> > > that delivered to the promise.  I guess in Windows the situation is<br>
> > > hardly much simpler.  Creating yet another universal solution doesn't<br>
> > > appear to be in scope for v2v (if realistic at all); and I'm not sure<br>
> > > that having a very limited solution for a very basic use case only is<br>
> > > better than explicitly telling the user not to rely on v2v for network<br>
> > > configuration.<br>
> ><br>
> > Rich.<br>
<br>
Rich.<br>
<br>
-- <br>
Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones</a><br>
Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br>
virt-top is 'top' for virtual machines.  Tiny program with many<br>
powerful monitoring features, net stats, disk stats, logging, etc.<br>
<a href="http://people.redhat.com/~rjones/virt-top" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones/virt-top</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px!important;padding:0px!important"><b style="font-family:arial,helvetica,sans-serif;font-size:small"><font color="#cc0000"><span style="margin:0px!important;padding:0px!important">Fabien</span> <span style="margin:0px!important;padding:0px!important">Dupont</span></font></b><br></p><p style="color:rgb(0,0,0);margin:0px!important;padding:0px!important"></p><p style="font-size:small;color:rgb(0,0,0);margin:0px!important;padding:0px!important"><span style="font-family:arial,helvetica,sans-serif;font-size:x-small">PRINCIPAL SOFTWARE ENGINEER</span><font size="1" face="arial, helvetica, sans-serif"><br style="margin:0px!important;padding:0px!important"></font></p><p style="font-size:small;margin:0px!important;padding:0px!important"><font face="arial, helvetica, sans-serif" size="1" color="#000000">Red Hat - Solutions Engineering</font></p><p style="margin:0px!important;padding:0px!important"><font size="1" face="arial, helvetica, sans-serif"><span style="margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important"><a href="mailto:fabien@redhat.com" target="_blank"><font color="#0b5394">fabien@redhat.com</font></a></span><font color="#000000">     </font></span><span style="margin:0px!important;padding:0px!important"><font color="#000000">M: </font><a href="tel:+33662784971" style="margin:0px!important;padding:0px!important" target="_blank"><font color="#0b5394">+33 (0) 662 784 971</font></a></span></font></p><p style="margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important"><font size="1" face="arial, helvetica, sans-serif"><a href="http://redhat.com" style="color:rgb(0,0,0)" target="_blank"><img src="https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png" width="96" height="30"></a><font color="#000000">  </font><span style="margin:0px!important;padding:0px!important"><font color="#cc0000"><b>TRIED. TESTED. TRUSTED.</b></font></span></font></span></p><p style="color:rgb(0,0,0);margin:0px!important;padding:0px!important"><font size="1" face="arial, helvetica, sans-serif"><span style="margin:0px!important;padding:0px!important"></span></font></p><div style="color:rgb(0,0,0);margin:0px!important;padding:0px!important"><div style="margin:0px!important;padding:0px!important"><font size="1" face="arial, helvetica, sans-serif">Twitter: <a href="https://twitter.com/redhatway" target="_blank">@redhatway</a> | Instagram: <a href="https://www.instagram.com/redhatinc/" target="_blank">@redhatinc</a> | Snapchat: @redhatsnaps</font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>