This patch series is to enable Kimchi to assign hos devices directly to
a VM, thus greately improve VM performance. Currently we support assigning
PCI device, USB device and SCSI LUN. For example, we can assign an NIC
to VM to improve guest network throughput, or passthrough a USB camera
to enable the guest OS to record video.
Host devices form a tree. We can assign most of the devices in the tree
to VM. By assigning a device, all the devices in its sub-tree are also
assigned. It might not make sense to assign a USB controller, because
the host may be using one of the devices connected to the controller.
Instead, Kimchi just presents the "leaf" devices to assign to guest.
In recent Linux kernel and KVM, it is able to recognize the IOMMU group
of a PCI device. The "leaf" PCI devices in the same IOMMU group should
be assigned and dismissed together. The IOMMU group is the actual
smallest isolation granularity of the PCI devices.
The first patch is to list all host devices information. It's useful on
its own to show host devices information.
The second patch is to list all eligible host devices to assign, as well
as the "affected" devices in the same IOMMU group.
The third patch creates a sub-collection "hostdevs" to the VM resource,
and deals with assigning and dismissing devices.
I'll update API and unit test once everyone is happy with the interface
Zhou Zheng Sheng (3):
PCI passthrough: list all types of host devices
PCI passthrough: list eligible device to passthrough
PCI passthrough: Directly assign and dissmis host device from VM
docs/API.md | 11 +-
src/kimchi/control/host.py | 9 ++
src/kimchi/control/vm/hostdevs.py | 44 ++++++
src/kimchi/featuretests.py | 10 +-
src/kimchi/hostdev.py | 266 +++++++++++++++++++++++++++++++++
src/kimchi/i18n.py | 7 +
src/kimchi/mockmodel.py | 7 +-
src/kimchi/model/config.py | 2 +
src/kimchi/model/host.py | 32 ++--
src/kimchi/model/libvirtstoragepool.py | 18 +--
src/kimchi/model/vmhostdevs.py | 259 ++++++++++++++++++++++++++++++++
src/kimchi/rollbackcontext.py | 3 +
src/kimchi/xmlutils.py | 26 +++-
tests/test_rest.py | 6 +-
tests/test_storagepool.py | 7 +-
15 files changed, 668 insertions(+), 39 deletions(-)
create mode 100644 src/kimchi/control/vm/hostdevs.py
create mode 100644 src/kimchi/hostdev.py
create mode 100644 src/kimchi/model/vmhostdevs.py
$ sudo PYTHONPATH=src ./src/kimchid
*** Running feature tests ***
[21/May/2014:19:41:48] ENGINE Error in 'start' listener <bound method
<kimchi.model.config.CapabilitiesModel object at 0x314ac10>>
Traceback (most recent call last):
line 197, in publish
line 69, in _set_capabilities
self.metadata_support = FeatureTests.has_metadata_support()
line 197, in has_metadata_support
conn = libvirt.open('qemu:///system')
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 247, in open
if ret is None:raise libvirtError('virConnectOpen() failed')
libvirtError: Failed to connect socket to
'/var/run/libvirt/libvirt-sock': Connection refused
[21/May/2014:19:41:48] ENGINE Shutting down due to error in start listener:
[21/May/2014:19:41:48] ENGINE Bus STOPPING
[21/May/2014:19:41:48] ENGINE HTTP Server
cherrypy._cpwsgi_server.CPWSGIServer(('127.0.0.1', 8010)) shut down
[21/May/2014:19:41:48] ENGINE Stopped thread '_TimeoutMonitor'.
[21/May/2014:19:41:48] ENGINE Stopped thread 'Autoreloader'.
[21/May/2014:19:41:48] ENGINE Bus STOPPED
[21/May/2014:19:41:48] ENGINE Bus EXITING
[21/May/2014:19:41:48] ENGINE Bus EXITED
I do not find the root reason. but
after I use LibvirtConnection to open a libvirt connection, kimchi can
+from kimchi.model.libvirtconnection import LibvirtConnection
@@ -104,7 +105,7 @@ def libvirt_supports_iso_stream(protocol):
- conn = libvirt.open('qemu:///system')
+ conn = LibvirtConnection('qemu:///system').get()
Thanks and best regards!
IBM Linux Technology Center
According to #296, Dialogue window blocked ui when generating debug
report. I have one proposal that added a process bar showing that it's
working without blocking ui:
I have two thoughts:
1. Dynamic dots during generating process indicate it's working.
2. Dynamic background(with the blue stripe moving forward) indicating
Your comments on this design are highly valued and very important to me.
On 05/16/2014 01:37 AM, Crístian Viana wrote:
> On 15-05-2014 00:30, Hongliang Wang wrote:
>> It's an interesting topic here.
> I agree :-) I wish we had more discussions like this here.
>> Take edit template for example. The flow is:
>> List templates =>
>> Select a template to edit by clicking the "*Edit*" Button =>
>> Edit template window is open, and user changes some fields. =>
>> Click the "*Save*" (Or "Submit") Button to save (or submit) changes.
>> Notice that "Edit" means the user is about to edit the template, so
>> "Edit'" Button should trigger a pop-up window to allow user to change
>> some fields.
>> And "Save" Button is for saving user's changes to server. So I think
>> it's reasonable to use these 2 labels for these 2 different purposes.
> You're right, that's another way of labeling the buttons. But this is
> also not used in throughout Kimchi and that's what concerns me. Some
> windows have the "Save" button, some windows have the same label as
> the button which triggered it; we need a consistency. Whichever way is
> fine for me, as long as it looks consistent. I don't like the idea of
> having each dialog of the same application designed differently, even
> if subtly, which is how I feel it is now.
> I also thought about always using "Save" as the buttons' labels, as
> you said, and that sounds totally fine for me. If we think this
> approach is better, I'll use this approach on the next version of this
Go ahead! Either "Save" or "Submit" is fine for me.
>> Let me explain the naming rule of #guest-edit-button-save. It follows
>> name space style like Java package mechanism.
>> guest-: It's within the scope of guest page
>> edit-: It's within the scope of guest edit window
>> button-: It's a button within the scope of guest edit window
>> save: It's a button named save
>> So please remain the original ID string of the button. If we will
>> introduce another button in the future, we can simply name it
> Thanks for the explanation, it makes total sense. I just blindly
> removed the "save" string from the variable name, I should have left
> "edit" instead, which is the new label I'm using.
> But, again, this variable naming rule is also not consistent
> throughout thel Kimchi code. For example, the submit button of the
> dialog "Create Storage Pool" has an id="pool-doAdd". According to this
> naming rule, it should be something like "storage-add-button-create".
> In this patch, I was just trying to remove the reference to "save",
> which was the label I removed. I agree I should have left the new
> label on the ID, "edit". But I think this is a different discussion,
> regarding coding consistency, which [definitely] needs to be addressed
> in future patches. I'll use "guest-edit-button-edit" in the next
> version of this patch to keep the style you mentioned.
Agree. The naming rules is totally not consistent because we didn't
propose one unified. I also think we need have a unified naming rule (as
well as same user experience through out Kimchi, including windows,
dialog s, buttons, operation behaviors, etc.). Maybe we need propose a
coding/designing guideline documentation for future code. If we are
planning to, I'm glad to be involved in.