#1155 Issue closed: P2V: Is it possible to do a ReaR backup on physical and restore to Vmware host?¶
Labels: support / question, fixed / solved / done
unix1adm opened issue at 2017-01-05 16:20:¶
Relax-and-Recover (rear) Issue Template¶
Please fill in the following items before submitting a new issue (quick response is not guaranteed with free support):
- rear version (/usr/sbin/rear -V): Relax-and-Recover 1.17.2 / Git
- OS version (cat /etc/rear/os.conf or lsb_release -a): Rehl 6/7
- rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
- Are you using legacy BIOS of UEFI boot?
- Brief description of the issue:
I backed up a physical system successfully. I was able to restore to the physical system successfully.
I want to restore the image of the physical system to a VMware client.
However no Ethernet interfaces show up when I boot into the rescue ISO file.
I am assuming that could be because the image did not have the VMware Ethernet drivers so it did not load anything.
Is there a way to get this to work?
I have need to move a physical system to the VM world and was hoping
ReaR would work for us.
P2V was is not giving us what we need.
Thank you in advance for your help.
- Work-around, if any:
unix1adm commented at 2017-01-05 17:48:¶
As an update I tried a vm to a new vm container restore and that worked fine. This makes me think my first assumption is correct about the physical not having the drivers that are needed.
I did have to change the IP manually and the MAC address to be the new nic,
Something interesting when I tried to do a restore of a VM back to its original container. Networking did not get configured as it did on the physical system. I did the following commands to get it working:
a. ip link set dev ens32 up
b. ip addr add
c. ip route add default via
Restore then worked fine.
gdha commented at 2017-01-07 10:56:¶
@unix1adm Have a look at the loaded network drivers of the VM and you
have to make sure that these kernel drivers are copied/loaded on the
physical system before you can do a P2V cloning.
E.g. add
MODULES_LOAD=( "${MODULES_LOAD[@]}" "my_vm_kernel_network_module" )
into /etc/rear/local.conf
jsmeix commented at 2017-01-09 09:07:¶
@unix1adm
what you like to do is not a pure recovery but actually it is
a system migration (from physical to virtual: 'P2V').
In general using ReaR for migrating a system onto
different kind of "hardware" is tricky and depending
on the exact difference it may become a complicated task.
Simply put: The more different the new "hardware" is
the more tricky and complicated the migration it will be.
Regarding P2V system migration
you may have a look at the example in
https://github.com/rear/rear/issues/943
In general regarding special networking setup see
http://relax-and-recover.org/documentation/faq
therein the "IP migration" section and see
https://github.com/rear/rear/issues/819#issuecomment-239458728
and follow the links therein.
unix1adm commented at 2017-01-09 12:23:¶
Thank you for the info.
We tried P2V and it failed that is why I was hoping ReaR would help us
out. I will review the links your provided.
I appreciate the feed back and will post more question if any after I review.
jsmeix commented at 2017-01-12 09:18:¶
Only FYI an untested idea regarding possibly easier migration
of an existing system onto very different new "hardware":
Instead of what I wrote in
https://github.com/rear/rear/issues/943#issuecomment-236129462
... you need to manually adapt the var/lib/rear/layout/disklayout.conf file into something that matches the new "hardware"
I like to suggest to try out if it works perhaps easier
when you do it the other way round:
Instead of running "rear mkrescue" on the old hardware and
then manually adapt the old var/lib/rear/layout/disklayout.conf
file into something that matches the new "hardware"
I like to suggest the following opposite way:
Install a small initial system from scratch on the new hardware
with the disk layout (i.e. partitioning, filesystems, mount points)
as intended for the final system on the new hardware
(e.g. by using the Linux distribution's native installer) and then
run "rear mkbackup" in that initial system on the new hardware
so that you get in particular a var/lib/rear/layout/disklayout.conf
file that matches the intended disk layout on the new hardware
and save the whole var/lib/rear/ directory contents
from the initial system to a safe place.
On the old system run "rear mkbackup" to get primarily
only a backup of the files of the old system.
Then overwrite the initial system on the new hardware
via "rear recover" where you use in particular the
var/lib/rear/layout/disklayout.conf that you made
before in the initial system on the new hardware
and the backup of the files of the old system that
you made before on the old system.
Perhaps you could even use the ReaR recovery system
from the "rear mkbackup" run on the new hardware
because that one should contain the right kernel modules
and other needed stuff that match the new hardware
provided you used for the "rear mkbackup" run on the
new hardware the same backup method as you use
when you run "rear mkbackup" run on the old hardware
to ensure the new ReaR recovery system also contains
the right backup restore tools.
I guess it should work when you overwrite the backup.tar.gz
from the "rear mkbackup" run on the new hardware
with the backup.tar.gz that contains the files of the old system
so that you could run the new ReaR recovery system on
the new hardware and run "rear recover" to get the old
system's files migrated onto the new hardware with the
intended new hardware's disk layout.
Again:
This is only an untested idea.
@unix1adm
I would appreciate it very much if you could provide feedback
whether or not that idea seems to work in general
or if it is perhaps only a nonsese dead end.
jsmeix commented at 2017-01-12 09:24:¶
An addedum:
System software migration at the same time
together with hardware migration cannot work.
At least it cannot work when you intend to use the
ReaR recovery system from the "rear mkbackup" run
on the new hardware.
I.e. when you install the above mentioned initial system
from scratch on the new hardware you must use the same
Linux distribution version that you currently run on your
old hardware to ensure the programs and other files
in the new ReaR recovery system match what you
use on the old hardware.
unix1adm commented at 2017-01-12 12:24:¶
Good Day jsmeix
Well the initial issue I am having is that I cannot even do a recover as
I am missing the ethernet. The backup files are on a nfs share ( I have
them on a Linux system as well as a AIX nfs share.)
but when I boot the system from the ISO file I cannot load anything as
there is no networking to mount the backed up files.
So you are saying to load a basic OS on the new VM container so it has the networking? Then try to overlay a rear restore? I was under the assumption you had to boot from the ISO file to do a restore.
unix1adm commented at 2017-01-12 12:33:¶
On a similar point :
The other thing I am going to be working on is I need to take a backup of a Rhel Linux system on Power then restore it to another Power system as is. Hardware specs are not know at this time but they are in the same family of Power systems. So I am hoping I will be able to restore it.
If I can get the networking going I think a restore will work in this case.
Another question I have is :
I am assuming I can make a backup to ANY nfs mountpoint then copy the
files over to another NFS server (different domain) and then do a
restore.
Now the question I have is with the /etc/rear/local.conf file will be pointing to the OLD nfs server
sample local.conf file:
a. vi /etc/rear/local.conf add the below lines to the end of the file.
UTPUT=ISO
OUTPUT_URL=nfs://192.168.56.1/storage
BACKUP=NETFS
BACKUP_URL=nfs://192.168.56.1/storage
SSH_ROOT_PASSWORD="redhat"
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media'
'/var/tmp' '/var/crash')
NETFS_KEEP_OLD_BACKUP_COPY=
So is there a way to edit this file from the ISO or a command line option to point to the new NFS server?
unix1adm commented at 2017-01-12 13:10:¶
By the way I am not changing the release of the OS. If it is at 6.8 it will stay at 6.8.
jsmeix commented at 2017-01-12 13:45:¶
If your backup is on a remote machine you
need networking in the ReaR recovery system.
I think you cannot boot something else and
overlay that with ReaR with reasonable effort.
What I use and what always works for me
in my network environment to get networking
in the ReaR recovery system is in local.conf
USE_DHCLIENT="yes" SSH_ROOT_PASSWORD="rear"
cf. "First steps with Relax-and-Recover" at
https://en.opensuse.org/SDB:Disaster_Recovery
But in restricted network environments
(e.g. when there is no DHCP server)
you may have to do manual networking setup
for the ReaR recovery system, cf.
NETWORKING_PREPARATION_COMMANDS
in default.conf.
When you copy the ReaR files (in particular backup.tar.gz)
over to another NFS server you need to adapt in the
running ReaR recovery system /etc/rear/local.conf
before you run "rear recover" so that the BACKUP_URL
points to the right NFS share wherefrom "rear recover"
can get the backup.tar.gz to be restored.
In general you can adapt in the ReaR recovery system
anything as you need before you run "rear recover".
For example you can manually type appropriate commands
in the ReaR recovery system to set up networking therein.
didacog commented at 2017-01-12 14:26:¶
Hi @unix1adm,
Regarding P2V to VMWare, the easiest way to do it is to assign e1000 driver to the VM NIC for the initial restore. This should work without issues and linux will recognize it in order you can have the network working, after the recover, reboot, install vmware tools, shutdown, switch the NIC driver to vmxnet and after boot will work as expected and P2V.
Hope this helps.
Regards,
jsmeix commented at 2017-01-12 14:58:¶
@didacog
many thanks for your help regarding possible issues with VMWare.
I don't have VMWare so that I cannot help with its issues.
My KVM/QEMU VMs "just work" for me ;-)
didacog commented at 2017-01-12 15:03:¶
You're welcome @jsmeix! ;)
unix1adm commented at 2017-01-12 17:41:¶
To jsmeix
I think you dotn understand my question. Yes I have to modify the /etc/rear/local.conf file
The initial backup needs to go to a NFS server on a ip 192.168.1.x says
for eample
During the restore it needs ot be changed to point to 192.168.2.x say
How do I get to the local.conf file after the system is booting from the restore ISO file?
If I change it before i take the backup it wont go to the NFS server it needs to for that.
Sorry if I was not clear before.
or are you saying I can backup the system to a local dir on the system then move that file off to another system and restore from that?
The issue I see is that I need to have the tar file on some mount point that rear knows about so it can pull it down and restore the OS.
gdha commented at 2017-01-12 18:31:¶
@unix1adm Just edit /etc/rear/local.conf and change it manually before
starting the recover. As simple as that :-)
unix1adm commented at 2017-01-12 19:20:¶
Are you saying once I boot the ReaR ISO file this can be changed?
That would be simple. I have not had time to try that but I will and report back.
Thank you.
unix1adm commented at 2017-01-12 19:55:¶
Well thank you a bunch. That solution to the part of the restore using a new NFS system worked great. I still have to test physical hardware but in Vm it worked.
jsmeix commented at 2017-01-13 07:56:¶
In
https://github.com/rear/rear/issues/1155#issuecomment-272166335
I wrote
When you copy the ReaR files (in particular backup.tar.gz) over to another NFS server you need to adapt in the running ReaR recovery system /etc/rear/local.conf before you run "rear recover" so that the BACKUP_URL points to the right NFS share wherefrom "rear recover" can get the backup.tar.gz to be restored.
What is not clear about:
"adapt in the running ReaR recovery system /etc/rear/local.conf"
?
unix1adm commented at 2017-01-17 11:56:¶
I am set with this issue for now. Thank you again for the great info.
I will be testing the restore of the Linux on Power this week as I was
able to get the backup successfully.
Crossing fingers the restores goes as smooth.
[Export of Github issue for rear/rear.]