NVMe madness

[Fog_Newb]

@Sebastian-Roth

I copied over the updated init.xz to

/var/www/html/fog/service/ipxe/

Then set the host primary disk to 1000204886016 and attempted to capture

It worked great

Thank you very much

[Sebastian Roth]

@Fog_Newb said in NVMe madness:

Then set the host primary disk to 1000204886016 and attempted to capture

So this was capturing the one tera byte disk, right?

[Fog_Newb]

@Sebastian-Roth

Yes.

[Fog_Newb]

@Sebastian-Roth

So yes, this is a perfect solution since Primary host disk can now be set by size. I have one image for the OS disk, and one for the “D” drive. I just switch the Primary Host disk setting depending on which image I want to capture or deploy.

[Sebastian Roth]

This is committed to the fos repo and will be available in the next release.

@Tom-Elliott Should we re-phrase the name of that field or just leave it like that and add this information to the documentation?

[Tom Elliott]

@Sebastian-Roth I think leave as is but update documentation.

[Sebastian Roth]

@JJ-Fullmer @Jurgen-Goedbloed Would one of you take care of adding this new feature to the documentation?

[Tom Elliott]

@Sebastian-Roth hmmm what about a new field specifically designed for the size? If hard drive specified default to that, else if size specified match drive based on that?

[Sebastian Roth]

@Tom-Elliott But why have another file if they can’t be used in combination anyway? It’s either or!

[Tom Elliott]

@Sebastian-Roth that’s what I mean. If you have specified the hdd use that. If hdd not found but you have size defined, try to find matching size. If both or either defined but not exist error out.

[Quazz]

@Tom-Elliott I kind of like that idea of a fallback mechanism, but I fear that it would kind of nullify what it’s trying to solve in a way.

Few people would know about the NVME naming scheme being essentially random on each boot and thus may presumably fill in the name of the drive. This would then get used and the size (if filled in) would be ignored.

I think if it were to be implemented as such, then the GUI should inform to use size over name for NVME drives.

PS: What happens when you have 2 identical drives?

[Sebastian Roth]

@Quazz Right, using a second field will just allow for people to confuse things. While we try to give people more responsibility instead of trying to solve all things within the code I don’t think adding another field is valuable in this term. It’s a simple case of either or in one field and there is no situation where specifying both size and dev name at the same time makes sense.

PS: What happens when you have 2 identical drives?

I have thought about this while implementing the multi disk NVMe code and this new stuff as well but I don’t think there is any possible way we can help people with two identical sized disks. If we store disk identifiers (globally unique) it cannot be deployed to a different target machine. As far as I see size is the only parameter helping us to solve this dilemma.

[Fog_Newb]

@Sebastian-Roth

Quick question. Does 1.5.9.36 dev build have these NVME related intits?

[Sebastian Roth]

@Fog_Newb No, not yet.

[Fog_Newb]

@Sebastian-Roth

Thanks. I updated and instead of checking I got lazy and posted. Where can I find info on what’s changed in each dev build? Github didn’t seem to have anything listed.

[Sebastian Roth]

@Fog_Newb Every dev version is just one single new commit to the dev-branch. So you know what changed looking at the commit history on github.

[Fog_Newb]

@sebastian-roth

Thanks.

[JJ Fullmer]

@fog_newb I suggest bookmarking https://github.com/FOGProject/fogproject/commits/dev-branch
So you can do a quick check for updates on the dev-branch anytime

@Sebastian-Roth So, just so I’m documenting the right thing.
Should I update the field’s documentation here https://docs.fogproject.org/en/latest/management/host-management.html#primary-disk
With a note (and a link to this forum post) that you can put either the devname or the exact blocksize/sector count with the linux command to find said sector count. Is that command accessible in the fog debug console? It looks like in windows you can use the powershell command get-disk | select Number, "FriendlyName", Size to list available disks by number and friendly name and display the blocksize. So it can be found fairly easily in Windows and Linux.

Is just adding a note by the field enough, or should there be a separate page explaining nvme selection?

[Fog_Newb]

@jj-fullmer

Thanks. That is exactly what I did.

[Sebastian Roth]

@JJ-Fullmer said:

Should I update the field’s documentation here https://docs.fogproject.org/en/latest/management/host-management.html#primary-disk

I had this on my list for a long time but somehow lost track of this, sorry.

The command on the FOS debug console would be: blockdev --getsize64 /dev/nvme0n1 (or whatever disk you want to get the block count from, e.g. /dev/sda)

It looks like in windows you can use the powershell command get-disk | select Number, "FriendlyName", Size …

Could be right but I am not exactly sure. Would you be able to verify this is the same number as we get from blockdev --getsize64 ... on a few systems?

Is just adding a note by the field enough, or should there be a separate page explaining nvme selection?

From my point of view adding this as a note is enough. The current explanation is pretty short and we might also add some examples.