IDE to SCSI

English Virtualization
#1

Hi all,

I have a LEAP 15 system as VM on VMWare ESX host. I would like to change the Virtual Device node type from IDE to SCSI. When i do that on vmware VM settings and start the VM the OpenSUSE LEAP 15 system won’t boot.
What could i do to fix this?

Error:
A start job is running for dev-disk…9763.device (16min 32sec/no limit)

Please help.

#2

First,
Questions like this that are specific to a virtualized deployment are better asked in the Virtualization forum instead of this forum which is more generally focused on general installation installation issues.

Because you’re deployed on ESXi,
AFAIK there has never been an officially sanctioned inexpensive way to manage VMs on ESXi, so you should probably describe how you’re modifying your VM settings… VMware has recommended using ESX(The paid product) although most people probably use the unsupported method to login locally to the command line on ESXi. If you’re doing the latter, then you should provide the command you used to modify just so people can double-check what you’re doing.

You may have to also provide some back story on how you are deploying this virtual SCSI disk, it’s not common for people to do this kind of thing, partly because AFAIK there is no benefit to one connection over another aside from maybe setting up virtual arrays and I’d have to think awfully hard even about how that might be beneficial (Real, physical disk arrays would have obvious benefits, virtual I’m not so sure about because there are other more well known alternatives).

I’d be more inclined personally to just build a new machine with a particular virtual disk connection than try to modify an existing VM.

If you’re importing a VM using an OVMF, these kinds of things should be set up automatically.

TSU

#3

Hi,

Thank you for trying to help me.

I have to start somewhere. Hi, first of all i posted here as this is a “boot” problem. I am using a licensed ESX environment and i changed the virtual hardware provider. I’ve not posted on VMware themed forums as i believe this is a GRUB2/FSTAB/UUID issue or something similar. I’ve done the same on Ubuntu distribution with no issues.
I’ve simply added the well-known LSI SCSI adapter and changed the adapter type from IDE to SCSI on boot drive. GRUB2 boot fine but then it is unable to boot (rootfs or something).
If I change back to IDE adapter the SuSE LEAP15 system boot OK (as usual).
Due to low performance of IDE adapter and the requirement that I need much more virtual disk drives I need to switch to SCSI adapter type.
Could someone please advise, where to look for? What to check? Where to read?

#4

I am with tsu2. Your posts are full of Virtalisation buzz words which I do not understand at all. And I guess that people lurking in the Virtualisation sub-forum will understand at least some of them.

You are wrong when you decide where to post on the base of the piece of software you think ultimately shows the problem. You better choose your sub-forum on the base of the knowledge the people there might have to serve you best.

#5

Hi all,

I have a LEAP 15 system as VM on VMWare ESX host. I would like to change the Virtual Device node type from IDE to SCSI. When i do that on vmware VM settings and start the VM the OpenSUSE LEAP 15 system won’t boot.

Error:
A start job is running for dev-disk…9763.device (16min 32sec/no limit)

If i change back to IDE adapters, everthing works fine.
What could i do to fix this?

Would adapter switch result in UUID change? Any other idea?

Please help.

#6

Tsu2 was referring to the openSUSE forum:
https://forums.opensuse.org/forumdisplay.php/934-Virtualization
which is for
“Questions about virtual machines as hosts and clients and in all operating systems”

There is some crossover in audience, but e.g. I used to participate there while I supported a number of virtual systems, and the people there are more specialized/knowledgable. The forum admins can move threads between sub-forums if asked.

One problem here is that IDE was so long ago that not many will remember /dev/hda etc. Are you able to have both the IDE and ATA/SCSI virtual interfaces available. If so you could use the YasT partition module to transfer the mount points from the virtual IDE devicces (/dev/hdx/) to the equivalent ATA/SCSI devices (/dev/sdx). I am presuming that the emulated LSI SCSI card provides a standard/generic interface and does not require proprietary drivers.

#7

Administrative remark.

A new thread was opened by the OP. As double posting is not allowed (making two conversations about the same subject where people are not aware of each others posts is not very effective), both threads are merged now. Thus the repeated explanation in post #5 above.

#8

Although I haven’t tried to do exactly this kind of modification,

IMO the relevant setting is only in the Guest Properties.
Assuming this virtual machine uses only a single virtual disk, then all partitioning and disk configurations within the disk should not need to be modified.

But,
The disk connection has to be configured properly, and it may not be obvious how to do so.

I have asked what command you used to modify your disk connection setting, and/or whatever tool you used to define the new disk connection. At the very least and perhaps in addition to my request, you should post your vmx file (It’s the configuration file that defines the virtual environment and settings your vm would use).

