I have a SLES 11 SP4 machine that is a VM on a Hyper-V server. I shutdown the VM and exported a copy to a different host for testing purposes of some software.
On the new host, I have successfully imported the SLES VM, but when I turn it on I get disk errors such as:
[CODE]fsck.ext3: No such file or directory while trying to open /dev/disk/by-id/scsi-14253465420202020b55afof5d356d04b9e0aa3747286fdfe-part7
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt and you might try running e2fsck with an alternate superblock: e2fsck -b 8193
/etc/init.d/kbd: line 42: locale: command not found
/etc/init.d/kbd: line 234: find: command not found
Can not find a keymap for us.map.gz, trying fallback.
Loading keymap Loading /etc/defkeymap.map
no /usr/sbin → Numlock off.
Stop Unicode mode.
fsck failed for at least one filesystem (not /)
Please repair manually and reboot.
The root file system is already mounted read-write.
Attention: Only CONTROL-D will reboot the system in this maintenance mode. shutdown or reboot will not work.[/CODE]
The original VM that I exported from runs and boots fine. Thoughts?
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:
Visit http://www.suse.com/support and search the knowledgebase and/or check all
the other support options available.
If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot…
The original VM that I exported from runs and boots fine. Thoughts?[/color]
I haven’t worked with Hyper-V so I can only offer some generic
suggestions.
I assume the new host is also running Hyper-V?
Which version(s) of Hyper-V are running en each host?
What is different about the new host?
Will the VM run if you import it back into the same host? Maybe there
is an issue with the export on the original host (or the import on the
new one)?
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
[QUOTE=bkesting;53690]I have a SLES 11 SP4 machine that is a VM on a Hyper-V server. I shutdown the VM and exported a copy to a different host for testing purposes of some software.
On the new host, I have successfully imported the SLES VM, but when I turn it on I get disk errors such as:
[CODE]fsck.ext3: No such file or directory while trying to open /dev/disk/by-id/scsi-14253465420202020b55afof5d356d04b9e0aa3747286fdfe-part7
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt and you might try running e2fsck with an alternate superblock: e2fsck -b 8193
/etc/init.d/kbd: line 42: locale: command not found
/etc/init.d/kbd: line 234: find: command not found
Can not find a keymap for us.map.gz, trying fallback.
Loading keymap Loading /etc/defkeymap.map
no /usr/sbin → Numlock off.
Stop Unicode mode.
fsck failed for at least one filesystem (not /)
Please repair manually and reboot.
The root file system is already mounted read-write.
Attention: Only CONTROL-D will reboot the system in this maintenance mode. shutdown or reboot will not work.[/CODE]
The original VM that I exported from runs and boots fine. Thoughts?
Thanks[/QUOTE]
I’ve seen similar issues over the years with Hyper-V and SUSE. You can’t move from one system to another with dynamic MACs without some trouble.
The way I fix this is to boot the moved system up to the point I can get command line, go edit /etc/fstab and get rid of every instance if UUID or disk-by-id mention. The issue is the UUID referenced is bogus on the new system. You need to change those to /dev/sda1 etc.
That will get it to boot in my experience.
FYI, its also prone to switch eth0 to eth1 when you do these types of moves…