Linux P2V Questions (VMware)

[Billiam29]

Advanced apologies for the long post, but my Google skills have failed me and I have some lingering questions on using the converter for P2V of linux systems. For reference, I'm asking these questions in the context of an environment where there is a dedicated *nix admin that's a different person than the VMware admin.

Question 1

How does the converter "map" the network interface names on a source physical machine to virtual NICs on the destination VM? In other words, will eth0 on the physical source always end up as eth0 on the destination VM; eth1 -> eth1, etc...? Can you bet the house on this as long as the destination VM has the same number of interfaces?

I'm just trying to understand what risks may exist for blowing yourself out of the water if your physical source system has interface-specific iptables rules and/or interfaces on different vlans.

Similarly, I'm trying to understand if you can "leave behind" any unused interfaces on the physical source machine when you convert or if this could be asking for trouble.


Question 2

Any suggested practices for destination network adapter types during the P2V process?

a) Convert with destination NICs as set as e1000 -> install tools -> change NICs to vmxnet3. Any risk of this causing interface name changes?
or
b) Install tools before p2v -> convert with destination NICs set as vmxnet3
or
c) something else?


Question 3

I noticed that the converter seems to want to put the boot partition(s) on their own virtual drive. Is there a specific reason for this?

I can see the benefits of this arrangement. I'm just curious if there's a reason why the converter doesn't seem to allow for other layouts such as having the boot partition(s) on the same virtual drive as the root file system.


Question 4

Any opinions on continuing to use LVM on destination VMs? The little bit I've found on this seems to be that vCenter and the hypervisor don't really care. Do whatever works best for your environment or the system in question.

The only exception possibly being LVM-based thin provisioning where the usual thin-on-thin concerns could come into play.

Agree? Disagree? Overlooking anything?

 

[FnordMan]

Caveat: not a Vmware "expert", just familiar with Linux distros so i'll answer what i'm familiar with.
1: It likely doesn't, expect your eth<x> names to change.
2: b may not work, not sure if the tools will install outside of the VM, if the tools will install than that would be ideal as it'd be the least messy. A will work but will be messy.
1 and 2 sub-note: once you get your networking under control you'll have to edit the udev network file if you want the interfaces to be named what they once were.

 

[Billiam29]

Thanks for the advice against pre-installing the VMware tools FnordMan. It likely saved me multiple headaches.

I'm posting the additional information below in case it's helpful to anyone that's facing Linux P2Vs but still generally learning the ropes with the OS itself. Any corrections or improvements are welcome as I'm still very much in the learning stages with Linux and the nuances of P2V conversion.

After some additional poking around on the networking stuff, it looks like changing the adapter type on existing VM network adapters can be done but it is generally something to be avoided. Therefore, if you P2V'd using e1000 adapters, the best bet for a clean system may be:

convert using e1000 network adapters -> install tools after conversion -> remove e1000 adapters from VM -> add new network adapters using vmxnet3

If you do this, it appears that Linux will probably not remove the network configs for the "original" e1000 adapters. Therefore, your new vmxnet3 adapters could get assigned the next sequential network device names and not assume the same device names as the no-longer-present e1000 adapters.

I created a new VM to test removing/re-adding adapters and will make a separate post below showing the steps I went through. Hopefully that info will be helpful to someone in the future.

 

[Billiam29]

Below are the steps I went through to change a Linux VM from using e1000 network adapters to vmxnet3 network adapters.

Starting Conditions:
- CentOS 6.6 x86_64 VM
- two functioning e1000 network interfaces, different port groups/vlans
- open-vm-tools installed


powered off vm
removed both e1000 network adapters
powered on vm
# noted boot errors attempting to initialize interfaces that no longer exist

looked in /etc/sysconfig/network-scripts
# saw that original ifcfg-eth0 & ifcfg-eth1 were both still present

renamed ifcfg-eth0 & ifcfg-eth1 to original.ifcfg-eth0 & original.ifcfg-eth1
moved original.ifcfg-eth0 & original.ifcfg-eth1 out of /etc/sysconfig/network-scripts

rebooted
# previous network-related boot errors no longer present

powered off vm
added two new vmxnet3 network adapters (NOTE: left MAC address setting as 'automatic')
powered on vm
# no errors or NIC-related messages at boot that I could see

looked in /etc/sysconfig/network-scripts
# saw that no new configuration scripts had been generated. Nothing present for eth[n] interfaces.

ran ethtool -i against eth0 and eth1
# both were present and showed "driver: vmxnet3"

generated new UUID values for vmxnet3 interfaces with "uuidgen eth0" & "uuidgen eth1", recorded values
recorded MAC addresses of new vmxnet3 network adapters from vSphere client, compared against MAC addresses of original e1000 adapters
# NOTE: these did not change from original e1000 adapters even though MAC address setting was left at "automatic" for new vmxnet3 adapters. Coincidence/lucky?

created new ifcfg-eth0 & ifcfg-eth1 in /etc/sysconfig/network-scripts, used newly generated UUID values
verified permissions on new ifcfg-eth0 & ifcfg-eth1 had root,root with 644 like originals
# Noted that original network config scripts had selinux security context (ls of them has dot at end of permissions). Newly created scripts do not.
# Not an issue for me since selinux is disabled on VM in question

rebooted
# Noted standard duplicate IP check messages during boot.

verified basic IP networking functioning as expected