Or, as I suggested because even with the info I requested I’ve never done what you’re trying to do and never heard of anyone doing such, I highly recommend just creating a new vm with the settings you want. If the machine is very simple, it should take no time re-building the new machine to do what your old machine did, or you can use various methods for transferring/imaging your old disk to your new.

TSU

#9

Am thinking that perhaps disk connection configuration is not understood.

Do you have VMware Workstation or Player installed?
If you do, you can create a simple test VM to experiment and play with, to see how different disk connection configurations are defined and the extent you can modify.

For example
I’m looking at one of my existing VMs in Workstation now.
When I look at the disk properties, it’s already configured as a SCSI (that’s been default for about 8 years plus now) and when I look at available options, none of them include an IDE connection, there are only SCSI LUNs.
That suggests to me that converting from IDE to SCSI or vice versa is problematic. If you want to try, it will require editing the vmx file and then it’s YMMV.

But then, as I’ve noted, I don’t know what your motivation to change from IDE to SCSI might be. I don’t know that there is any benefit to do so AFAIK all virtualized disk connections of any type perform the same.

TSU

#10

TSU,

This change is very simple. Using ESX WEB GUI i added SCSI adapter to VM and changed the (previous IDE) disk to this SCSI adapter. Worked right-away on Ubuntu LTS 16.
Failed with SuSE LEAP 15. Trying to find out why. I’need to do this on lots of VMs. “Reinstall” is not option. I thought that experts here would suggest some solutions other than “forget and reinstall every VM in datacenter…”

So, lets try to add more info:

  1. No mather what adapter i use drives are represented as /dev/sdx devices
  2. LSI drivers are well-known and working fine if i add additional file as SCSI(0:x) drive

OK, what would i need to do to check what are the UUID names when drives are attached over LSI SCSI adapter?https://content.screencast.com/users/IvicaVugrinec/folders/Snagit/media/46cc26e7-c700-4c11-a07a-e05b7001b87a/07.25.2018-19.30.png
https://www.screencast.com/t/AbgN99Dskdr

https://www.screencast.com/t/AbgN99Dskdr

#11

These drivers must be added to initrd, otherwise device with root filesystem is not recognized. If you know which driver is needed you can boot with IDE and use “–add-drivers” dracut option to include them in initrd. After that switch to SCSI should work. Subsequent mkinitrd will automatically add needed drivers.

If you do not know which drivers to add then boot once without additional SCSI drive and once with it and post “lsmod” output in each case.

#12

Hey guys…
All this talk about drivers, configuring LVM and the like are irrelevant.
Those are relevant when you’re talking about physical hardware.

In the described scenario would therefor be relevant only for the initial installation and deployment of ESXi.
Once that is set up, like every other virtualization Guests are completely removed from the physical and need only configure virtual objects.

In this instance, the Guest is originally configured with <virtual> IDE connections to its virtual disks and have no relevance to the underlying hardware. For whatever reason, the @OP wants to change from these <virtual> IDE connections to SCSI which in theory might be possible but IMO questionable (which is why I’ve never heard anyone ask this question before). Note that like any other virtual configuration, it’s perfectly possible to have Guests configured with virtual IDE and SCSI connections and various related configurations like LVM without <any> consideration to what exists in the physical world… the ESXi storage might be IDE, SCSI, mesh fabric(SAN), NAS, or anything else that is imaginable as long as it’s supported by ESXi. The Guests won’t know anything about what is happening in the physical world and won’t care, they will all use the generic VMware storage driver and see and know nothing else.

TSU

#13

You made my day.

#14

OK, Thx,
This is very helpful to know that your are indeed using the ESX tool to manage the Guests on your ESXi.

Is this a screenshot of one of your problem VMs you want to convert?
Some things I’d suggest inspect and compare between VMs you can convert and those you can’t…

  • The current VMware version of each Guest… You may need to upgrade Guests to the latest (or, hopefully not find that only old versions work, AFAIK there is no way to downgrade VMware versions) Also, IIRC some versions of ESXi support only some versions of VMware fully, so the Guest VMware version <is> important and that you know the version of ESXi you’re running and its compatibility requirements.
  • I doubt the LSI connector is important, as you say it’s the most recommended and at one time the only choice that worked reliably. I think that nowadays LSI may not be required anymore…

Although most important things should be reported in your ESX Web tool, keep in mind that for <all> VMware products you can get a full picture only if you inspect and compare the vmx files, so that is one thing I’d suggest to understand if there is something different between the Guests that can be converted and those that can’t.

I may think of other things to check later…

HTH,
TSU

#15

The more I thought about this,
The more I’m convinced that if there is <anything> that might affect how a VM might be configured as you want for some and not others, I can’t think of anything other than incompatible VMware versions (Every Guest should be upgraded as necessary if the base VMware server product is upgraded).

