xvda is not a block device.'¶

Labels: support / question, fixed / solved / done

bspfau opened issue at 2018-03-01 00:03:¶

Relax-and-Recover (ReaR) Issue Template¶

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 2.3 / 2017-12-20
OS version (cat /etc/rear/os.conf ):
OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=7
rear configuration files (cat /etc/rear/local.conf):
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=nfs://xxx.xx.xxx.xx/temp-rear-backups
OUTPUT_PREFIX=
ISO_DEFAULT=automatic
rear-testvm2.log
Are you using legacy BIOS or UEFI boot? BIOS
Brief description of the issue:
I'm using rear to backup a Citrix XenServer 6.5 VM and recover it onto a newly built Red Hat Virtualization 4.2 platform. I'm taking advantage of the "unattended" option so I can automate the migration of a large number of VMs from the one platform to another. I get the error: 'Disk /dev/xvda is not a block device.' and rear instructs me to report this as a bug to this forum.
rear-testvm2.log
Work-around, if any: Use automatic recover and use USER_INPUT_LAYOUTCONFIRM settings

gdha commented at 2018-03-09 14:11:¶

@bspfau What did you modify in the layout configuration?

bspfau commented at 2018-03-09 16:45:¶

Thanks for the reply -- I didn't modify anything in the layout
configuration because I wanted the rear recover operation to just go with
the defaults.

On Fri, Mar 9, 2018 at 7:11 AM, gdha notifications@github.com wrote:

@bspfau https://github.com/bspfau What did you modify in the layout
configuration?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/1745#issuecomment-371822480, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AjOkacHp-zCdIHDBlbAgemX27atbbAJoks5tco2QgaJpZM4SXjXU
.

--
Bunny Pfau
Ace Info Solutions, Inc. (AceInfo) Supporting NOAA
ESRL / Global Systems Division / ITS
Bernadette.Pfau@noaa.gov
(303) 497-4706 / DSRC 2B159

gdha commented at 2018-03-12 13:37:¶

@bspfau Perhaps try recover with debugging options -d -D so we can see more precisely where it fails?

jsmeix commented at 2018-03-12 13:52:¶

I think "using rear to backup a Citrix XenServer 6.5 VM and
recover it onto a newly built Red Hat Virtualization 4.2 platform"
is a system migration and anything can happen in such cases.

I assume "a newly built Red Hat Virtualization 4.2 platform"
is not compatible with "a Citrix XenServer 6.5 VM",
cf. "Fully compatible replacement hardware is needed" at
https://en.opensuse.org/SDB:Disaster_Recovery

@bspfau
in case of a system migration you usually need at least
to adapt your disk layout configuration file (disklayout.conf)
to make it match what there actually is on your new "hardware"
where "hardware" also means a virtual machine.
This is what those various user dialogs request you to do
when MIGRATION_MODE is true.

In case of a system migration onto really different "hardware"
you usually have to addtionally adapt various other things to make
the ReaR recovery system boot and work as you need it on your
new "hardware" e.g. kernel modules adaptions, networking setup
adaptions, bootloader installation adaptions, whatever else...

bspfau commented at 2018-03-14 14:49:¶

Thanks gdha and Johannes for both the replies. I'm following your
suggestions and running the debug recover right now. I'll examine it first
and then incorporate Johannes' suggestion about adapting the disk layout
conf files. When I get further I'll post my findings here before asking
for more direction. Thanks!

On Mon, Mar 12, 2018 at 7:53 AM, Johannes Meixner notifications@github.com
wrote:

I think "using rear to backup a Citrix XenServer 6.5 VM and
recover it onto a newly built Red Hat Virtualization 4.2 platform"
is a system migration and anything can happen in such cases.

I assume "a newly built Red Hat Virtualization 4.2 platform"
is not compatible with "a Citrix XenServer 6.5 VM",
cf. "Fully compatible replacement hardware is needed" at
https://en.opensuse.org/SDB:Disaster_Recovery

@bspfau https://github.com/bspfau
in case of a system migration you usually need at least
to adapt your disk layout configuration file (disklayout.conf)
to make it match what there actually is on your new "hardware"
where "hardware" also means a virtual machine.
This is what those various user dialogs request you to do
when MIGRATION_MODE is true.

In case of a system migration onto really different "hardware"
you usually have to addtionally adapt various other things to make
the ReaR recovery system boot and work as you need it on your
new "hardware" e.g. kernel modules adaptions, networking environment
adaptions, bootloader installation adaptions, whatever else...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/1745#issuecomment-372316698, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AjOkaasj-dr2mypvHN4cRnobyU47gStKks5tdn29gaJpZM4SXjXU
.

