|Summary:||Increase VM_MAX_NAMELEN value|
|Product:||Base System||Reporter:||Mateusz Kwiatkowski <kwiat3k>|
|Component:||kern||Assignee:||Rodney W. Grimes <rgrimes>|
|Severity:||Affects Some People||CC:||kwiat3k, pawel.biernacki, rgrimes, scottl, swills, virtualization|
Description Mateusz Kwiatkowski 2018-12-18 13:52:11 UTC
Currently VM_MAX_NAMELEN is set to 32 and thus the maximum length of virtual machine is 31 characters. We’re building product that uses bhyve to run virtual machines and we wanted to use UUIDs as names for VMs. UUID with hyphens has 36 characters and without it has 32 characters. Can this limit be increased to 33 and ideally to 37 or more characters? For comparison qemu-kvm+libvirt allow for virtual machines with names that are over 240 chars. I've tested hypervisor with VM_MAX_NAMELEN to 64 on stable/12 branch and didn't experience any issue.
Comment 1 Rodney W. Grimes 2018-12-18 17:30:32 UTC
A little bit of code work to change this into a dynamically allocated string and then raise the limit to pathmax is probably in order. This constant was just a fast path to deployed code.
Comment 2 Mateusz Kwiatkowski 2018-12-18 19:24:22 UTC
Rodney, thank you for your answer. Are you going to work on this soon? If not can we have it just bumped to 64 for now?
Comment 3 Rodney W. Grimes 2018-12-18 19:57:05 UTC
I have bhyve work planned over the week between christmas and new years, I have also added virtualization to the CC: list, and am sending an email to have this issue added as a topic for the next bhyve conference call (early January).
Comment 4 Mateusz Kwiatkowski 2018-12-18 19:58:07 UTC
That sounds great. Thanks!
Comment 5 Mateusz Kwiatkowski 2019-02-08 09:41:27 UTC
Hi Rodney, Did you have a chance to take a look on this issue? Thanks!
Comment 6 Rodney W. Grimes 2019-02-08 15:55:57 UTC
(In reply to Mateusz Kwiatkowski from comment #5) Some how I let this slide off the radar, this bug is now on the PR list for the bi-monthly bhyve developers call and shall be discussed at the next meeting on February 21, 2019. As long as there are no issues with doing this I'll create a phabricator review and get this enhancement moved forward.
Comment 7 Rodney W. Grimes 2019-02-21 17:31:49 UTC
(In reply to Mateusz Kwiatkowski from comment #5) This was discussed during the bhyve developer call on 2019/02/21 and I shall be creating a patch that makes the vm name a dynamic string of size up to MAX_NAMELEN. Look for a diffential review to be added to this PR in the next 2 weeks.
Comment 8 Mateusz Kwiatkowski 2019-05-14 16:32:26 UTC
(In reply to Rodney W. Grimes from comment #7) Hi Rodney, Any update on this?
Comment 9 Mateusz Kwiatkowski 2019-06-07 08:02:59 UTC
Hi Rodney, I understand that proper change may take some time but can we have this limit simply bumped to 64 so that it can make into upcoming releases?
Comment 10 Scott Long 2019-06-24 22:40:26 UTC
VM_MAX_NAMELEN can be increased to 63 right now. Any larger and it exceeds the length allowed by the devfs (i.e. /dev) filesystem via the SPECNAMELEN limit. Truncating names in those nodes will be problematic, and increasing the limit will require a significant amount of code review and testing. Would 63 be good enough for now?
Comment 11 Mateusz Kwiatkowski 2019-06-25 04:17:58 UTC
Hi Scott, Thank you for chiming in. Yes, 63 is fine for our use case. Internally we’re we use limit of 64 and works fine. All VM has UUIDs as their names so well below that though.
Comment 12 Mateusz Kwiatkowski 2019-07-11 08:45:11 UTC
(In reply to Scott Long from comment #10) Hi Scott, Would you have some free cycles to commit the change? Thank you in advance.
Comment 13 Scott Long 2019-07-11 18:02:22 UTC
See the following review: https://reviews.freebsd.org/D20924
Comment 14 commit-hook 2019-07-12 18:38:51 UTC
A commit references this bug: Author: scottl Date: Fri Jul 12 18:37:57 UTC 2019 New revision: 349948 URL: https://svnweb.freebsd.org/changeset/base/349948 Log: Tie the name limit of a VM to SPECNAMELEN from devfs instead of a hard-coded value. Don't allocate space for it from the kernel stack. Account for prefix, suffix, and separator space in the name. This takes the effective length up to 229 bytes on 13-current, and 37 bytes on 12-stable. 37 bytes is enough to hold a full GUID string. PR: 234134 MFC after: 1 week Differential Revision: http://reviews.freebsd.org/D20924 Changes: head/sys/amd64/include/vmm.h head/sys/amd64/include/vmm_dev.h head/sys/amd64/vmm/vmm_dev.c