Libguestfs - Dec 2018 - Re: [PATCH FOR DISCUSSION ONLY 0/2] v2v: Copy static IP address information over for Windows guests (RHBZ#1626503).

On Wed, Dec 05, 2018 at 12:52:21PM +0000, Roman Kagan
wrote:
> On Wed, Dec 05, 2018 at 11:01:43AM +0000, Richard W.M. Jones wrote:
> > On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote:
> > > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones
wrote:
> > > > This patch is just for discussion.  There are still a couple
of issues
> > > > that I'm trying to fix.
> > > 
> > > Sorry if I missed the original discussion on that, but why is
copying
> > > the static IP configuraition even considered to be a good thing?
> > >
> > > For one, it's unlikely that the IP address will remain valid
in the
> > > target environment.
> > 
> > For our v2v conversions (generally from VMware to oVirt or OpenStack)
> > we're trying to maintain a near-identical network configuration on
> > both sides.  So for example a guest will have the same MAC addresses
> > before and after and, if using DHCP, will pick up the exact same IP
> > address (probably served by the same DHCP server) and be able to
> > access the same set of services etc.
> 
> This doesn't look like an assumption that can be made in general.
I agree this is a somewhat specialized scenario, but our interest in
virt-v2v is liberating VMs off VMware on to our open source products
and the idea is that you get a drop-in replacement without major
changes to how VMs conceptually run.  IOW the result looks more like
vSphere and not much like a public cloud.
> > However let me describe the problem we're seeing, as it is a bit
more
> > general and might even apply in some cloud scenarios.  If you have a
> > Windows guest which starts out with a static IP address (no DHCP) it
> > might be configured like this on VMware:
> > 
> >   00:50:56:01:02:03   192.168.128.10   vmxnet3  "Ethernet0" 
EnableDHCP=0
> > 
> > After conversion we preserve the MAC address and add virtio drivers,
> > but the new netkvm.sys driver just adds a new network interface so
> > it'll end up like this:
> > 
> >   (no hardware)       192.168.128.10   vmxnet3  "Ethernet0" 
EnableDHCP=0
> >   00:50:56:01:02:03   (no address)     netkvm   "Ethernet1" 
EnableDHCP=1
> > 
> > It has no address in the second case because this is a non-DHCP
> > network.  (The DHCP situation is better because the second network
> > will be assigned the right IP address because of the preserved MAC
> > address, although it still has the unnecessary network adapter.)
> 
> ... unless the dhcp client uses unique client-id for each device...
This seems a niche configuration though.  I've only used Linux DHCP
clients in anger and client ID would be specified by machine (although
looking at the docs, I see that you _can_ set it per interface if
you're that crazy :-))
> > Note that Windows < 10 doesn't have a concept of persistent
network
> > names like we do in Linux which mostly solves this problem.  (Windows
> > 10 on the other hand does save the MAC address in the Registry, but I
> > haven't fully investigated yet what it's doing.)
> > 
> > Anyway if you have another suggestion how to solve this, I'm all
ears ...
> > For other areas we'd fix things up using an Ansible post-copy
script,
> > but in this case we can't do that since Ansible cannot reconfigure
a
> > guest that has no working network.
> 
> No I don't have a general solution to this.  But ...
> 
> > > For two, in a typical cloud setup static IP addresses are
configured by
> > > some sort of a cloud-specific management agent, and bypassing it
is
> > > likely to cause conflicts.
> 
> In particular, in Virtuozzo the guests are often configured to get their
> IP configuration from the management layer via a guest agent.  This is
> of course limited in the variety of net configurations that can be
> created in the guest (IIRC only static and dhcp are supported), and also
> allows to apply IP filtering on the hypervisor side.  Then, if desired,
> on v2v the configuration is obtained from the source hypervisor
> (Virtuozzo 6 in our case) and applied on the target (QEMU/KVM-based
> Virtuozzo 7).
> 
> IOW in this case the network configuration is *owned* by the
> management/orchestration layer, not the guest, and it would be a mistake
> to ignore that.
> 
> Dunno if it can be applied in other scenarios, though.
We do have a guest agent running, although only after conversion.

Unfortunately without a working network it cannot collect the required
network configuration.  One possibility then is that we modify the
guest agent so it can read out the required IP address from a
temporary file and set up the network that way, although that it not
very different from the patch I proposed, except using an agent
instead of a hacky Powershell script.

I'm also now hearing that some customers regard DHCP as insecure.
Aarrggh.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v