migration of opensuse 10.3 machine

[r4pt0x]

I have to migrate an open suse 10.3 machine i don't have root access to. It runs a small remote application used on 3 clients within our network.
We've already discussed the virtualization with the company that set up the machine - from the licensing side there's no limitation whether it's installed on a physical or virtual machine. BUT: they won't provide support for migration or the root password and the price for a new installation on the virtual machine is just insane, especially considering the application is rarely used...

So i just started on my own - it's just a linux machine, so how hard can it be?

Live migration via clonezilla worked fine - i got everything transferred to the VM without any errors. Booting also worked after editing the entries at grubs menu.lst

But now i have one major problem:
- if i configure the disk as scsi (as it was on the natively installed machine) the VM won't start up (seems to be a known bug, no solution yet)
- if i configure the disk as ata or virtio i can start the VM and get grub starting the suse installation, but then it won't find the disk by the path set by grub and fstab (/dev/sd* or hd*), so it falls back to "disk by id" path (what obviously won't work with the VM disk) and won't boot...

As i'm not that familiar with suse linux (only worked with debian based distros...) - how different is the process of detecting and mounting drives at startup at suse compared to debian?
At a debian based system i'd just edit the grub entries to /dev/sd* path (worked for the suse machine...) and fstab to mount the "new" device path set by udev at boot (doesn't work for the suse machine..).
The suse system seems to rely on another mechanism because at some point it _always_ looks out for the "device by id" path because the short /dev/sd* (or hd*) path isn't found...


I already found some articles about cloning suse 10.3 machines and they all mention this device-path-problem, but they all just describe what i've already tried: editing the entries of grub/menu.lst and fstab...


Has anyone had similar problems and found a workaround for it?

Maybe setting up an ata disk for grub and attaching the cloned disk via scsi to the VM?

 

[udo]

I have to migrate an open suse 10.3 machine i don't have root access to. It runs a small remote application used on 3 clients within our network.
We've already discussed the virtualization with the company that set up the machine - from the licensing side there's no limitation whether it's installed on a physical or virtual machine. BUT: they won't provide support for migration or the root password and the price for a new installation on the virtual machine is just insane, especially considering the application is rarely used...

So i just started on my own - it's just a linux machine, so how hard can it be?

Live migration via clonezilla worked fine - i got everything transferred to the VM without any errors. Booting also worked after editing the entries at grubs menu.lst

But now i have one major problem:
- if i configure the disk as scsi (as it was on the natively installed machine) the VM won't start up (seems to be a known bug, no solution yet)
- if i configure the disk as ata or virtio i can start the VM and get grub starting the suse installation, but then it won't find the disk by the path set by grub and fstab (/dev/sd* or hd*), so it falls back to "disk by id" path (what obviously won't work with the VM disk) and won't boot...

As i'm not that familiar with suse linux (only worked with debian based distros...) - how different is the process of detecting and mounting drives at startup at suse compared to debian?
At a debian based system i'd just edit the grub entries to /dev/sd* path (worked for the suse machine...) and fstab to mount the "new" device path set by udev at boot (doesn't work for the suse machine..).
The suse system seems to rely on another mechanism because at some point it _always_ looks out for the "device by id" path because the short /dev/sd* (or hd*) path isn't found...


I already found some articles about cloning suse 10.3 machines and they all mention this device-path-problem, but they all just describe what i've already tried: editing the entries of grub/menu.lst and fstab...


Has anyone had similar problems and found a workaround for it?

Maybe setting up an ata disk for grub and attaching the cloned disk via scsi to the VM?

Hi,
clonezilla is the right way. Simply boot in the VM a live-distro like grml - than you can mount the suse-root-partition and change /etc/fstab to mount the right partitions (look with blkid). In this case you can also change the password-hash ;-)
I guess you must also change an udev-rule, because of the nic.

Udo

 

[r4pt0x]

I'm back at the office and just started a new try from scratch (transferred the PM to VM via clonezilla). after editing the menu.lst, re-installing grub at the MBR of the virtual disk i get a working grub which boots up suse 10.3.

The fstab has been edited to /dev/sd* i boot up suse, but it refuses to find any harddrive:

resume device /dev/sda2 not found (ignoring)
Trying manual resume from /dev/sda2
.
.
.
Could not find /dev/sda3
Want me to fall back to /dev/disk/by-id/scsi-SATA_WDC_WD1600AAJS-_WD-WCAP98755404-part3? (Y/n)

When aborting ("n") and looking into /dev there are no drives listed - neither the hard drive partitions (tried virtio or ide), nor the attached CDROM (ide)

Seems like someone tried to save some disk space with installing minimal kernel modules and drivers... (~12GB installation on a 160GB drive...)