I’ve been running this on Nutanix CE (KVM based platform) without issue for the last year or so. I recently had to rebuild the CE node and I’m having issues with the virtual disks that I never had before. I’ve tried multiple versions of Rockstor (3.8-12 -> 3.8-14 -> 3.8-14.10) and have failures trying to create pools (unless I use a tiny vdisk - i.e. 10 GB) and also zero luck enlarging pools. A typical error listed below.
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py”, line 40, in _handle_exception
yield
File “/opt/rockstor/src/rockstor/storageadmin/views/pool.py”, line 275, in post
add_pool(p, dnames)
File “/opt/rockstor/src/rockstor/fs/btrfs.py”, line 53, in add_pool
out, err, rc = run_command(cmd)
File “/opt/rockstor/src/rockstor/system/osi.py”, line 104, in run_command
raise CommandException(cmd, out, err, rc)
CommandException: Error running a command. cmd = [’/sbin/mkfs.btrfs’, ‘-f’, ‘-d’, ‘single’, ‘-m’, ‘single’, ‘-L’, ‘A-pool’, ‘/dev/disk/by-id/sdc’]. rc = 1. stdout = [‘btrfs-progs v4.6’, ‘See http://btrfs.wiki.kernel.org for more information.’, ‘’, ‘’]. stderr = [“Failed to check size for ‘/dev/disk/by-id/sdc’: No such file or directory”, ‘’]
I’ll be honest - I’ve seen all manner of issues with the disks and pools after rebuilding the server. I’ve reinstalled a number of times but no joy. Removed disks - added new ones etc etc.
Are these known issues or are they specific to my implementation?
@dannyboy1121 A belated welcome to the Rockstor community.
Note sure about earlier versions producing this error but this can result from ignoring the big red warning against disks on the “Disks” page due to device serial issues. But again this particular error would only be in later versions since we changed to the by-id type disk naming. But if a drive has no serial it can’t be tracked by Rockstor and is thus not supported, hence the warning; we are still a little unrefined in this regard but further improvements are in the works. Please see Device management in Rockstor for a current explanation for this area of Rockstor in more recent versions.
If you present a particular scenario that is not working for you where all the disks in question are without the big red label, ie they have valid and unique serials and then the resulting error we may well be able to address that particular issue, otherwise it’s a little like shooting in the dark and ultimately more frustrating than need be for all parties. Most core functions as you describe are mostly well behaved but only in sane circumstances such as all devices having unique serials. So I would look first to that element of your setup first as it’s is not usual to have quite the level of dysfunction you are apparently experiencing. Especially since it seemed to be working for you in the past. Maybe the rebuild left out some device serial attribution element that was in effect previously.
Maybe a screen shot of the Disks page would help info wise as this is a bit of a puzzler.
I had a look in /opt/var/log … the most recent entries appeared to be in gunicorn.log (not sure if this is relevant - probably not):
So - not exactly the same issues as seen before and now I’ve managed to get a pool up and running. My gut feeling is that it’s something to do with the nature of the virtual platform I’m using. Probably not a regular way to provision storage for Rockstor.
@dannyboy1121 Sorry for the slow response here. If you still have this same setup could you post a fresh screen shot of the disk page and the output of the following command:
ls -la /dev/disk/by-id/
As I suspect you will encounter issues with newer by-id using versions of Rockstor (currently testing channel updates only) given the incredibly long serial numbers displayed in your previous screen grabs.
Yes this arrangement does seem to be allocating very long serial numbers hence my request for the full by-id names, and to see if they are being created at all.
The next stable release of Rockstor will have issues with device path names longer that 64 chars and the fix is simple but it would be helpful to see if there is more to it than this before making changes, ie if there are in fact any udev created by-id names for these disk mappings, hence my ‘ls -la’ request previously, if not then things are a little less simple and will require a more complex fix to support these specific devices going forward.
@dannyboy1121 Just a note that as of the next stable release of Rockstor you may well experience issues due to these very long serial numbers and the unknown state of the by-id symlinks that Rockstor as of version 3.8-14.02 depends upon.
I have created an issue so that this might be addressed and linked back to this forum thread.
If you could respond with the output from the command specified in my penultimate post prior to this one we might be able to address this issue, or at least avoid it’s impact on your setup going forward.
@dannyboy1121 That’s great cheers, I have updated the issue accordingly and will try and get the required changes ready for review soon. My apologises for not spotting this future issue sooner. I would advise that you not upgrade to the next stable release of Rockstor on this platform until this issue is resolved as although your normal un-partitioned (data) disks will be fine the Rockstor database will fail to accommodate the partitioned system disk due to it’s by-id name being 4 characters too long. Fancy that. This is turn will have undetermined consequences for Rockstor’s base functions.
Thanks again for your contribution on this issue and hopefully once this has been sorted we can work on sorting out other specific issues with this platform as they are identified. I will update this forum thread on the resolution of the issue opened on it’s behalf.
As of Rockstor testing channel update version 3.8-14.22 the potential problem with the next stable release with your very long nutanix serial numbers and consequent by-id names should no longer exist as the GitHub issue opened as a result of this forum thread has now been closed. This fix should end up in the next stable release so my previous concerns over your long device names in the current testing channel updates and consequently the next stable channel update no longer apply.
