Bug 864773
Summary: | libvirt should deny illegal NIC model when edit guest xml | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | EricLee <bili> |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.5 | CC: | acathrow, bsarathy, cwei, dallan, dyuan, gsun, hhuang, jdenemar, juzhang, knoel, marcel, mkenneth, mkletzan, mst, mzhan, rhod, virt-maint, ydu |
Target Milestone: | rc | ||
Target Release: | 6.5 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-11-11 12:48:01 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
EricLee
2012-10-10 05:11:17 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... Could we add capabilities data for the allowed models? 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. 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. Defer to RHEL7 due to limited capacity on RHEL6 (this is a new feature, appears to be low-priority). 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. Martin, is this BZ fixed by Peter's patches to make start errors clearer? 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 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. 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. 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 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 *** |