If that’s not a cause,
I can’t think of a likely relevant change that might have happened.
LEAP 15 made some internal storage changes, but those should be strictly internal and should not have affected how a disk is recognized and setup externally. How a disk appears to the overall machine whether virtual or physical is pretty standardized and any changes would be playing with fire, likely unnecessarily.

If after pursuing all the things I suggested (VMware version matching, vmx comparisons),
I’d actually recommend just making your changes by script, particularly if you want to convert a large number of machines…

  • Backup/copy the original vmx file for safekeeping
  • Determine the vmx file modifications you want by diffing (comparing) a modified vm’s vmx vs an unmodifiied
  • Script the necessary changes to any given vmx file.

As I said in my previous post, how you manipulate the vmx file is the <real> power and you can do things that aren’t possible in VMware’s GUI tools (eg I all the time set machines to access the virtual BIOS when they need to boot to an alternate boot device), so it’s not necessarily a bad thing to edit the vmx file directly. Just make sure you have an original copy or it can be very hard or impossible to recover from certain changes like those that are randomly generated.

TSU

#16

FYI
Likely relevant VMware KB article

https://kb.vmware.com/s/article/1016192

TSU

#17

I don’t think so. The UUID is in the file sysem, so not device specific.

However, I would guess that you might need to regenerate the “initrd”. Maybe it is lacking a driver needed for the device.

Maybe run

mkinitrd -A

while it is configured for IDE, and then see if it boots after switching to SCSI.

#18

I had assumed that the boot process should automatically detect and load the required SCSI driver but if I’m wrong the following article describes the full process of building the required SCSI kernel module and loading

http://pubs.vmware.com/esx254/admin/wwhelp/wwhimpl/common/html/wwhelp.htm?context=admin&file=esx25admin_vms.4.12.html

TSU

#19

Had a little time over the weekend to look at this as much as I was able to…
I have Workstation 14 but not an ESX to play around with.

From the above article,
The following info can be extracted and summarized…

The article itself can be boiled down to 3 steps…

  • Install a SCSI disc connector
  • Convert the virtual disk from IDE to SCSI
  • Connect the newly converted SCSI disk to the SCSI disk connector (thereby orphaning the IDE connector that can then be removed if unused and unneeded).

It should be noted that the VMware article assumes and is based on a Windows XP Guest, which is why all the extra steps to install drivers and set up SCSI connectors (with plenty of rebooting). If the Guest is Vista or later, or in our case a current openSUSE version, you should be able to skip a good many steps because

  • All necessary drivers should exist in our Linux kernel already, ready to be used.
  • In my own test, as expected when the system boots, the scsi disk connector added in the Guest Properties is detected automatically on boot and so that part is installed and configured automatically.

So, of the three steps outlined in the article that pretty much means that openSUSE automatically does what is necessary for the first step (detecting and installing the SCSI disk connector) and likely the third step (Connect the disk to the system using the SCSI connector).

I only say the 3rd step <should> work because on my Workstation 14, I found that I couldn’t do step 2, because although the SCSI disk created in step 1 was as described in the VMware article, for some reason the brand new IDE disk created by Workstation 14 did not have the same simple embedded metadata that needed to be changed. Based on what I found in my system, although I couldn’t perform a successful conversion, the following is still what can be learned…

  • Virtual disk files are the same no matter whether they are IDE, SCSI, or something else. The metadata can still be read though to determine what type of data connector the disk should be connected to. In Workstation, this setting is read and determines what connection should be allowed, but this raises the possibility that if the setting is either changed or simply not set or read then simply switching the connection in the ESX Web client is likely possible.
  • The IDE disk created by Workstation 14 did not have the necessary metadata setting, so could not be switched from IDE to SCSI. But, if the IDE virtual disk was created by another version of Workstation or by some other means… Those raise possibilities that conversion should be possible.

So,
Bottom line.
If you can find the metadata setting that specifies an IDE disk connection and you can modify it as described in the article
or
Because as I described it appears that the virtual disks are generic and can be accessed by any connector (IDE, SCSI or otherwise) and you can find a way to force the connection no matter what the disk connection metadata might be set as, for example by using the ESX Web Client,

Then you can be successful where I wasn’t.

HTH,
TSU

#20

So I tested this in my own ESXi cluster and the fix is rather straightforward.

The issue is due to resume= in Leap 15’s grub pointing to a virtual IDE partition/device - edit your grub configuration and remove the resume= or point it to your swap partition - in a VM datacenter environment you’re unlikely to ever need resume so you can simply delete it.

So edit /boot/grub2/grub.cfg and remove all resume= or do it via YAST bootloader.