Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionKrist van Besien
2019-11-29 08:27:00 UTC
Description of problem:
Using the Virtual Machines Tab in the Cockpit one can change the virtual network a VM is connected to, but this appears to be ignored.
Version-Release number of selected component (if applicable):
RHEL 8.1
How reproducible:
Always
Steps to Reproduce:
1. Create a VM via the Cockpit. Attach an ISO. Do not start it.
2. Edit the VM, changing the network from the "default" virtual network to another one. (in this case a bridged one on a different interface).
3. Start the VM
Actual results:
VM is started, but network connection reverts back to the default (virbr0)
Expected results:
VM is started, and is connected to the selected network.
Additional info:
I create the second network as follow:
- Created a bridge, named bridge0 on a second ethernet interface.
- Created a second virtual network using this xml:
<network>
<name>host-bridge</name>
<forward mode="bridge"/>
<bridge name="bridge0"/>
</network>
(RFE: Make it possible to do this using the cockpit)
I did another test where I changed the network the interface was attached to after the first boot. This time the change did stick (the VM is attached to the other network) but the network tab has a small "hourglas" symbol next to the type and source, indicating that this will be made active after the next restart of the VM. And this even though it is already active...
This was fixed upstream with:
commit 48419b121778e305126a01bf6adce49224bb9d94
Author: Simon Kobyda <skobyda>
Date: Mon Dec 16 14:30:56 2019 +0100
machines: Fix lost of configuration changes made before installation
Yes, of course.
It can be reproduced with:
cockpit-machines-209-1.el8.noarch
Steps:
1. On Networks page, prepare 2 Virtual Network
2. Create a new VM , uncheck "Immediately Start VM", click Create
3. Enter Network Interfaces tab, edit the default network to the other network prepared in step 1
4. Click run
5. Enter Network Interfaces tab again
The Source is changed back to default.
But is this the same bug with: https://bugzilla.redhat.com/show_bug.cgi?id=1780449
Please take a look and maybe close this one if they have the same root cause since the bug1780449 above has already been verified.
Thanks.