- 22 9月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
The patch adds <cpu> element to domain capabilities XML: <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'/> <mode name='custom' supported='yes'> <model>Broadwell</model> <model>Broadwell-noTSX</model> ... </mode> </cpu> Applications can use it to inspect what CPU configuration modes are supported for a specific combination of domain type, emulator binary, guest architecture and machine type. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 21 9月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1322717 During offline migration, no storage is copied. Nor disks, nor NVRAM file, nor anything. We use qemu for that and because domain is not running there's nobody to copy that for us. We should document this to avoid confusing users. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 19 9月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
The layout in $HOME/.pki is different from that in /etc/pki but we never tell anyone about this trap. Add docs showing the required $HOME/.pki layout.
-
- 16 9月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
It already is used and tests will be automatically added in later patches. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 13 9月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1218603Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 09 9月, 2016 2 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1366989 QEMU added another virtio-net tunable [1]. It basically allows users to set the size of RX virtio ring. But because virtio-net uses two separate ring buffers to pass data from/to guest they named it explicitly rx_queue_size. We should expose it in our XML too. 1: http://lists.nongnu.org/archive/html/qemu-devel/2016-08/msg02029.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Add a new secret usage type known as "tls" - it will handle adding the secret objects for various TLS objects that need to provide some sort of passphrase in order to access the credentials. The format is: <secret ephemeral='no' private='no'> <description>Sample TLS secret</description> <usage type='tls'> <name>mumblyfratz</name> </usage> </secret> Once defined and a passphrase set, future patches will allow the UUID to be set in the qemu.conf file and thus used as a secret for various TLS options such as a chardev serial TCP connection, a NBD client/server connection, and migration. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 06 9月, 2016 1 次提交
-
-
由 Roman Mohr 提交于
Signed-off-by: NRoman Mohr <rmohr@redhat.com>
-
- 03 9月, 2016 1 次提交
-
-
由 Qiaowei Ren 提交于
With current perf framework, this patch adds support and documentation for more perf events, including cache misses, cache references, cpu cycles, and instructions. Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com>
-
- 02 9月, 2016 1 次提交
-
-
由 Daniel Veillard 提交于
* docs/news.html.in: update for release * po/*po*: regenerate
-
- 27 8月, 2016 1 次提交
-
-
由 Christophe Fergeau 提交于
The iothread example for virtio-scsi should be <driver iothread='4'/> rather than <driver iothread='4'> for the XML to be valid.
-
- 26 8月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Make it clear that vcpu order is valid for online vcpus only and state that it has to be specified for all vcpus or not provided at all. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370043
-
- 25 8月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
Add support for using the new approach to hotplug vcpus using device_add during startup of qemu to allow sparse vcpu topologies. There are a few limitations imposed by qemu on the supported configuration: - vcpu0 needs to be always present and not hotpluggable - non-hotpluggable cpus need to be ordered at the beginning - order of the vcpus needs to be unique for every single hotpluggable entity Qemu also doesn't really allow to query the information necessary to start a VM with the vcpus directly on the commandline. Fortunately they can be hotplugged during startup. The new hotplug code uses the following approach: - non-hotpluggable vcpus are counted and put to the -smp option - qemu is started - qemu is queried for the necessary information - the configuration is checked - the hotpluggable vcpus are hotplugged - vcpus are started This patch adds a lot of checking code and enables the support to specify the individual vcpu element with qemu.
-
由 Peter Krempa 提交于
Individual vCPU hotplug requires us to track the state of any vCPU. To allow this add the following XML: <domain> ... <vcpu current='2'>3</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/> <vcpu id='1' enabled='no' hotpluggable='yes'/> </vcpus> ... The 'enabled' attribute allows to control the state of the vcpu. 'hotpluggable' controls whether given vcpu can be hotplugged and 'order' allows to specify the order to add the vcpus.
-
- 20 8月, 2016 3 次提交
-
-
由 Laine Stump 提交于
For some unknown reason the original implementation of the <forwarder> element only took advantage of part of the functionality in the dnsmasq feature it exposes - it allowed specifying the ip address of a DNS server which *all* DNS requests would be forwarded to, like this: <forwarder addr='192.168.123.25'/> This is a frontend for dnsmasq's "server" option, which also allows you to specify a domain that must be matched in order for a request to be forwarded to a particular server. This patch adds support for specifying the domain. For example: <forwarder domain='example.com' addr='192.168.1.1'/> <forwarder domain='www.example.com'/> <forwarder domain='travesty.org' addr='10.0.0.1'/> would forward requests for bob.example.com, ftp.example.com and joe.corp.example.com all to the DNS server at 192.168.1.1, but would forward requests for travesty.org and www.travesty.org to 10.0.0.1. And due to the second line, requests for www.example.com, and odd.www.example.com would be resolved by the libvirt network's own DNS server (i.e. thery wouldn't be immediately forwarded) even though they also match 'example.com' - the match is given to the entry with the longest matching domain. DNS requests not matching any of the entries would be resolved by the libvirt network's own DNS server. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1331796
-
由 Laine Stump 提交于
If you define a libvirt virtual network with one or more IP addresses, it starts up an instance of dnsmasq. It's always been possible to avoid dnsmasq's dhcp server (simply don't include a <dhcp> element), but until now it wasn't possible to avoid having the DNS server listening; even if the network has no <dns> element, it is started using default settings. This patch adds a new attribute to <dns>: enable='yes|no'. For backward compatibility, it defaults to 'yes', but if you don't want a DNS server created for the network, you can simply add: <dns enable='no'/> to the network configuration, and next time the network is started there will be no dns server created (if there is dhcp configuration, dnsmasq will be started with "port=0" which disables the DNS server; if there is no dhcp configuration, dnsmasq won't be started at all).
-
由 Laine Stump 提交于
The new forward mode 'open' is just like mode='route', except that no firewall rules are added to assure that any traffic does or doesn't pass. It is assumed that either they aren't necessary, or they will be setup outside the scope of libvirt. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=846810
-
- 12 8月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1353296 On UNIX like systems there are no constraints on what characters can be in file/dir names (except for NULL, obviously). Moreover, some values that we think of as paths (e.g. disk source) are not necessarily paths at all. For instance, some hypervisors take that as an arbitrary identifier and corresponding file is then looked up by hypervisor in its table. Instead of trying to fix our regular expressions (and forgetting to include yet another character there), lets drop the validation completely. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 8月, 2016 1 次提交
-
-
由 Laine Stump 提交于
I apparently misunderstood Marcel's description of what could and couldn't be plugged into qemu's pxb-pcie controller (known as pcie-expander-bus in libvirt) - I specifically allowed directly connecting a pcie-switch-upstream-port, and it turns out that causes the guest kernel to crash. This patch forbids such a connection, and updates the xml docs appropriately. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1361172
-
- 08 8月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
So, I've ran into very interesting problem lately. When doing the following, I've encountered an error: libvirt.git $ make dist && tar -xJf libvirt-2.2.0.tar.xz && \ cd libvirt-2.2.0 && ./configure && \ rm docs/formatdomain.html && make -C docs make: Entering directory 'docs' make: *** No rule to make target 'formatdomain.html', needed by 'web'. Stop. make: Leaving directory 'docs' I had no idea what was going on, so I've nailed down the commit that "broke it" via running git-bisect. It was this one: 7659bd92. But that shed no more light until I realized that the commit might actually just exposed a problem we had. And guess what - I've nailed it down. Of course we are not distributing subsite.xsl that's why make prints error message. Very misleading one I must say. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 04 8月, 2016 2 次提交
-
-
由 Michal Privoznik 提交于
This element will control secure boot implemented by some firmwares. If the firmware used in <loader/> does support the feature we must tell it to the underlying hypervisor. However, we can't know whether loader does support it or not just by looking at the file. Therefore we have to have an attribute to the element where users can tell us whether the firmware is secure boot enabled or not. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Since its release of 2.4.0 qemu is able to enable System Management Module in the firmware, or disable it. We should expose this capability in the XML. Unfortunately, there's no good way to determine whether the binary we are talking to supports it. I mean, if qemu's run with real machine type, the smm attribute can be seen in 'qom-list /machine' output. But it's not there when qemu's run with -M none. Therefore we're stuck with version based check. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 03 8月, 2016 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1356937 Add the definitions to allow for viewing/setting cgroup period and quota limits for IOThreads. This is similar to the work done for emulator quota and period by commit ids 'b65dafa8' and 'e051c482'. Being able to view/set the IOThread specific values is related to more recent changes adding global period (commmit id '4d92d58f') and global quota (commit id '55ecdae0') definitions and qemu support (commit id '4e17ff79' and 'fbcbd1b2'). With a global setting though, if somehow the IOThread value in the cgroup hierarchy was set "outside of libvirt" to a value that is incompatible with the global value. Allowing control over IOThread specific values provides the capability to alter the IOThread values as necessary.
-
- 02 8月, 2016 3 次提交
-
-
由 Cédric Bosdonnat 提交于
Introduce libxl hook and use it for start, prepare, started, stop, stopped, migrate events.
-
由 Chunyan Liu 提交于
According to libxl implementation, it supports pvusb controller of version 1.1 and version 2.0, and it supports two types of backend, 'pvusb' (dom0 backend) and 'qusb' (qemu backend). But currently pvusb backend is not checked in yet. To match libxl support, extend usb controller schema to support two more models: qusb1 (qusb, version 1.1) and 'qusb2' (qusb version 2.0). Signed-off-by: NChunyan Liu <cyliu@suse.com>
-
由 Daniel Veillard 提交于
* docs/news.html.in: updated for release * po/*.po*: regenerated
-
- 01 8月, 2016 2 次提交
-
-
由 Nikolay Shirokovskiy 提交于
This patch reflects cases when <interface> element and its <source> subelement for network type are formated based on actual type resolved from referenced network instead of original one. networkAllocateActualDevice and virDomainActualNetDefContentsFormat are taken as reference.
-
由 Nikolay Shirokovskiy 提交于
-
- 28 7月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
The current LUKS support has a "luks" volume type which has a "luks" encryption format. This partially makes sense if you consider the QEMU shorthand syntax only requires you to specify a format=luks, and it'll automagically uses "raw" as the next level driver. QEMU will however let you override the "raw" with any other driver it supports (vmdk, qcow, rbd, iscsi, etc, etc) IOW the intention though is that the "luks" encryption format is applied to all disk formats (whether raw, qcow2, rbd, gluster or whatever). As such it doesn't make much sense for libvirt to say the volume type is "luks" - we should be saying that it is a "raw" file, but with "luks" encryption applied. IOW, when creating a storage volume we should use this XML <volume> <name>demo.raw</name> <capacity>5368709120</capacity> <target> <format type='raw'/> <encryption format='luks'> <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/> </encryption> </target> </volume> and when configuring a guest disk we should use <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/home/berrange/VirtualMachines/demo.raw'/> <target dev='sda' bus='scsi'/> <encryption format='luks'> <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/> </encryption> </disk> This commit thus removes the "luks" storage volume type added in commit 318ebb36 Author: John Ferlan <jferlan@redhat.com> Date: Tue Jun 21 12:59:54 2016 -0400 util: Add 'luks' to the FileTypeInfo The storage file probing code is modified so that it can probe the actual encryption formats explicitly, rather than merely probing existance of encryption and letting the storage driver guess the format. The rest of the code is then adapted to deal with VIR_STORAGE_FILE_RAW w/ VIR_STORAGE_ENCRYPTION_FORMAT_LUKS instead of just VIR_STORAGE_FILE_LUKS. The commit mentioned above was included in libvirt v2.0.0. So when querying volume XML this will be a change in behaviour vs the 2.0.0 release - it'll report 'raw' instead of 'luks' for the volume format, but still report 'luks' for encryption format. I think this change is OK because the storage driver did not include any support for creating volumes, nor starting guets with luks volumes in v2.0.0 - that only since then. Clearly if we change this we must do it before v2.1.0 though. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 27 7月, 2016 3 次提交
-
-
由 Prasanna Kumar Kalever 提交于
To allow using failover with gluster it's necessary to specify multiple volume hosts. Add support for starting qemu with such configurations. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Ramon Medeiros 提交于
Kimchi is a open-source interface to kvm. It runs with HTML5, simple and easy to manage kvm guests. Signed-off-by: NRamon Medeiros <ramonn@linux.vnet.ibm.com>
-
由 Anton Khramov 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1181539
-
- 20 7月, 2016 3 次提交
-
-
由 Ján Tomko 提交于
Most of the lines we look at are not going to match one of the driver types contained in $groups_regex. Move on to the next line if it does not contain any of them early. This speeds up the script execution by 50%, since this simple regex does not have any capture groups.
-
由 Ján Tomko 提交于
The %groups hash contains all the driver types (e.g. virHypervisorDriver or virSecretDriver). When searching for all the APIs that are implemented by a driver of that specific driver type, we keep iterating over the %groups hash on every line we look at, then matching against the driver type. This is inefficient because it prevents perl from caching the regex and it executes the regex once for every driver type, even though one regex matching excludes all the others, since all the driver types are different. Construct the regex containing all the driver types upfront to save about 6.4s (~98%) of the script execution time.
-
由 Ján Tomko 提交于
When generating the hvsupport.html.in file, we parse the -api.xml files generated by apibuild.py to know in which HTML file the API function is. Doing an XPath query for every single 'function' element in the file is inefficient. Since the XML file is generated by another of our build scripts (apibuild.py, using Python's standard 'output.write' XML library), just find the function name->file mapping by a regex upfront. Also add a note about this next to the line that generates it in apibuild.py and do not check if XML::XPath is installed in bootstrap since we no longer use it.
-
- 18 7月, 2016 2 次提交
-
-
由 Ján Tomko 提交于
The code for parsing the different public syms files only differs in the filenames and version prefix. Unify it to a single subroutine.
-
由 Ján Tomko 提交于
We were requiring a USB port path in the schema, but not enforcing it. Omitting the USB port would lead to libvirt formatting it as (null). Such domain cannot be started and will disappear after libvirtd restart (since it cannot parse back the XML). Only format the port if it has been specified and mark it as optional in the XML schema.
-
- 15 7月, 2016 2 次提交
-
-
由 John Ferlan 提交于
Revert the remainder of commit id 'c8438010'
-
由 John Ferlan 提交于
Commit id's 'c8438010', '9bbf0d7e', and '2552fec2' altered the documentation to describe adding a 'passphrase' type secret usage model in order to reference the secret for a luks volume. After commit, it was deemed that a 'volume' usage model should be used, so adjust the various documents in order rephrase descriptions in order to follow the correct usage model. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 12 7月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
A device with an attribute 'model', with just one model so far: <devices> ... <iommu model='intel'/> </devices> https://bugzilla.redhat.com/show_bug.cgi?id=1235580
-