[Libguestfs] [PATCH FOR DISCUSSION ONLY 0/2] v2v: Copy static IP address information over for Windows guests (RHBZ#1626503).
Richard W.M. Jones
rjones at redhat.com
Wed Dec 5 14:24:09 UTC 2018
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
More information about the Libguestfs
mailing list