8:24 a.m.
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