Description of problem: Version-Release number of selected component (if applicable): 4.3.9 installed from https://resources.ovirt.org/pub/ovirt-4.3/iso/ovirt-node-ng-installer/4.3.9-2020031917/el7/ovirt-node-ng-installer-4.3.9-2020031917.el7.iso How reproducible: always Steps to Reproduce: 1. compute - virtual machines - click test1 2. click network interfaces, select interface, click edit 3. change link state from up to down or change network Actual results: message displayed "Cannot edit Interface. External network cannot be changed while plugged into a running virtual machine. Stop the VM or unplug the vNIC before editing." Expected results: On the fly change of link and network Additional info: Come on guys. I can do this for running virtual machines with Microsoft and VMWare for years. Why must this be so complicated on oVirt?
Created attachment 1690215 [details] cannot change link state of running vm
Created attachment 1690216 [details] cannot change connected network of a running vm
Hi This is not supported. External network must be unplugged first. Changing link state or network profile supported only with hotunplug for external networks.
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
(In reply to Michael Burman from comment #3) > Hi > > This is not supported. External network must be unplugged first. > Changing link state or network profile supported only with hotunplug for > external networks. I understand that, but: My question is why? Also will this ever work on oVirt? Is it planned? What is preventing it?
(In reply to Mai Ling from comment #5) > (In reply to Michael Burman from comment #3) > > Hi > > > > This is not supported. External network must be unplugged first. > > Changing link state or network profile supported only with hotunplug for > > external networks. > > I understand that, but: > > My question is why? > Please note that changing networks of plugged vNICs works for linux bridge based networks. Can you share why the flow of 1. hotunplug 2. change network 3. hotplug is a problem in your scenario? > Also will this ever work on oVirt? Is it planned? It is currently not planed, because there was no request to do so. > What is preventing it? I agree, that this is a question worth to investigate. First reason is, that oVirt has not many assumptions about external networks. But if we assume, we are using an external network on the ovirt-provider-ovn, it would be interesting to check if the requested feature would be possible. ovirt-provider-ovn connects the vNIC to a OVS bridge. Next step would be to check if libvirt supports hot updates on such interfaces.
(In reply to Dominik Holler from comment #6) > (In reply to Mai Ling from comment #5) > > (In reply to Michael Burman from comment #3) > > > Hi > > > > > > This is not supported. External network must be unplugged first. > > > Changing link state or network profile supported only with hotunplug for > > > external networks. > > > > I understand that, but: > > > > My question is why? > > > > Please note that changing networks of plugged vNICs works for linux bridge > based networks. If I understand correctly, linux bridge-based ovirt networks require a physical interface on the host to bind to the bridge. This is not possible if the host already has the only physical interface bound to the ovirtmgmt bridge. > > Can you share why the flow of > 1. hotunplug > 2. change network > 3. hotplug > is a problem in your scenario? * some apps inside the guest may not reconfigure to network interface unexpected appearing/dissappearing on the system * if the interface was manually configured and not managed by NetworkManager then it requires manual intervention for interface reconfiguration when interface comes up * tcp connections are reset when interface dissapears, maybe I want to keep running that tcpdump on the interface, maybe I want those tcp sessions to timeout naturally ... etc
(In reply to Mai Ling from comment #7) > (In reply to Dominik Holler from comment #6) > > (In reply to Mai Ling from comment #5) > > > (In reply to Michael Burman from comment #3) [...] > > Please note that changing networks of plugged vNICs works for linux bridge > > based networks. > > If I understand correctly, linux bridge-based ovirt networks require a > physical interface on the host to bind to the bridge. This is not possible > if the host already has the only physical interface bound to the ovirtmgmt > bridge. > Also, this is failing for me when I added the second interface, removed it, then attempted to add it again. It only worked for the first time when in "setup host networks", then after deleting all subsequent tries fail and when the network has the "Required" flag for the cluster, the host is marked as unavailable in the cluster.
(In reply to Mai Ling from comment #7) > (In reply to Dominik Holler from comment #6) > > (In reply to Mai Ling from comment #5) > > > (In reply to Michael Burman from comment #3) > > > > Hi > > > > > > > > This is not supported. External network must be unplugged first. > > > > Changing link state or network profile supported only with hotunplug for > > > > external networks. > > > > > > I understand that, but: > > > > > > My question is why? > > > > > > > Please note that changing networks of plugged vNICs works for linux bridge > > based networks. > > If I understand correctly, linux bridge-based ovirt networks require a > physical interface on the host to bind to the bridge. This is correct. > This is not possible > if the host already has the only physical interface bound to the ovirtmgmt > bridge. > Logical networks in oVirt can have a VLAN tag. Logical networks with different VLAN tags can be attached to a single NIC of the host, while the VLAN tag ensures isolation between the different logical networks. The pitfall is that the physical switch might require additional configuration to forward VLAN tagged Ethernet frames. > Also, this is failing for me when I added the second interface, removed it, then attempted to add it again. It only worked for the first time when in "setup host networks", then after deleting all subsequent tries fail and when the network has the "Required" flag for the cluster, the host is marked as unavailable in the cluster. I do not understand this flow. Sounds like a candidate for the mailing list https://lists.ovirt.org/archives/list/users@ovirt.org/ > > > > Can you share why the flow of > > 1. hotunplug > > 2. change network > > 3. hotplug > > is a problem in your scenario? > > * some apps inside the guest may not reconfigure to network interface > unexpected appearing/dissappearing on the system > * if the interface was manually configured and not managed by NetworkManager > then it requires manual intervention for interface reconfiguration when > interface comes up > * tcp connections are reset when interface dissapears, maybe I want to keep > running that tcpdump on the interface, maybe I want those tcp sessions to > timeout naturally > ... etc I see, thanks
(In reply to Dominik Holler from comment #9) > (In reply to Mai Ling from comment #7) > > (In reply to Dominik Holler from comment #6) > > > (In reply to Mai Ling from comment #5) > > > > (In reply to Michael Burman from comment #3) [...] > > The pitfall is that the physical switch might require additional > configuration to forward > VLAN tagged Ethernet frames. > Perhaps in production environments this feature is common, but in development and home and ad-hoc environments this is not always available. So if one wants to learn and try and discover and report issues, and does not have yet access to the future production environment, this is a critical showstopper.
(In reply to Mai Ling from comment #10) > (In reply to Dominik Holler from comment #9) > > (In reply to Mai Ling from comment #7) > > > (In reply to Dominik Holler from comment #6) > > > > (In reply to Mai Ling from comment #5) > > > > > (In reply to Michael Burman from comment #3) > > [...] > > > > > The pitfall is that the physical switch might require additional > > configuration to forward > > VLAN tagged Ethernet frames. > > > > Perhaps in production environments this feature is common, but in > development and home and ad-hoc environments this is not always available. > > So if one wants to learn and try and discover and report issues, and does > not have yet access to the future production environment, this is a critical > showstopper. Add this to the current temporary covid19 conditions when you can not get network support as fast as usual to enable tagged VLAN frames on the interface. Or can not get a remote hand to plug a cable into an additional network interface.
(In reply to Mai Ling from comment #11) > (In reply to Mai Ling from comment #10) > > (In reply to Dominik Holler from comment #9) > > > (In reply to Mai Ling from comment #7) > > > > (In reply to Dominik Holler from comment #6) > > > > > (In reply to Mai Ling from comment #5) > > > > > > (In reply to Michael Burman from comment #3) > > > > [...] > > > > > > > > The pitfall is that the physical switch might require additional > > > configuration to forward > > > VLAN tagged Ethernet frames. > > > > > > > Perhaps in production environments this feature is common, but in > > development and home and ad-hoc environments this is not always available. > > > > So if one wants to learn and try and discover and report issues, and does > > not have yet access to the future production environment, this is a critical > > showstopper. > From my point of view it is the other way round. If you are in a home environment, you can either use a cheap unmanaged Ethernet switch, which will ignore the VLAN tags, or you can manage the switch on your own. Both is fine for oVirt. Please note that oVirt configures the VLAN tagging on the hosts, which is fine for default configuration of Ethernet switches. Would this work for you? > Add this to the current temporary covid19 conditions when you can not get > network support as fast as usual to enable tagged VLAN frames on the > interface. Or can not get a remote hand to plug a cable into an additional > network interface. I agree, if you cannot use VLANs, e.g. because the network administrator blocked VLANs in the switch, and you do not want to wait for the network admin to enable them for you, or you require very many logical networks, external networks becomes interesting. I agree, in such situations in combination with no way to reconfigure the guest, changing external networks of plugged vNICs would be helpful.
(In reply to Dominik Holler from comment #12) > (In reply to Mai Ling from comment #11) > > (In reply to Mai Ling from comment #10) > > > (In reply to Dominik Holler from comment #9) > > > > (In reply to Mai Ling from comment #7) > > > > > (In reply to Dominik Holler from comment #6) > > > > > > (In reply to Mai Ling from comment #5) > > > > > > > (In reply to Michael Burman from comment #3) > > > > > > [...] > > > > > > > > > > > The pitfall is that the physical switch might require additional > > > > configuration to forward > > > > VLAN tagged Ethernet frames. > > > > > > > > > > Perhaps in production environments this feature is common, but in > > > development and home and ad-hoc environments this is not always available. > > > > > > So if one wants to learn and try and discover and report issues, and does > > > not have yet access to the future production environment, this is a critical > > > showstopper. > > > > From my point of view it is the other way round. > If you are in a home environment, you can either use a cheap unmanaged > Ethernet > switch, which will ignore the VLAN tags, or you can manage the switch on > your own. > Both is fine for oVirt. > Please note that oVirt configures the VLAN tagging on the hosts, which is > fine > for default configuration of Ethernet switches. > Would this work for you? Unfortunately not. At home this looks interesting (I have a cheap unmanaged switch and a second network interface as well), but at workplace the machine I'm particularly remote working on from home (for which I opened this BZ) only has one interface connected to a managed switch and for a couple of days there is nobody available to either plug in an additional ethernet cable nor reconfigure tagged vlan on existing interface, not to mention the difficulty of creating additional temporary vlans (just for testing and learning) on a switch that I do not have access to so bothering the admin just for that would be impossible.
This request is not currently committed to 4.4.z, moving it to 4.5
This RFE is problematic to implement and requested only by one user, so closing due to insufficient resources