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.
Bug 864773 - libvirt should deny illegal NIC model when edit guest xml
Summary: libvirt should deny illegal NIC model when edit guest xml
Keywords:
Status: CLOSED DUPLICATE of bug 954248
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.5
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 6.5
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-10 05:11 UTC by EricLee
Modified: 2013-11-11 12:48 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-11 12:48:01 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description EricLee 2012-10-10 05:11:17 UTC 
Description of problem:
libvirt should deny illegal NIC model when edit guest xml, but give unclear error message when start guest

Version-Release number of selected component (if applicable):
# rpm -qa libvirt qemu-kvm-rhev kernel seabios
seabios-0.6.1.2-22.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.317.el6.x86_64
libvirt-0.10.2-2.el6.x86_64
kernel-2.6.32-309.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
# virsh edit raw
change
    <interface type='network'>
      <mac address='54:52:00:54:9e:f4'/>
      <source network='default'/>
      <model type='virtio'/>
    </interface>
to
    <interface type='network'>
        <mac address='54:52:00:54:9e:f4'/>    
        <source network='default'/>
        <model type='test'/>  
    </interface>

modified successfully.

But when start guest:
# virsh start raw
error: Failed to start domain raw
error: internal error Process exited while reading console log output: 2012-10-10 03:00:40.710+0000: 7350: debug : virFileClose:72 : Closed fd 21
2012-10-10 03:00:40.710+0000: 7350: debug : virFileClose:72 : Closed fd 27
2012-10-10 03:00:40.711+0000: 7350: debug : virFileClose:72 : Closed fd 3
char device redirected to /dev/pts/1
qemu-kvm: -device test,netdev=hostnet0,id=net0,mac=52:54:00:1b:6f:e5,bus=pci.0,addr=0x3: Parameter 'driver' expects a driver name
Try with argument '?' for a list.

A lot of unnecessary error info, and not clear enough.

Actual results:
As steps

Expect result:
Should deny illegal NIC model, just like illegal interface type:
# virsh edit raw
error: internal error unknown interface type 'test'
Failed. Try again? [y,n,f,?]:

Or give clearer error info without lots of unnecessary info.
Comment 2 Jiri Denemark 2012-10-10 13:11:15 UTC 
Unlike interface type NIC model is not interpreted by libvirt and thus at the time of defining a new domain libvirt cannot guess what models will be supported by QEMU when the domain is started. From this point of view everything works as expected and this is not a bug. On the other hand, I agree the error is not very helpful but checking each device for support before trying to use it on QEMU command line seems bad as well...
Comment 3 Dave Allan 2012-10-10 13:15:20 UTC 
Could we add capabilities data for the allowed models?
Comment 4 Jiri Denemark 2012-10-11 12:40:41 UTC 
Currently we can get list of all devices QEMU supports but we don't know which ones are network devices. Anyway, it seems awful to check all devices we are going to add to qemu against that list. Mainly becuase QEMU will also do the same check. I'd prefer if QEMU could provide a better error message.
Comment 5 Martin Kletzander 2012-10-15 12:59:42 UTC 
I agree with Jiri, this would be a huge overhead from our side, plus we are unable to say whether QEMU will be ok with the device used as a network device w/o running it and checking the errors for each device.  However, having QEMU provide a better error would probably look better.

Having said that, I'm not sure their list-parsing method is able to know that the model specified is really a wrong model, not some other parameter.
Comment 7 Ademar Reis 2013-03-26 21:30:41 UTC 
Defer to RHEL7 due to limited capacity on RHEL6 (this is a new feature, appears to be low-priority).
Comment 10 Ronen Hod 2013-11-03 13:19:46 UTC 
As far as QEMU is concerned, the error message is OK (not perfect).
"qemu-kvm: -device test,netdev=hostnet0,id=net0,mac=52:54:00:1b:6f:e5,bus=pci.0,addr=0x3: "

Libvirt wise, the excessive logging is not helpful. Returning to Libvirt.

Note that Marcel can make use of the "device categories" code in order to return additional information regarding the devices and their type.

QEMU wise, I would close this bug.
Comment 11 Dave Allan 2013-11-06 18:50:43 UTC 
Martin, is this BZ fixed by Peter's patches to make start errors clearer?
Comment 12 Dave Allan 2013-11-07 03:36:54 UTC 
Answering my own question, it doesn't seem to be, with the current upstream HEAD, starting a VM with an invalid nic model results in:

virsh start minimal
error: Failed to start domain minimal
error: Unable to read from monitor: Connection reset by peer
Comment 13 Dave Allan 2013-11-07 03:43:44 UTC 
IMO libvirt should be reporting at least what qemu provides, although I don't see any useful information being reported in the qemu log, either, so I disagree that this is not a qemu bug and I disagree strongly that the existing error message is useful to the user.  This is a serious usability problem.
Comment 14 Martin Kletzander 2013-11-07 13:27:34 UTC 
To go a bit further in this BZ...  We're now querying qemu for some of its capabilities, but we're still unable to properly recognize whether qemu will not object to a use of some device.  There are two problems.  The first one is minor, we're not saving the list of devices qemu knows when we are probing for capabilities.  The second one is worse, however.  We must identify each device with its "type", i.e. whether it is a network device, graphics card, etc.  This is not (yet?) implemented in qemu.  If this is what was meant in comment #10, then 

@Marcel:  Did I understand correctly, that it would be possible for you to add e.g. "type":"audio" parameters into the return data of "qom-list-types"?  If yes, is there a BZ tracking the progress of it or should I create a new one?  We could then switch this one to libvirt (to track the progress of us checking all the supported devices), I guess.
Comment 15 Marcel Apfelbaum 2013-11-07 15:41:40 UTC 
We have some patches (not yet in RHEL 7) that add a "category" field for each device. However, multi-function devices will have several categories.

You can see the patch here:
https://lists.gnu.org/archive/html/qemu-devel/2013-10/msg01318.html

The BZ I use for keeping track of device-slot compatibility(not exactly this problem) is:
https://bugzilla.redhat.com/show_bug.cgi?id=984341

If we backport those patches I suppose we can add this "categories" field to qom-list-types query, but be aware that it will be a list and not one element.

Please see the above BZ (984341) and see we have a bigger issue, on which devices can go in which slot.

Regarding *this* bug, only the following line belongs to qemu:
qemu-kvm: -device test,netdev=hostnet0,id=net0,mac=52:54:00:1b:6f:e5,bus=pci.0,addr=0x3: Parameter 'driver' expects a driver name
Try with argument '?' for a list.

As you can see, it *points* to the device with the problem, and asks you to go to the specific help of the device. Not perfect, but it does the job...

Hope it helped,
Marcel
Comment 16 Martin Kletzander 2013-11-11 12:48:01 UTC 
Having "qom-list-types" reporting object categories would be great from this POV.  I understand that due to multifunction devices it must be a list, but that's not a problem.  But that's not the point, I'll create another BZ for that.

The rest of this bug (outputting libvirt debug messages as part of qemu log), this is already fixed in bug 954248.  Closing as a dup.

*** This bug has been marked as a duplicate of bug 954248 ***
Note You need to log in before you can comment on or make changes to this bug.