- 21 2月, 2015 2 次提交
-
-
由 Peter Krempa 提交于
The structure will gradually become the only place for NUMA related config, thus rename it appropriately.
-
由 Peter Krempa 提交于
For weird historical reasons NUMA cells are added as a subelement of <cpu> while the actual configuration is done in <numatune>. This patch splits out the cell parser code from cpu config to NUMA config. Note that the changes to the code are minimal just to make it work and the function will be refactored in the next patch.
-
- 19 2月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
Not all files we want to find using virFileFindResource{,Full} are generated when libvirt is built, some of them (such as RNG schemas) are distributed with sources. The current API was not able to find source files if libvirt was built in VPATH. Both RNG schemas and cpu_map.xml are distributed in source tarball. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 13 2月, 2015 1 次提交
-
-
由 Ján Tomko 提交于
Add an XML attribute to allow disabling merge of rx buffers on the host: <interface ...> ... <model type='virtio'/> <driver ...> <host mrg_rxbuf='off'/> </driver> </interface> https://bugzilla.redhat.com/show_bug.cgi?id=1186886
-
- 12 2月, 2015 4 次提交
-
-
由 Martin Kletzander 提交于
In order for QEMU vCPU (and other) threads to run with RT scheduler, libvirt needs to take care of that so QEMU doesn't have to run privileged. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1178986Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Laine Stump 提交于
Prior to commit 7d5bf484 (first appearing in libvirt 1.2.2), the status XML of a domain's interface was missing a lot of important information; mainly it just output the config of the interface, plus the name of the tap device and qemu device alias. Commit 7d5bf484 changed the status XML to include many important bits of information that were required to make network "hook" scripts useful - bandwidth information, vlan tag, the name of the bridge (or physical device in the case of macvtap) that the tap/macvtap device was attached to - the commit log for 7d5bf484 has a very detailed explanation of the change. For quick reference - in the example given there, prior to the change, status XML looked like figure [C]: <interface type='network'> <source network='testnet' portgroup='admin'/> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> and after the change, it looked like figure [E]: <interface type='direct'> <source dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> You'll notice that bandwidth info, physdev, and macvtap mode have been added, but the network and portgroup names are now missing - I didn't think that this information was of any use once the needed bandwidth/vlan/etc config had been pulled from the network/portgroup. I was wrong. A few months after that change a user on IRC asked what happened to portgroup in the status XML and described how he used it (more or less as a tag to decide what external information to use in a hook script that was run at startup/migration time - see http://wiki.libvirt.org/page/OVS_and_PVLANS ). At that time I planned to make a patch to re-add portgroup, but life intervened as that was just prior to a transatlantic move involving several weeks of "vacation". During this time I somehow forgot to make the patch, and also mistakenly remembered that I *had* made it. Subsequent to this, as a part of mprivozn's work to add support for network-specific hooks, I did re-add the output of the network name in status XML, but once again completely forgot about portgroup. This was in commit a3609121 (first appearing in libvirt 1.2.11). This made the status XML from the above example look like this: <interface type='direct'> <source network='testnet' dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> *This* patch just adds the portgroup back to the status XML, so the same example interface will look like this: <interface type='direct'> <source network='testnet' portgroup='admin' dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> The result is that the status XML now contains all information about how the interface is setup (bandwidth, physical device, tap device, etc), in addition to pointers to its origin (the network and portgroup).
-
由 Laine Stump 提交于
virDomainGraphicsListenSetAddress() and virDomainGraphicsListenSetNetwork() both set their respective char* to NULL directly when asked to set it to NULL, which is okay as long as it's already set to NULL. If these functions are ever called to clear a listen object that has a valid string in address or network, it will end up leaking the old value. Currently that doesn't happen, so this is just a preemptive strike.
-
由 Laine Stump 提交于
Prior to 0.9.4, libvirt only supported a single listen, and it had to be an IP address: <graphics listen='1.2.3.4' ..../> Starting with 0.9.4, a graphics element could have a <listen> subelement (actually the grammar supports multiples, but all of the drivers only support a single <listen> per <graphics>), and that listen element can be of type='address' or type='network'. For type='address', <listen> also has an attribute called 'address' which contains the IP address for listening: <graphics ....> <listen type='address' address='1.2.3.4' .../> </graphics> type can also be "network", and in that case listen will have a "network" attribute which will contain the name of a libvirt network: <graphics ....> <listen type='network' network='testnet' .../> </graphics> At domain start (or migrate) time, libvirt will attempt to find an IP address associated with that network (e.g. the IP address of the bridge device used by the network, or the physical device listed in <forward dev='physdev'/>) and fill in that address in the status XML: <graphics ....> <listen type='network' network='testnet' address='1.2.3.4' .../> </graphics> In the case that a <graphics> element has a <listen> subelement of type='address', that listen subelement's "address" attribute is backfilled into the parent graphics element's "listen" *attribute* for backward compatibility (so that a management application unaware of the separate <listen> element can still learn the listen address). This backfill should be done with the IP learned from type='network' as well, and that's what this patch does: <graphics listen='1.2.3.4' ....> <listen type='network' network='testnet' address='1.2.3.4' .../> </graphics> This is a continuation of the fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1191016
-
- 11 2月, 2015 2 次提交
-
-
由 Zhang Bo 提交于
The function virDomainVcpuPinDel() used vcpupin_list to stand for def->cputune.vcpupin, which made the codes more readable. However, in this function, it will realloc vcpupin_list later. As the definition of realloc(), it may free vcpupin_list and then points it to a new-realloced address, but def->cputune.vcpupin doesn't point to the new address(it's freed however). Thus, 1) When we refer to the def->cputune.vcpupin afterwards, which was freed by realloc(), an INVALID READ occurs, and libvirtd may crash. 2) As no one will use vcpupin_list any more, and no one frees it(it's just alloced by realloc()), memory leak occurs. Part of the valgrind logs are shown as below: ==1837== Thread 15: ==1837== Invalid read of size 8 ==1837== at 0x5367337: virDomainDefFormatInternal (domain_conf.c:18392) which is : virBufferAsprintf(buf, "<vcpupin vcpu='%u' ", def->cputune.vcpupin[i]->vcpuid); ==1837== by 0x536966C: virDomainObjFormat (domain_conf.c:18970) ==1837== by 0x5369743: virDomainSaveStatus (domain_conf.c:19166) ==1837== by 0x117B26DC: qemuDomainPinVcpuFlags (qemu_driver.c:4586) ==1837== by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803) ==1837== by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762) ==1837== by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740) ==1837== by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437) ==1837== by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307) ==1837== by 0x171B83: virNetServerProcessMsg (virnetserver.c:172) ==1837== by 0x171E6E: virNetServerHandleJob (virnetserver.c:193) ==1837== by 0x5318E78: virThreadPoolWorker (virthreadpool.c:145) ==1837== Address 0x12ea2870 is 0 bytes inside a block of size 16 free'd ==1837== at 0x4C291AC: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==1837== by 0x52A3D14: virReallocN (viralloc.c:245) ==1837== by 0x52A3DFB: virShrinkN (viralloc.c:372) ==1837== by 0x52A3F57: virDeleteElementsN (viralloc.c:503) ==1837== by 0x533939E: virDomainVcpuPinDel (domain_conf.c:15405) //doReset为true时才会进到。 ==1837== by 0x117B2642: qemuDomainPinVcpuFlags (qemu_driver.c:4573) ==1837== by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803) ==1837== by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762) ==1837== by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740) ==1837== by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437) ==1837== by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307) ==1837== by 0x171B83: virNetServerProcessMsg (virnetserver.c:172) Steps to reproduce the problem: 1) use virDomainPinVcpuFlags() to pin a guest's vcpu to all the pcpus of the host. This patch uses def->cputune.vcpupin instead of vcpupin_list to do the realloc() job, to avoid invalid read or memory leaking. Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: Yue Wenyuan <yuewenyuan@huawei.com@huawei.com>
-
由 Erik Skultety 提交于
Parser checks for per-domain seclabel duplicates, so it would be nice if it checked for per-device seclabel duplicates the same way Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1165485
-
- 10 2月, 2015 3 次提交
-
-
由 Luyao Huang 提交于
The helpers will be useful when implementing hotplug and coldplug of random number generator devices. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
When adding devices to the definition it's useful to check whether the devices don't reside on a conflicting address. This patch adds a helper that iterates all device info and compares the addresses with the given info.
-
由 Martin Kletzander 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1190956Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 09 2月, 2015 1 次提交
-
-
由 Erik Skultety 提交于
-
- 06 2月, 2015 1 次提交
-
-
由 Ján Tomko 提交于
It is only supported for virtio adapters. Silently drop it if it was specified for other models, as is done for other virtio attributes. Also mention this in the documentation. https://bugzilla.redhat.com/show_bug.cgi?id=1147195
-
- 04 2月, 2015 2 次提交
-
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1188914 Add a missing jump to the error label in case the input device bus is invalid. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Luyao Huang 提交于
Add the missing jump to thje error label. The error message shouldn't ever be triggered though as it's called only on pre-selected nodes. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
- 30 1月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1170492 In one of our previous commits (dc8b7ce7) we've done a functional change even though it was intended as pure refactor. The problem is, that the following XML: <vcpu placement='static' current='2'>6</vcpu> <cputune> <emulatorpin cpuset='1-3'/> </cputune> <numatune> <memory mode='strict' placement='auto'/> </numatune> gets translated into this one: <vcpu placement='auto' current='2'>6</vcpu> <cputune> <emulatorpin cpuset='1-3'/> </cputune> <numatune> <memory mode='strict' placement='auto'/> </numatune> We should not change the vcpu placement mode. Moreover, we're doing something similar in case of emulatorpin and iothreadpin. If they were set, but vcpu placement was auto, we've mistakenly removed them from the domain XML even though we are able to set them independently on vcpus. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 29 1月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
After virBitmapEqual is able to compare NULL bitmaps few bits of code can be cleaned up.
-
- 28 1月, 2015 1 次提交
-
-
由 Ján Tomko 提交于
Do the allocation first, then add the actual device. The second part should never fail. This is good for live hotplug where we don't want to remove the device on OOM after the monitor command succeeded. The only change in behavior is that on failure, the vmdef->consoles array is freed, not just the first console.
-
- 27 1月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
Currently when launching the LXC controller we first write out the plain, inactive XML configuration, then launch the controller, then replace the file with the live status XML configuration. By good fortune this hasn't caused any problems other than some misleading error messages during failure scenarios. This simplifies the code so it only writes out the XML once and always writes the live status XML. To do this we need to handshake with the child process, to make execution pause just before exec() so we can write the XML status with the child PID present.
-
- 23 1月, 2015 1 次提交
-
-
由 Erik Skultety 提交于
Previously the function returned either -1 in case of an error or 0 on success. However, we should also distinguish between a case we successfully added a controller and a case there wasn't a need to add any controller
-
- 16 1月, 2015 6 次提交
-
-
由 Dmitry Guryanov 提交于
Ploop is a pseudo device which makeit possible to access to an image in a file as a block device. Like loop devices, but with additional features, like snapshots, write tracker and without double-caching. It used in PCS for containers and in OpenVZ. You can manage ploop devices and images with ploop utility (http://git.openvz.org/?p=ploop). Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>
-
由 Martin Kletzander 提交于
Just a new feature that can be turned on/off. https://bugzilla.redhat.com/show_bug.cgi?id=1178853Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 John Ferlan 提交于
Commit id 'aa2cc721' added calls to virSocketAddrFormat but did not check for a NULL (error) return which could lead to bad output in the XML file. Need to check for NULL return and cause failure. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Commit id 'aa2cc721' added call to virSocketAddrFormat and did not VIR_FREE() the returned memory. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Cédric Bosdonnat 提交于
-
由 Daniel P. Berrange 提交于
The virDomainDefineXMLFlags and virDomainCreateXML APIs both gain new flags allowing them to be told to validate XML. This updates all the drivers to turn on validation in the XML parser when the flags are set
-
- 14 1月, 2015 3 次提交
-
-
由 Michal Privoznik 提交于
There's this function virNetDevBandwidthParse which parses the bandwidth XML snippet. But it's not clever much. For the following XML it allocates the virNetDevBandwidth structure even though it's completely empty: <bandwidth> </bandwidth> Later in the code there are some places where we check if bandwidth was set or not. And since we obtained pointer from the parsing function we think that it is when in fact it isn't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrange 提交于
The virDomainDefParse* and virDomainDefFormat* methods both accept the VIR_DOMAIN_XML_* flags defined in the public API, along with a set of other VIR_DOMAIN_XML_INTERNAL_* flags defined in domain_conf.c. This is seriously confusing & error prone for a number of reasons: - VIR_DOMAIN_XML_SECURE, VIR_DOMAIN_XML_MIGRATABLE and VIR_DOMAIN_XML_UPDATE_CPU are only relevant for the formatting operation - Some of the VIR_DOMAIN_XML_INTERNAL_* flags only apply to parse or to format, but not both. This patch cleanly separates out the flags. There are two distint VIR_DOMAIN_DEF_PARSE_* and VIR_DOMAIN_DEF_FORMAT_* flags that are used by the corresponding methods. The VIR_DOMAIN_XML_* flags received via public API calls must be converted to the VIR_DOMAIN_DEF_FORMAT_* flags where needed. The various calls to virDomainDefParse which hardcoded the use of the VIR_DOMAIN_XML_INACTIVE flag change to use the VIR_DOMAIN_DEF_PARSE_INACTIVE flag.
-
由 Daniel P. Berrange 提交于
The virCPUDefFormat* methods were relying on the VIR_DOMAIN_XML_* flag definitions. It is not desirable for low level internal functions to be coupled to flags for the public API, since they may need to be called from several different contexts where the flags would not be appropriate.
-
- 13 1月, 2015 1 次提交
-
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1181408 When we try to hotplug a channel chr device with no target, we will get success (which should fail) in virDomainChrDefParseXML, because we use goto cleanup this place and return an incomplete definition (with no target). In qemuDomainAttachChrDevice, we add it to the domain definition, but fail to remove it from there when chardev-add fails, because virDomainChrRemove matches chardevices according to the target name. The device definition is then freed in qemuDomainAttachDeviceFlags, leaving a stale pointer in the domain definition. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 09 1月, 2015 1 次提交
-
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1179684 The way that we currently generate the <driver/> for <controller/> is just madness: <controller type='scsi' index='0' model='virtio-scsi'> <driver queues='12'/> <driver cmd_per_lun='123'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> It's obvious that we should be aiming at the following: <controller type='scsi' index='0' model='virtio-scsi'> <driver queues='12' cmd_per_lun='123'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
- 07 1月, 2015 1 次提交
-
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1177194 When migrate a vm, we will generate a xml via qemuDomainDefFormatLive and pass this xml to target libvirtd. Libvirt will use the current network state in def->data.network.actual to generate the xml, this will make migrate failed when we set a network type guest interface use a macvtap network as a source in a vm then migrate vm to another host(which has the different macvtap network settings: different interface name, bridge name...) Add a flag check in virDomainNetDefFormat, if we set a VIR_DOMAIN_XML_MIGRATABLE flag when call virDomainNetDefFormat, we won't get the current vm interface state. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 06 1月, 2015 4 次提交
-
-
由 Cédric Bosdonnat 提交于
Network interfaces devices and host devices with net capabilities can now have IPv4 and/or an IPv6 routes configured.
-
由 Cédric Bosdonnat 提交于
-
由 Cédric Bosdonnat 提交于
Add the possibility to have more than one IP address configured for a domain network interface. IP addresses can also have a prefix to define the corresponding netmask.
-
由 Cédric Bosdonnat 提交于
-
- 16 12月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Currently, when there is an API that's blocking with locked domain and second API that's waiting in virDomainObjListFindByUUID() for the domain lock (with the domain list locked) no other API can be executed on any domain on the whole hypervisor because all would wait for the domain list to be locked. This patch adds new optional approach to this in which the domain is only ref'd (reference counter is incremented) instead of being locked and is locked *after* the list itself is unlocked. We might consider only ref'ing the domain in the future and leaving locking on particular APIs, but that's no tonight's fairy tale. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 15 12月, 2014 1 次提交
-
-
由 Wang Rui 提交于
We can change vnc password by using virDomainUpdateDeviceFlags API with live flag. But it can't be changed with config flag. Error is reported as below. error: Operation not supported: persistent update of device 'graphics' is not supported This patch supports the graphics arguments changed with config flag. Signed-off-by: NWang Rui <moon.wangrui@huawei.com>
-