#915 Issue closed: RFE: usecase: automatically clone new virtual machine

Labels: needs sponsorship

jscotka opened issue at 2016-07-14 11:13:

Hi,
I've tested rear and I wanted to use rear for cloning one virt machine to anither one:
cat /etc/rear/local.conf
OUTPUT=ISO
OUTPUT_URL="file:///issoo.iso"
BACKUP=NETFS
BACKUP_URL="iso:///bbbb/"

then using virt-install like:
virt-install -r 2048 -n newrear -f new.img --cdrom rear-rearclient.iso

it is working moreless perfect, but it needs to click in boot menu that I want automatical recovery, and then click 1 that I want to use disc /dev/sda and then 5 to allow resizing of partitions.

I would suggest to have there some option for command rear -v mkbackup
what creates ISO what will be tolerant and fully automated (something like kickstart for installation), no asking, just boot from iso and recover and config first possible disc (in most cases there is one disc, so it could be acceptable)
like: option --force
Regards
Honza

jsmeix commented at 2016-07-15 11:00:

@jscotka
FYI what it means that this issue is set
to "looking for sponsorship" see
http://relax-and-recover.org/support/sponsors

In general regarding contributing see
http://relax-and-recover.org/development/
and
"How to contribute to Relax-and-Recover (rear)" at
https://en.opensuse.org/SDB:Disaster_Recovery

Here my current personal offhanded opinion regarding
ISOs that do a fully automated system installation
(disaster recovery is system re-installation):

I do not like such ISOs because I think
they behave too easily as a descructive pitfall
(just boot with that ISO and your old system is gone).

I would prefer that an explicit confirmation action is needed
by the user before he gets his system re-installed.

I mean not something like "rear mkrescue autorecover"
that has the 'autorecover' confirmation at ISO creation time.

I mean some confirmation at ISO boot time, i.e. something
that is not already hardcoded on the ISO but something
that must be provided "from outside" that makes the ISO
do an automated "rear recover".

But I don't know if one can provide such kind of
confirmation "from outside" at ISO boot time
in an automated way so that in the end you
could get a full automated "rear recover".

For example if one could simulate some keyboard input
via virt-install command line then the virt-install command
could provide that confirmation "from outside".

But this is only some offhanded thoughts because
I am not at all an expert in those areas.

jsmeix commented at 2016-07-15 11:10:

A totally different idea:

A "rear recover" on a "new virtual machine" means
all harddisks on the target system (the "new virtual machine")
are empty (except the disk/CDROM where the ISO is).

Accordingly a full automated "rear recover" might be
possible with reasonably limited risk when there is
a test implemented that errors out if it detects
any data on the harddisks on the target system.

This could make those possibly descructive ISOs
reasonable safe against actually causing damage
(i.e. safe against automatically overwriting a system).

jscotka commented at 2016-07-19 13:08:

I agree with your views, yep, it can be destructive, but I know what I'm doing and in case I add some option like "rear mkbackup --autorecover" or whatever, it should accept my will, that I know what I'm doing.
Your detection if disc is empty or does not contain any partitions also could work.
It is not easy to pass some clicks/keyboard input to virt machine automatically.
I need some way how to do it fully automatic, it is also important for automatic testing of rear. In case there will be some option or method what will detect that disc is empty, it enable possibility to create machine via virt-install, run there some config, run rear, delete machine, create empty disc, use virt-install with ISO and boot machine again.

jsmeix commented at 2016-07-22 11:07:

Only FYI regarding "detect that disc is empty":

I think there could be a relation to https://github.com/rear/rear/issues/799
which is about a "cleanupdisk" script.

When such a "cleanupdisk" script does not find
anything that needs to be cleaned up on the disk
(in particular not any partition on the disk)
then it should mean that the disk is empty.

In short:
Such a "cleanupdisk" script might be somehow usable
to determine whether or not a disk is empty.

gdha commented at 2016-07-25 12:56:

@jscotka to autostart the ISO you can define in /etc/rear/local.conf the variable ISO_DEFAULT=automatic which fixes your first problem.
@jsmeix Perhaps if with above setting we can force a cleanupdisk script then we're all set, no? We can add an additional precaution setting (via the command line or variable).

jsmeix commented at 2016-07-26 07:42:

My plan for the "cleanupdisk" script is that it is run
in any case (i.e. no need to enforce it) but currently
I do not have sufficient understanding to make such
a "cleanupdisk" script in a good way because currently it seems
there are too many uncertainties - at least for my understanding.

Perhaps after rear 1.19 was released I should implement
a first version of such a "cleanupdisk" script so that we can
get user feedback how it works.

I assume such a "cleanupdisk" script cannot cause any harm
(in particular no regression) because I cannot imagine
what could be wrong when such a "cleanupdisk" script
does some first steps to remove step by step stuff
from a used harddisk to make a used harddisk
more and more appear as if it was a new harddisk.

In the end the goal of such a "cleanupdisk" script is
to eliminate the difference between a used harddisk
and a new harddisk.

Because "rear recover" must work at least on a
new replacement harddisk (with same type and size
as the original harddisk was), such a "cleanupdisk" script
should help to avoid issues in "rear recover" that
happen because of leftover stuff on a used harddisk.

jscotka commented at 2016-07-28 09:33:

I'm not sure if it should only work on disc of same type and size. From my POV It would work on any empty HDD size and type are more less irrelevant, or better to say size is important, but size could be same or bigger, but I prefer to autostart recovering without any asking on any type and size.

jsmeix commented at 2016-07-28 11:41:

I think when the target disks (i.e. those disks
were "rear recover" would do partitioning and so on)
are empty, then no existing data would be overwritten,
so that it should be safe to "just do it".

gdha commented at 2017-01-19 09:36:

@jscotka @jsmeix Will check it out within the rear-automated-testing (https://github.com/gdha/rear-automated-testing) project. Currently using PXE, but ISO is in scope as well (but not yet fully implemented). Need some more time.

gdha commented at 2017-08-16 09:32:

@jscotka @jsmeix PXE and ISO can now do an unattended recovery - see as example the config file https://github.com/gdha/rear-automated-testing/blob/master/templates/ISO-booting-with-NETFS-NFS.conf

jsmeix commented at 2017-08-23 16:11:

@jscotka @gdha
to be precise 'an unattended recovery' means here that
after booting the ReaR recovery system "rear recover"
is run automatically which is what is requested here.

But this does not mean that "rear recover" can
run unattended in any case.

For example when the disk size is different
"rear recover" will go into its so called migration mode
and then user dialogs appear to confirm the disk migration.

Also when the network interface has changed there
could be a user dialog to let the user chose the right
network interface in the ReaR recovery system.

Running "rear recover" fully unattended
is something for the future, see in particular
https://github.com/rear/rear/issues/1399

gdha commented at 2017-10-03 15:35:

@jscotka Is your question sufficient answered?

[Export of Github issue for rear/rear.]