When there are multile USB devices, --host-device with bus.addr
can identify unique device, so we need to add bus/addr info to
XML rather than only vendor/product
If there is only one USB device with --host-device bus.addr,
adding bus/addr is no harm under the request of user.
host-model is a bit more scary then previous behavior, since the
model of an existing VM can transparently change across libvirt
upgrade or HW upgrade. This will probably be improved at the libvirt
level, but for now revert.
This reverts commit 17f43e47fb.
Although the code in lookup_nodedev() is general to deal with
hostdev, it has to seperate USB device from PCI device there.
For PCI device, the domain/bus/slot/function is hex.
For USB device, the bus/device is decimal.
This fix makes the label use hostdev pretty_name:
+------------------------------------------------------+
| Physical USB Device |
| Device: 006:032 RSA RSA SecureID (R) Authenticator |
(crobinso: fix some pylint)
There was an example for USB controller, but to show all the
sub-options, there was the master= option used without extra
information about the fact that it is used for companion controllers
only. So this patch adds second example in front of the previous one
and re-words the description a little bit.
When there are mutiple USB devices with identical vendorId and
productId, with --host-device <vendorId:productId>, virt-install
fails to specify one.
Currently the virt-install add the first node device with
these vendorId and productId.
This fix will throw out an error when argument to --host-device
can't specify unique node device.
For example:
virt-install ${other args} \
--host-device <vendorId:productId>
ERROR 15e1:2007 corresponds to multiple node devices
Remote sound works fine these days. If people want to turn the
preference off, they probably want to do it in all cases, and can
'customize before install' to alter the rest.
In case there was '.treeinfo' file available, virt-install was
forcibly getting image information out of the file. For some
distributions (especially older releases, e.g. RHEL 4), there might be
'.treeinfo' file available, but with incomplete information. Allow
fallback to default values even when '.treeinfo' file is found.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=954262
Kind of a maintenance pain, and it's just poorly duplicating info
from the git logs. We could autogenerate this but I don't really
have the interest in figuring it out. Patches welcome :)
-c maps to --cdrom for virt-install, but for other libvirt tools like
virsh it maps to --connect.
Handle -c and --cdrom a little differently: if -c contains '://',
error out with an explanation. User can work around it by using
--cdrom. This could in theory break some users, but the change they
make will be backwards compatible.
If the host-model is selected, disable the cpu model drop down
and features list. They still show what exact configuration the
host-model is using.
For the old libvirt which doesn't support <cpu mode='host-model'/>
virt-manager still copy cpu configs from caps XML to domain XML.
(crobinso: Fix some minor pylint)
The helper function aims to reset cpu related vars to none except
<topology>.
It is named with clear_attrs(). clear() could be saved for later use
of clearing all of them including <topology>.
UPDATE_CPU flag exists after v0.8.0, so libvirt that
supports HOST_MODEL should support UPDATE_CPU,
the earliest version we are going to check is v0.9.10.
After all these changes, it fixes the invisible scrollbar issue. It
was some combination of do_style_set and something else, but I didn't
bother narrowing it down.
The only bits were were using was the icon installation and
translation building, which amounted to about 70 lines of code.
Just steal it so we can avoid the dep which will cause trouble
for future RHEL.
Object leak stuff isn't a big deal and won't be fixed anytime soon.
Remove some completed items.
Website has changed recently, so update that bullet point.
Was originally added with hopes for being used in an ovirt related
product, but was more or less a code dump, and the author has been
allocated to other things. He confirmed it's okay to remove.
That, and it's currently broken, and we've had approximately 0 user
feedback since it was committed.
This unfortunately has a decent amount of fallout: add a wrapper class
in config.py that reduces much of the churn.
Another big piece is that gsettings can't accept arbitrary paths like
gconf would, everything needs to be described in the schema.
Also do a bunch more RPM spec modernizing
Guannan Ren