Nvme drive changing number

I have 3 nvme drives (Physical PCB’s) installed. One contaiins my Manjaro host system. Another NVME contains all of the VBox clients I’ve built using VMDK raw metal installs. The third NVME contains backup space.
The issue is, the when I boot the system, intermittantly the NVME that contains the VBox clients changes its NVME number with the backup NVME. IE nvme0n1px becomes nvme1n1px, rendering the VBox clients gone as VBox requires the nvme number when installing the client, IE The nvme number is hardcoded into the vmdk file.
How can I insure that the nvme number remains the same ? (IE I want the client nvme drive to always be nvme0n1pX.)
I’ve been in touch with Gigabyte (Motherboard supplier) and they say it’s the OS that determines the nvme number. Motherboard is x670 Aorus with a Ryzen 7 7700 cpu.

Those arent expected to be reliable. Use UUIDs.


You can’t. Block device names are only temporary and can change any time every boot. Reliable are LABEL, UUID, ID, PATH, PARTLABEL, PARTUUID.

Check this: ls -l /dev/disk/*

Take a look here: Persistent block device naming - ArchWiki


Same problem with an nvme with the MaxIO MAP1602A chip, these had a problem that they were not recognized by the kernel when booting, the patch to fix the problem has this side effect.


You can physically connect to the first slot a disk without the mentioned problem and it will always be nvme0, the other two will change, that’s the best I got.

1 Like

unfortunately for the RawDisk parameter you must specify the absolute device, IE /dev/sdx or /dev/nvme0n. Please reference paragraph 10 of the VirtualBox manual.

1 Like

Can you not use /dev/disk/by-uuid/{uuid}?

Obviously replace {uuid} with the actual UUID.

1 Like

Not sure, without experimentation which is not available right now. Later I can experiment. Don’t think the manual documents that as a choice…

It may or may not be in virtualbox documentation.

nvme0n1 is a device file populated by Linux, it also populates other files that link to the actual device file via names that don’t change, I just showed you one but there are others.

ls -l /dev/disk

If you need the actual disk, rather than a partition, you may need to use another option, eg. by-id.


Virtualbox needs the absolute path to the device, I believe that they mean by “absolute” that the address for the RawDisk parameter that the only acceptable variable is /dev/sdX for SATA drives or /dev/nvme0n1 for m.2 devices, leaving off the last 2 digits (Which specify a particular volume. )
All the displays (blkid, lsblk, ls) do not show a unique identifer (UUID, Label for a whole nvme. Thou there are UUID’s for volumes on the m.2 device.
When specifiing a device to Virtualbox there is an additional parameter that is used to specify the specific volumes but it does NOT override the RawDisk parameter, it is in addition to the RawDisk parameter.

“Absolute” is usually used as the antithesis of “relative”.
A relative path being something like ../disk-2 - notice the path is not a full structure beginning with root, but uses .. to mean ‘from the parent directory of current location’.

More of an example if you dont know what I mean

You have a structure like this:


And the script may contain a line like

mkdir -p ../tempdir

The tempdir will be created in HOME (~).
This is an example of a relative path.


I’m using the term absolute as gleaned from the Oracle VirtualBox manual. Whatever the case, the Vbox clients that I have built that are resident on a NVME m.2 drive using the virtualbox VMDK format work when I specify /dev/nvme0n1 for the RawDisk parameter. I don’t know how to specify a path to a comlete m.2 nvme device other then “nvme0n1” .

Below is the output of “ls -f” that shows the volume UUID’s but no UUID for the m.2 device nvme0n1. As you can see there is no UUID for “nvme0n1” and UUID’s for all the volumes.

│    vfat   FAT16 MINTYEFI         18A2-E813                                           
│    ext4   1.0   misty            3c32b3bb-e032-4745-8267-df4462abccd4                
│    vfat   FAT32 EFI-SYSTEM       010C-9CD5                                           
│    ext4   1.0   rootMX23         d12126f4-b194-4d7d-87c1-e38726ba5095                
│    vfat   FAT32 SPARKYEFI        B63E-87E9                                           
│    ext4   1.0   nvmesparky       dafd4e6f-86d2-46b0-82be-db75dd6101a3                
│    vfat   FAT32                  4597-9383                                           
│    ext4   1.0                    ed157658-68b1-4b06-86ac-fa873c3e624f                
│    vfat   FAT32 EFIPEPPER        BB3E-130D                                           
│    ext4   1.0                    1ec8df44-a79a-4d36-b792-bdb11604f3fd                
│    vfat   FAT32 EFISUSE          BF5B-460D                                           
│    ext4   1.0   suse             19562568-f487-4be4-83ba-c55b2f7d5425                
│    vfat   FAT32                  DE37-8D38                                           
│    ext4   1.0                    3c4e2956-c880-48c3-9bba-420046019b5b                
│    vfat   FAT32 EFIROCKY         BFB7-CC31                                           
│    ext4   1.0   rocky            36d9ccab-2c57-4ee3-bcf5-7fcb4095ce15                
│    vfat   FAT32                  665C-C499                                           
│    ext4   1.0                    564138ce-7272-41bd-b2ed-71d470773d0a                
│    vfat   FAT16                  99F7-A63C                                           
│    ext4   1.0                    60e8811f-4ca2-4e74-80db-d24bf66e7ffa                
│    vfat   FAT32                  5BA0-FF6E                                           
│    ext4   1.0                    833d26d8-7462-4eef-b9ff-648625dd26d1                
│    vfat   FAT32                  F14F-411B                                           
│    ext4   1.0                    709a3c44-5bae-478d-a624-c0ba0b90d958                
│    vfat   FAT32 EFIKALI          22EE-B678                                           
     ext4   1.0   kali             875143bd-e40a-4962-a6ba-4b7dc161e7ba

Unless that was specified, I’d assume it’s the more conventional definition, as described by @cscs (if it starts with a / then it’s an absolute path, otherwise it’s relative).

You may still be right about other options not working, but it seems like an odd limitation.

I did make a suggestion, though it’s actually a namespace not a drive/disk:

$ ls /dev/disk/
by-diskseq  by-id  by-label  by-loop-inode  by-loop-ref  by-partlabel  by-partuuid  by-path  by-uuid

The by-id directory contains symlinks to the device files for drives and namespaces such as nvme0n1, in fact there are several for mine.

$ ls -l /dev/disk/by-id
lrwxrwxrwx 1 root root 13 Jun 20 14:21 nvme-eui.uuid -> ../../nvme0n1
lrwxrwxrwx 1 root root 13 Jun 20 14:21 nvme-WD_BLACK_SN770_1TB_number -> ../../nvme0n1
lrwxrwxrwx 1 root root 13 Jun 20 14:21 nvme-WD_BLACK_SN770_1TB_number_1 -> ../../nvme0n1

So that would give something like this /dev/disk/by-id/WD_BLACK_SN770_1TB_number, which is an absolute path to a symlink which in turn points to a relative path.

I’m not sure if it’ll work…but they’re there for specifying a device file in a reliable manner so it should work.

This is all in the link provided by @megavolt in post 3.


I’ve got the same issue. Tried the Arch wiki ( Persistent block device naming - ArchWiki ) as mentioned above as best as I could understand it but nothing from there worked for me. Damn things kept changing. I gave up on it. Only time I’ve found you have to be careful is if you are doing a system backup / restore.

So you’re trying to use a disk or nvme namespace as a raw disk for virtualbox?

You’re saying the persistent naming schemes weren’t persistent?

What did you try?

I’m actually using a raw installed client in vbox. I can either boot the client volume directly (raw metal) from grub, or boot the client volumes (EUFI + system volumes)
in vobox.
I would like to use persistant naming but too much of a noob to get the picture on what has to be setup in Manjaro.

You use it the same as /dev/nvme0n1, presumably you make a new raw disk.


A quick search brought this up:


1 Like

This may have been true in 2019 but the vboxmanage command has changed to create the RawDisk parameter and entering /dev/disk/by-id/{drive unique id} doesn’t work in vbox 7.0.18. Ive tried.
IE: Here is what I tried, including shortening the “by-id several times”.
sudo vboxmanage createmedium disk --filename nvmetest.vmdk --format=VMDK --variant RawDisk /dev/disk/by-id/nvme-CT2000P3SSD8_2311E6B9B101_1

This was wrong:
sudo vboxmanage createmedium disk --filename nvmetest.vmdk --format=VMDK --variant RawDisk /dev/disk/by-id/nvme-CT2000P3SSD8_2311E6B9B101_1
type or paste code here
should have been:
sudo vboxmanage createmedium disk --filename nvmetest.VMDK --format+VMDK --variant RawDisk --property RawDrive=/dev/disk/by-id/“uniqueid for m.2 device”

The problem is, that the above still points to the m.2 device that is represented by “nvme0n1” . My problem is, that occasionally nvme0n1 does NOT contain the client vbox files.

Actually by-id doesn’t work as it is the same as specifing nvme0n1. My issue is that who ever assigns the value “nvme0n1” to the physical m.2 device is not assigning the value to the same m.2 device, consistantly, weather I specify using by-id or specifing nvme0n1.
The other suggestions point to volumes on the m.2 device. Vbox needs the pointer to the physical m.2 device.