--
Bunny Pfau
Ace Info Solutions, Inc. (AceInfo) Supporting NOAA
ESRL / Global Systems Division / ITS
Bernadette.Pfau@noaa.gov
(303) 497-4706 / DSRC 2B159

jsmeix commented at 2018-03-14 15:08:¶

@bspfau
when you work with a self-adapted disklayout.conf
I would like to really recommend to use a current
ReaR upstream GitHub master code as follows:

Basically "git clone" it into a separated directory and then
configure and run ReaR from within that directory like:

# git clone https://github.com/rear/rear.git

# mv rear rear.github.master

# cd rear.github.master

# vi etc/rear/local.conf

# usr/sbin/rear -D mkbackup

Note the relative paths "etc/rear/" and "usr/sbin/".

Reason:
The current ReaR upstream GitHub master code contains a
major rework and changed default behaviour how ReaR behaves
in migration mode when partitions can or must be resized
to fit on replacement disks with different size, see
https://github.com/rear/rear/issues/1731 and its related issues
https://github.com/rear/rear/issues/102 and
https://github.com/rear/rear/issues/1718

Without that new code you may get unexpected partitioning results
that do not match what you had specified in your disklayout.conf, cf.
https://github.com/rear/rear/issues/1731#issuecomment-368018282

bspfau commented at 2018-03-14 15:31:¶

Great info--I'll do that. Thanks, Johannes!

On Wed, Mar 14, 2018 at 9:08 AM, Johannes Meixner notifications@github.com
wrote:

@bspfau https://github.com/bspfau
when you work with a self-adapted disklayout.conf
I would like to really recomment to use a current
ReaR upstream GitHub master code as follows:

Basically "git clone" it into a separated directory and then
configure and run ReaR from within that directory like:

git clone https://github.com/rear/rear.git ¶

mv rear rear.github.master¶

cd rear.github.master¶

vi etc/rear/local.conf¶

usr/sbin/rear -D mkbackup¶

Note the relative paths "etc/rear/" and "usr/sbin/".

Reason:
The current ReaR upstream GitHub master code contains a
major rework and changed default behaviour how ReaR behaves
in migration mode when partitions can or must be resized
to fit on replacement disks with different size, see
#1731 https://github.com/rear/rear/issues/1731 and its related issues
#102 https://github.com/rear/rear/issues/102 and
#1718 https://github.com/rear/rear/issues/1718

Without that new code you may get unexpected partitioning results
that do not match what you had specified in your disklayout.conf, cf.
#1731 (comment)
https://github.com/rear/rear/issues/1731#issuecomment-368018282

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/1745#issuecomment-373055597, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AjOkafaFgknu2I_Gy_NvK8fzYMBgCzXUks5teTKHgaJpZM4SXjXU
.

--
Bunny Pfau
Ace Info Solutions, Inc. (AceInfo) Supporting NOAA
ESRL / Global Systems Division / ITS
Bernadette.Pfau@noaa.gov
(303) 497-4706 / DSRC 2B159

jsmeix commented at 2018-03-14 15:37:¶

@bspfau
I guess you may also need my "very latest greatest changes" in
https://github.com/rear/rear/pull/1758
see my comments therein for a possible reason why.

jsmeix commented at 2018-04-27 11:50:¶

Because "no news are good news" I assume this issue
does no longer happen with current ReaR GitHub master code
(otherwise this issue can be reopened).
If other different issues appear please report each of them
as a new and separated issue here.

[Export of Github issue for rear/rear.]

#1745 Issue closed: unattended recover fails with 'Disk /dev/xvda is not a block device.'¶

bspfau opened issue at 2018-03-01 00:03:¶

Relax-and-Recover (ReaR) Issue Template¶

gdha commented at 2018-03-09 14:11:¶

bspfau commented at 2018-03-09 16:45:¶

gdha commented at 2018-03-12 13:37:¶

jsmeix commented at 2018-03-12 13:52:¶

bspfau commented at 2018-03-14 14:49:¶

jsmeix commented at 2018-03-14 15:08:¶

bspfau commented at 2018-03-14 15:31:¶

git clone https://github.com/rear/rear.git¶

mv rear rear.github.master¶

cd rear.github.master¶

vi etc/rear/local.conf¶

usr/sbin/rear -D mkbackup¶

jsmeix commented at 2018-03-14 15:37:¶

jsmeix commented at 2018-04-27 11:50:¶

#1745 Issue `closed`: unattended recover fails with 'Disk /dev/xvda is not a block device.'¶

git clone https://github.com/rear/rear.git ¶