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.
Comment 3Martin Kletzander
2017-06-21 08:01:32 UTC
It makes sense, but I'm not convinced we should disable all such usage. For some things it can't make any change/difference, but there is no disadvantage for it. For some other cases, and I admit my lack of full understanding here, I can't wrap my head around why it wouldn't change anything. Moreover, in cases where there are no differences to whether it is set or not, if that will change in the future, libvirt is ready for it. If we disable any of those now, we'll need to enable them afterwards.
Comment 4Martin Kletzander
2017-08-23 12:27:17 UTC
Thinking about it, I feel like whoever is setting this should already know the impact and details behind it. So I think it's pretty safe to assume that such user doesn't need libvirt to hold their hands.
If more reasons arise, feel free to reopen this BZ or discuss below. For now I'm closing this as WONTFIX.
Description of problem: coalesce setting only support in network and bridge type interface devices with virtio model type and vhost as backend driver currently. But now, guest with coalesce settings can start without these prerequisites. Version-Release number of selected component (if applicable): libvirt-3.2.0-9.el7.x86_64 kernel-3.10.0-671.el7.x86_64 How reproducible: 100% Steps to Reproduce: Scenario 1: interface type = network, with hostdev or macvtap network, the guest can start with coalesce setting, but coalesce setting takes no effect. 1. # virsh net-dumpxml direct-macvtap <network> <name>direct-macvtap</name> <uuid>06848478-25db-4edc-8a85-27a0778b3f50</uuid> <forward dev='enp0s25' mode='bridge'> <interface dev='enp0s25'/> </forward> </network> 2. # virsh start rhel7 Domain rhel7 started 3. # virsh dumpxml rhel7 --inactive | grep /interface -B10 <interface type='network'> <mac address='52:54:00:65:60:17'/> <source network='direct-macvtap'/> <model type='virtio'/> <coalesce> <rx> <frames max='32'/> </rx> </coalesce> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> # virsh dumpxml rhel7 | grep /interface -B12 <interface type='direct'> <mac address='52:54:00:65:60:17'/> <source network='direct-macvtap' dev='enp0s25' mode='bridge'/> <target dev='macvtap0'/> <model type='virtio'/> <coalesce> <rx> <frames max='32'/> </rx> </coalesce> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> 4. # ethtool -c macvtap0 Coalesce parameters for macvtap0: Cannot get device coalesce settings: Operation not supported ---------------------------hostdev---------------------- 1. # virsh dumpxml test --inactive | grep /interface -B10 <interface type='network'> <mac address='52:54:00:08:da:72'/> <source network='hostnet'/> <model type='virtio'/> <coalesce> <rx> <frames max='64'/> </rx> </coalesce> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> 2. # virsh start test virsh Domain test started 3. # virsh dumpxml test | grep /interface -B14 <interface type='hostdev' managed='yes'> <mac address='52:54:00:08:da:72'/> <driver name='vfio'/> <source> <address type='pci' domain='0x0000' bus='0x86' slot='0x10' function='0x1'/> </source> <model type='virtio'/> <coalesce> <rx> <frames max='64'/> </rx> </coalesce> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> Scenario 2: For model type other than virtio(rtl8139, e1000, e1000e), coalesce setting can be set in interface xml, but in fact it takes no effect as it needs vhost as backend driver. 1. # virsh start rhel7 Domain rhel7 started 2. live xml still contain the coalesce setting for other model type. # virsh dumpxml rhel7 | grep /interface -B12 <interface type='network'> <mac address='52:54:00:cf:82:da'/> <source network='default' bridge='virbr0'/> <target dev='vnet0'/> <model type='rtl8139'/> <coalesce> <rx> <frames max='64'/> </rx> </coalesce> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> 3. although the tap device got the coalesce setting, but it needs vhost as backend. # ethtool -c vnet0 | grep rx-frames: rx-frames: 64 Scenario 3: If we specify the driver to <driver name='qemu'/>, coalesce setting will take no effect as it needs vhost as backend. 1. # virsh dumpxml rhel7 | grep /interface -B11 <interface type='network'> <mac address='52:54:00:cf:82:da'/> <source network='default'/> <model type='virtio'/> <driver name='qemu'/> <coalesce> <rx> <frames max='64'/> </rx> </coalesce> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> 2. # virsh start rhel7 Domain rhel7 started 3. # virsh dumpxml rhel7 | grep /interface -B13 <interface type='network'> <mac address='52:54:00:cf:82:da'/> <source network='default' bridge='virbr0'/> <target dev='vnet0'/> <model type='virtio'/> <driver name='qemu'/> <coalesce> <rx> <frames max='64'/> </rx> </coalesce> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> 4. # ethtool -c vnet0 | grep rx-frames: rx-frames: 64 Actual results: guest with coalesce settings can start without the prerequisites, and the coalesce makes no sense. Expected results: libvirt will do the check and report clear error message or warning when start the guest. Additional info: For hostdev, there is a similar scenario refer to Bug 1311928