Description of problem: When creating a new VM in RHEV-M, you must fill out a New Virtual Machine dialog box. After this is done, the next dialog box only prompts the administrator for the disk configuration and the Network Configuration is now gone from the dialog box. The administrator now has a VM with no networking and must shutdown the VM and manually add it from editing the VM in RHEV-M. Version-Release number of selected component (if applicable): RHEV-M 3.3 (is24.2) How reproducible: 100% Steps to Reproduce: 1. See above. 2. 3. Actual results: Expected results: Additional info:
VM network interfaces may now be configured directly in the new VM dialog, thereby obviating the need for the Guide Me flow to include network interfaces, see Bug 1024249.
Lior, I thought that since the network was grayed out, that the feature was disabled when you pointed this out in comment 2. I am really used to configuring the network on the dialog box with the VM disk and didn't realize the feature was even available. Do you know if the "nic 1" is grayed out on purpose?
It's grayed out on purpose, but maybe wrongfully so. The idea of the widget is that a row is "brought to life" when some profile is chosen (i.e. the NIC doesn't "really" exist until a profile is attached to it, as you've experienced). I understand why it could look disabled, and that might merit a bug. Do you think that changing the text ("There are currently no interfaces...") from gray to black would help make it appear editable?
Yes, because the "Brought to life" concept could be when you can add another nic interface.
*** Bug 1036218 has been marked as a duplicate of this bug. ***
*** Bug 1054205 has been marked as a duplicate of this bug. ***
Lior, IIRC correctly the discussions about the design I think the consensus was that the VM should have 1 NIC by default (which can be removed, or add more), the intent was to not ask user too many things and suggest a reasonable default. This was before network profiles. I think that we should assign a default/some network profile and the line should be alive without any extra user involvement. reopening to improve usability
Michal, I understand your point, but this would be inconsistent with our notion of templates (which complicates UX in a different way). I would also expect the VM to by default have a networking configuration similar to the one on the template from which it's being created. So if it's created from the blank template, the consistent thing to do would be to have no network by default. Unless we're willing to change the definition of the blank template.
(In reply to Lior Vernia from comment #10) I wonder if it would break anything if we just add a network to the blank template. Note the instance types will replace the blank template usage, I suppose, and I do expect it to have a NIC. Not sure about profiles, so do we need a default one perhaps?
If we want the default VM configuration based on the blank template to be network-ready without any changes, then yes, I would expect the blank template to have one vNIC by default to which the default ovirtmgmt profile will be attached. However, I'm not familiar with the flow of how the blank template is initially created, so I'm not sure if at the point of its creation there already exist the ovirtmgmt network and its profile. And I also don't know what could potentially break due to this meddling with the blank template.
(In reply to Lior Vernia from comment #12) > If we want the default VM configuration based on the blank template to be > network-ready without any changes, then yes, I would expect the blank > template to have one vNIC by default to which the default ovirtmgmt profile > will be attached. > > However, I'm not familiar with the flow of how the blank template is > initially created, so I'm not sure if at the point of its creation there > already exist the ovirtmgmt network and its profile. And I also don't know > what could potentially break due to this meddling with the blank template. I wouldn't recommend on that approach, since the ovirtmgmt might be (and basically we recommend it to the users) a non-vm network, therefore it wouldn't be possible to attached any vms to it. Therefore we might end-up in inconsistent behavior. I'd go with the first approach of creating a vm based on a template, exactly how it is configured. If the user decide to add a specific network to it, let him decide which specific network he wishes to add, since the template is on DC level and vms are on cluster levels.
A fix to Bug 1064431 should address the coloring, other than that I think the current behavior is as consistent as it possibly can be.
I am going to close this bug, but just wanted to give you a heads up first: As Lior pointed out in comment #14, we should address the coloring while defining a new NIC which is currently confusing. Other than that, I fully agree with Moti (comment #13) - the 'rhevm' network is the default management network, and NOT the default VM network. The customer should create its profiles accordingly.