Discrepancy in handling of periods in VM names

[entr0py]

Qubes 3.1

VM Manager does not allow creation of VM's with period in name.
qvm-create allows periods.

Will using a period in VM name cause any issues?

[unman]

@3n7r0p1 Yes, there's a discrepancy - it's not the only one. You can also use underscore with qvm-create, but not in Manager. The regexes are slightly different. I don't think it matters. (The command line often offers greater control.)

Yes, using a period will cause issues. DNS uses the period as a delimiter between labels, and various system elements will expect this to be the case. Trivially, the standard prompt will appear as user@a rather than user@a.b . Generally, anything that interacts with DNS will break. Don't do it. (This isn't specific to Qubes.)

[unman]

@3n7r0p1 Yes, there's a discrepancy - it's not the only one. You can also use underscore with qvm-create, but not in Manager. The regexes are slightly different. I don't think it matters. (The command line often offers greater control.)

Yes, using a period will cause issues. DNS uses the period as a delimiter between labels, and various system elements will expect this to be the case. Trivially, the standard prompt will appear as user@a rather than user@a.b . Generally, anything that interacts with DNS will break. Don't do it. (This isn't specific to Qubes.)

[jpouellet]

Additionally underscores are allowed in vm names but not allowed in the creation gui.
https://github.com/QubesOS/qubes-core-admin/blob/master/core-modules/000QubesVm.py#L572

Thought: Reserving a special character not able to be created in the gui would allow qubes-internal VMs (such as foo-dm for HVMs) to never conflict with user-specified domains. This would mean using foo_dm instead of foo-dm as the auto-generated domain for the 'foo' HVM.

[jpouellet]

Additionally underscores are allowed in vm names but not allowed in the creation gui.
https://github.com/QubesOS/qubes-core-admin/blob/master/core-modules/000QubesVm.py#L572

Thought: Reserving a special character not able to be created in the gui would allow qubes-internal VMs (such as foo-dm for HVMs) to never conflict with user-specified domains. This would mean using foo_dm instead of foo-dm as the auto-generated domain for the 'foo' HVM.

[unman]

@jpouellet Not clear on your proposal -I think you must mean reserving characters that cant be used in gui AND command line? Otherwise you will still have potential for conflict with user-specified names.

[unman]

@jpouellet Not clear on your proposal -I think you must mean reserving characters that cant be used in gui AND command line? Otherwise you will still have potential for conflict with user-specified names.

[jpouellet]

Not really a proposal so much as an observation.

If I create an HVM named "foo", and a pvm named "foo-dm", and start "foo", then I will be unable to start "foo-dm", because the name is already used internally by qubes. Instead, you get this unhelpful (if you don't already know why) error message:

Qubes internally using _dm instead of -dm would avoid this problem, because users in the gui can not create VMs named ..._dm.

Users on the command line are assumed to not be bothered by such minor user experience things.

[jpouellet]

Not really a proposal so much as an observation.

If I create an HVM named "foo", and a pvm named "foo-dm", and start "foo", then I will be unable to start "foo-dm", because the name is already used internally by qubes. Instead, you get this unhelpful (if you don't already know why) error message:

Qubes internally using _dm instead of -dm would avoid this problem, because users in the gui can not create VMs named ..._dm.

Users on the command line are assumed to not be bothered by such minor user experience things.

[marmarek]

-dm suffix is hardcoded in Xen toolstack, so not something we could easily change. Much easier thing to do for this particular problem, would be to prevent VM to have -dm suffix.

[marmarek]

-dm suffix is hardcoded in Xen toolstack, so not something we could easily change. Much easier thing to do for this particular problem, would be to prevent VM to have -dm suffix.

[jpouellet]

This issue isn't really resolved and IMO is not ready to be closed. There is still a discrepancy in periods (as the OP was about).

There was a reason my commit said "Partially fixes ..."

[jpouellet]

This issue isn't really resolved and IMO is not ready to be closed. There is still a discrepancy in periods (as the OP was about).

There was a reason my commit said "Partially fixes ..."

[marmarek]

github: "Partially fixes" still matches "fixes" ;)

[marmarek]

github: "Partially fixes" still matches "fixes" ;)

[marmarta]

I've made it more consistent:

• in R3.2, where dot is allowed in VM names, it will now be also allowed in GUI tools
• in R4.0, where dot is not allowed in VM names, it will not be allowed in GUI tools (but underscore, that should have been allowed but wasn't, will be)

[marmarta]

I've made it more consistent:

• in R3.2, where dot is allowed in VM names, it will now be also allowed in GUI tools
• in R4.0, where dot is not allowed in VM names, it will not be allowed in GUI tools (but underscore, that should have been allowed but wasn't, will be)