- 26 9月, 2016 8 次提交
-
-
由 Michal Privoznik 提交于
When creating a copy of virDomainDef we save ourselves the trouble of writing deep-copy functions and just format and parse back domain/device XML. However, the XML we are parsing was already fully formatted - there is no reason to run post parse callbacks (which fill in blanks - there are none!). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is an internal flag that prevents our two entry points to XML parsing (virDomainDefParse and virDomainDeviceDefParse) from running post parse callbacks. This is expected to be used in cases when we already have full domain/device XML and we are just parsing it back (i.e. virDomainDefCopy or virDomainDeviceDefCopy) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Just like virDomainDefPostParseCallback has gained new parseOpaque argument, we need to follow the logic with virDomainDeviceDefPostParse. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We want to pass the proper opaque pointer instead of NULL to virDomainDefParseString. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We want to pass the proper opaque pointer instead of NULL to virDomainDefParse and subsequently virDomainDefParseNode too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We want to pass the proper opaque pointer instead of NULL to virDomainDefParseXML and subsequently virDomainDefPostParse too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Some callers might want to pass yet another pointer to opaque data to post parse callbacks. The driver generic one is not enough because two threads executing post parse callback might want to see different data (e.g. domain object pointer that domain def belongs to). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 23 9月, 2016 1 次提交
-
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
- 22 9月, 2016 10 次提交
-
-
由 Jiri Denemark 提交于
The domain capabilities XML is capable of showing whether each guest CPU mode is supported or not with a possibility to provide additional details. This patch enhances host-model capability to advertise the exact CPU model which will be used as a host-model: <cpu> ... <mode name='host-model' supported='yes'> <model fallback='allow'>Broadwell</model> <vendor>Intel</vendor> <feature policy='disable' name='aes'/> <feature policy='require' name='vmx'/> </mode> ... </cpu> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The function filters all CPU features through a given callback while copying CPU model related parts of a CPU definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The function moves CPU model related parts from one CPU definition to another. It can be used to avoid unnecessary copies from a temporary CPU definitions which will be freed anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Useful for copying a CPU definition without model related parts (i.e., without model name, feature list, vendor). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
In case a hypervisor is able to tell us a list of supported CPU models and whether each CPU models can be used on the current host, we can propagate this to domain capabilities. This is a better alternative to calling virConnectCompareCPU for each supported CPU model. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Listing all CPU models supported by QEMU in domain capabilities makes little sense when libvirt will refuse any model it doesn't know about. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 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>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
- 21 9月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Return whether the live or persistent definition was returned. Sometimes it's necessary to base the decisions on this.
-
- 20 9月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 16 9月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
This way we'll be able to hotplug with both --live and --config in one API call. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 13 9月, 2016 2 次提交
-
-
由 Laine Stump 提交于
In a full domain config, libvirt allows overriding the normal PCI vs. PCI Express rules when a device address is explicitly provided (so, e.g., you can force a legacy PCI device to plug into a PCIe port, although libvirt would never do that on its own). However, due to a bug libvirt doesn't give this same leeway when hotplugging devices. On top of that, current libvirt assumes that *all* devices are legacy PCI. The result of all this is that it's impossible to hotplug a device into a PCIe port, even if you manually add the PCI address. This can all be traced to the function virDomainPCIAddressEnsureAddr(), and the fact that it calls virDomainPCIaddressReserveSlot() for manually set addresses, and that function hardcodes the argument "fromConfig" to false (meaning "this address was auto-assigned, so it should be subject to stricter validation"). Since virDomainPCIAddressReserveSlot() is just a one line simple wrapper around virDomainPCIAddressReserveAddr() (adding in a hardcoded reserveEntireSlot = true and fromConfig = false), all that's needed to solve the problem with no unwanted side effects is to replace that call for virDomainPCIAddressReserveSlot() with a direct call to virDomainPCIAddressReserveAddr(), but with reserveEntireSlot = true, fromConfig = true. That's what this patch does. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1337490
-
由 Martin Kletzander 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1218603Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 09 9月, 2016 4 次提交
-
-
由 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>
-
由 John Ferlan 提交于
If the incoming XML defined a path to a TLS X.509 certificate environment, add the necessary 'tls-creds-x509' object to the VIR_DOMAIN_CHR_TYPE_TCP character device. Likewise, if the environment exists the hot unplug needs adjustment as well. Note that all the return ret were changed to goto cleanup since the cfg needs to be unref'd Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
The code for replacing domain's transient definition with the persistent one is repeated in several places and we'll need to add one more. Let's make a nice helper for it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 06 9月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
In the latest glibc, major() and minor() functions are marked as deprecated (glibc commit dbab6577): CC util/libvirt_util_la-vircgroup.lo util/vircgroup.c: In function 'virCgroupGetBlockDevString': util/vircgroup.c:768:5: error: '__major_from_sys_types' is deprecated: In the GNU C Library, `major' is defined by <sys/sysmacros.h>. For historical compatibility, it is currently defined by <sys/types.h> as well, but we plan to remove this soon. To use `major', include <sys/sysmacros.h> directly. If you did not intend to use a system-defined macro `major', you should #undef it after including <sys/types.h>. [-Werror=deprecated-declarations] if (virAsprintf(&ret, "%d:%d ", major(sb.st_rdev), minor(sb.st_rdev)) < 0) ^~ In file included from /usr/include/features.h:397:0, from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdio.h:28, from ../gnulib/lib/stdio.h:43, from util/vircgroup.c:26: /usr/include/sys/sysmacros.h:87:1: note: declared here __SYSMACROS_DEFINE_MAJOR (__SYSMACROS_FST_IMPL_TEMPL) ^ Moreover, in the glibc commit, there's suggestion to keep ordering of including of header files as implemented here. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 03 9月, 2016 1 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Since the domain lock is not held during preparation of an external XML config, it is possible that the value can change resulting in unexpected failures during ABI consistency checking for some save and migrate operations. This patch adds a new flag to skip the checking of the cur_balloon value and then sets the destination value to the source value to ensure subsequent checks without the skip flag will succeed. This way it is protected from forges and is keeped up to date too. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
- 02 9月, 2016 1 次提交
-
-
由 Xian Han Yu 提交于
The 'multi' element in PCI address struct used as 'virTristateSwitch', and its default value is 'VIR_TRISTATE_SWITCH_ABSENT'. Current PCI process use 'false' to initialization 'multi', which is ambiguously for assignment or comparison. This patch use '{0}' to initialize the whole PCI address struct, which fix the 'multi' initialization and makes code more simplify and explicitly. Signed-off-by: NXian Han Yu <xhyubj@linux.vnet.ibm.com>
-
- 29 8月, 2016 1 次提交
-
-
由 Roman Bogorodskiy 提交于
Test 12 from objecteventtest (createXML add event) segaults on FreeBSD with bus error. At some point it calls testNodeDeviceDestroy() from the test driver. And it fails when it tries to unlock the device in the "out:" label of this function. Unlocking fails because the previous step was a call to virNodeDeviceObjRemove from conf/node_device_conf.c. This function removes the given device from the device list and cleans up the object, including destroying of its mutex. However, it does not nullify the pointer that was given to it. As a result, we end up in testNodeDeviceDestroy() here: out: if (obj) virNodeDeviceObjUnlock(obj); And instead of skipping this, we try to do Unlock and fail because of malformed mutex. Change virNodeDeviceObjRemove to use double pointer and set pointer to NULL.
-
- 26 8月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
../../src/conf/domain_conf.c:4425:21: error: potential null pointer dereference [-Werror=null-dereference] switch (vcpu->hotpluggable) { ~~~~^~~~~~~~~~~~~~
-
由 Peter Krempa 提交于
Validating the vcpu count is more intricate and doing it in the XML parser will make previously valid configs (with older qemus) vanish. Now that we have a very similar check in the qemu domain validation callback we can do it in a more appropriate place. This basically reverts commit b54de083. Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370066
-
- 25 8月, 2016 1 次提交
-
-
由 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
-
- 17 8月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Modify virDomainDefGetVcpuSched to emit an error message if virDomainDefGetVcpu returns NULL meaning the vcpu could not be found. Prior to commit id '9cc931f0' the error message would have been issued in virDomainDefGetVcpu.
-
- 16 8月, 2016 1 次提交
-
-
由 John Ferlan 提交于
When commit id '6dfb4507' refactored where the iothreadsched data was stored, the error message for when the virDomainIOThreadIDFind failed to find an iothreadid ("iothreadsched attribute 'iothreads' uses undefined iothread ids") was lost. This led to the possibility that someone would try to use it, but receive the generic message "An error occurred, but the cause is unknown". This patch adds the error message back so that someone will know that they have an invalid configuration. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-