- 18 4月, 2016 7 次提交
-
-
由 Peter Krempa 提交于
Break long lines and format headers correctly.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
The event test does not try to include libvirt internals. Using a macro named VIR_DEBUG might hint to such usage. Additionally it's useless since it's used only in the main() function. Modernize the message strings while touching them.
-
由 Peter Krempa 提交于
Most of the functions are no longer in this file. 'usage' does not need a declaration.
-
由 Jason J. Herne 提交于
virTypedParamsValidate currently uses an index based check to find duplicate parameters. This check does not work. Consider the following simple example: We have only 2 keys A (multiples allowed) B (multiples NOT allowed) We are given the following list of parameters to check: A A B If you work through the validation loop you will see that our last iteration through the loop has i=2 and j=1. In this case, i > j and keys[j].value.i will indicate that multiples are not allowed. Both conditionals are satisfied so an incorrect error will be given: "parameter '%s' occurs multiple times" This patch replaces the index based check with code that remembers the name of the last parameter seen and only triggers the error case if the current parameter name equals the last one. This works because the list is sorted and duplicate parameters will be grouped together. In reality, we hit this bug while using selective block migration to migrate a guest with 5 disks. 5 was apparently just the right number to push i > j and hit this bug. virsh migrate --live guestname --copy-storage-all --migrate-disks vdb,vdc,vdd,vde,vdf qemu+ssh://dsthost/systemSigned-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by: NEric Farman <farman@linux.vnet.ibm.com>
-
由 Dmitry Andreev 提交于
Migration API allows to specify a destination domain configuration. Offline domain has only inactive XML and it is replaced by configuration specified using VIR_MIGRATE_PARAM_DEST_XML param. In case of live migration VIR_MIGRATE_PARAM_DEST_XML param is applied for active XML. This commit introduces the new VIR_MIGRATE_PARAM_PERSIST_XML param that can be used within live migration to replace persistent/inactive configuration. Required for: https://bugzilla.redhat.com/show_bug.cgi?id=835300
-
由 Dmitry Andreev 提交于
This changes allow to use qemuMigrationCookieAddPersistent with an XML definition that isn't assigned to any domain.
-
- 17 4月, 2016 1 次提交
-
-
由 Richard Laager 提交于
By default, `zfs create -V ...` reserves space for the entire volsize, plus some extra (which attempts to account for overhead). If `zfs create -s -V ...` is used instead, zvols are (fully) sparse. A middle ground (partial allocation) can be achieved with `zfs create -s -o refreservation=... -V ...`. Both libvirt and ZFS support this approach, so the ZFS storage backend should support it. Signed-off-by: NRichard Laager <rlaager@wiktel.com>
-
- 16 4月, 2016 6 次提交
-
-
由 John Ferlan 提交于
Commit id '4b75237f' seems to have triggered Coverity into finding at least one memory leak in xen_xl.c for error path for cleanup where the listenAddr would be leaked. Reviewing other callers, it seems that qemu_parse_command.c would have the same issue, so just it too.
-
由 John Ferlan 提交于
Coverity found that commit id 'c661b675' needed to create a cleanup path to handle the closing of 'fp' if the virBitmapNewQuiet failed.
-
由 John Ferlan 提交于
Commit id '0da965c5' removed the 11th parameter, but neglected to remove the ATTRIBUTE_NONNULL for it and adjust the 17th and 18th.
-
由 Jim Fehlig 提交于
To ensure the libvirt libxl driver will build with future versions of Xen where the libxl API may change in incompatible ways, explicitly use LIBXL_API_VERSION 0x040200. The libxl driver does use new libxl APIs that have been added since Xen 4.2, but currently it does not make use of any changes made to existing APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity. The version can be bumped if/when the libxl driver consumes the changed APIs. Further details can be found in the following discussion thread https://www.redhat.com/archives/libvir-list/2016-April/msg00178.htmlSigned-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Martin Kletzander 提交于
When creating the master key, we used mode 0600 (which we should) but because we were creating it as root, the file is not readable by any qemu running as non-root. Fortunately, it's just a matter of labelling the file. We are generating the file path few times already, so let's label it in the same function that has access to the path already. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Jiri Denemark 提交于
Recent patches addiing support for ploop volumes did not properly update gluster backend. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 15 4月, 2016 26 次提交
-
-
由 Richard W.M. Jones 提交于
In a few places in libvirt we busy-wait for events, for example qemu creating a monitor socket. This is problematic because: - We need to choose a sufficiently small polling period so that libvirt doesn't add unnecessary delays. - We need to choose a sufficiently large polling period so that the effect of busy-waiting doesn't affect the system. The solution to this conflict is to use an exponential backoff. This patch adds two functions to hide the details, and modifies a few places where we currently busy-wait. Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>
-
由 Olga Krishtal 提交于
In case of ploop volume, target path of the volume is the path to the directory that contains image file named root.hds and DiskDescriptor.xml. While using uploadVol and downloadVol callbacks we need to open root.hds itself. Upload or download operations with ploop volume are only allowed when images do not have snapshots. Otherwise operation fails. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Olga Krishtal 提交于
Refreshes meta-information such as allocation, capacity, format, etc. Ploop volumes differ from other volume types. Path to volume is the path to directory with image file root.hds and DiskDescriptor.xml. https://openvz.org/Ploop/format Due to this fact, operations of opening the volume have to be done once again. get the information. To decide whether the given volume is ploops one, it is necessary to check the presence of root.hds and DiskDescriptor.xml files in volumes' directory. Only in this case the volume can be manipulated as the ploops one. Such strategy helps us to resolve problems that might occure, when we upload some other volume type from ploop source. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Olga Krishtal 提交于
Returns error in case of vol-wipe cmd for a ploop volume Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
-
由 Olga Krishtal 提交于
Changes the size of given ploop volume via ploop resize tool. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
-
由 Olga Krishtal 提交于
Recursively deletes whole directory of a ploop volume. To delete ploop image it has to be unmounted. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
-
由 Olga Krishtal 提交于
These callbacks let us to create ploop volumes in dir, fs and etc. pools. If a ploop volume was created via buildVol callback, then this volume is an empty ploop device with DiskDescriptor.xml. If the volume was created via .buildFrom - then its content is similar to input volume content. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Olga Krishtal 提交于
Ploop image consists of directory with two files: ploop image itself, called root.hds and DiskDescriptor.xml that contains information about ploop device: https://openvz.org/Ploop/format. Such volume are difficult to manipulate in terms of existing volume types because they are neither a single files nor a directory. This patch introduces new volume type - ploop. This volume type is used by ploop volume's exclusively. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
To prevent the error messages in cfg.mk from triggering the very same rules they're supposed to explain, we split the message in the middle of a symbol name, ending up with stuff like 'I am a me'ssage Instead of relying on these quotation tricks, simply exclude cfg.mk from the relevant checks.
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Peter Krempa 提交于
Rather than trying some magic calculations on our side query the monitor for the current size of the memory balloon both on hotplug and hotunplug. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1220702
-
由 Peter Krempa 提交于
No need to store failure and re-check right away.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Now that there is just one format of the memory balloon command line used the code can be merged into a single function. Additionally with some tweaks to the control flow the code is easier to read.
-
由 Peter Krempa 提交于
The change that made qemu not add the memballoon by default happened prior to 0.12.0. Additionaly the comment was misleading due to the code that was added below. Since we always need to add a balloon on the commandline drop the comment.
-
由 Peter Krempa 提交于
The flag is now unused and all qemus supported by libvirt already support it.
-
由 Peter Krempa 提交于
-
由 Cole Robinson 提交于
Move some API specific documentation out of -docs package and into -devel, and some end user docs out of -devel and into -docs, then drop the -devel dep on -docs. This is more in line with the suggested Fedora guidelines. https://bugzilla.redhat.com/show_bug.cgi?id=1310155
-
由 Cole Robinson 提交于
The only caller of this code is: for (i = 0; i < dom->def->ngraphics; i++) { if (dom->def->graphics[i]->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE) { if (!(mig->graphics = qemuMigrationCookieGraphicsAlloc(driver, dom->def->graphics[i]))) return -1; mig->flags |= QEMU_MIGRATION_COOKIE_GRAPHICS; break; } } So this is never triggered for VNC, and in fact VNC has no support for seamless migration anyways so that seems correct. Drop the dead VNC handling.
-
由 Erik Skultety 提交于
The reason for this is to fix the automatic rebuild of libvirt-common.h.in. All *.in files should be automatically rebuilt each time they're modified. It works well for makefiles and pkgconfig files, since they do have a valid dependency in the top-level Makefile. However, with libvirt-common.h.in there is no dependency in the top-level Makefile and there's no need for it either, so this rule include/libvirt/libvirt-common.h: $(top_builddir)/config.status \ $(top_srcdir)/include/libvirt/libvirt-common.h.in cd $(top_builddir) && $(SHELL) ./config.status $@ is never hit and should be moved to include/Makefile, but that's automake's job. According to GNU automake docs: "Files created by AC_CONFIG_FILES, be they Automake Makefiles or not, are all removed by ‘make distclean’. Their inputs are automatically distributed, unless they are the output of prior AC_CONFIG_FILES commands. Finally, rebuild rules are generated in the Automake Makefile existing in the subdirectory of the output file, if there is one, or in the top-level Makefile otherwise." Which means that if we want to have the rule for libvirt-common.h automatically generated by automake, the include/Makefile.am needs to be moved into libvirt/ subdirectory and $SUBDIRS in the top-level Makefile need to be adjusted as well. This patch moves Makefile.am from include/ to include/libvirt, adjusting the prefixes accordingly as well as updates the top-level Makefile $SUBDIRS to properly hint automake to generate all rules at proper places. Best way to see the changes, use -M with 'git show'. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Maxim Nestratov 提交于
Since vz driver is now lives as a part of daemon we can benefit from this fact and allow vz clients to use shared drivers API like storage, network, nwfilter etc. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Laine Stump 提交于
This is backed by the qemu device pxb-pcie, which will be available in qemu 2.6.0. As with pci-expander-bus (which uses qemu's pxb device), the busNr attribute and <node> subelement of <target> are used to set the bus_nr and numa_node options. During post-parse we validate that the domain's machinetype is q35-based (since the device shows up for 440fx-based machinetypes, but is unusable), as well as checking that <node> specifies a node that is actually configured on the guest.
-
由 Laine Stump 提交于
This controller provides a single PCIe port on a new root. It is similar to pci-expander-bus, intended to provide a bus that can be associated with a guest-identifiable NUMA node, but is for machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes). Aside from PCIe vs. PCI, the other main difference is that a pci-expander-bus has a companion pci-bridge that is automatically attached along with it, but pcie-expander-bus has only a single port, and that port will only connect to a pcie-root-port, or to a pcie-switch-upstream-port. In order for the bus to be of any use in the guest, it must have either a pcie-root-port or a pcie-switch-upstream-port attached (and one or more pcie-switch-downstream-ports attached to the pcie-switch-upstream-port).
-
由 Laine Stump 提交于
The pxb device is a PCIe expander bus that can be added to any Q35-based machinetype. A single PCIe port (*not* hotpluggable) is provided; if more than one device is desired, or if hotplug support is needed, either a pcie-root-port, or some combination of pcie-switch-upstream-port and pcie-swith-downstream-ports must be added to it. It can have a NUMA node number associated with it, as well as a bus number.
-
由 Laine Stump 提交于
This is backed by the qemu device "pxb". The pxb device always includes a pci-bridge that is at the bus number of the pxb + 1. busNr and <node> from the <target> subelement are used to set the bus_nr and numa_node options for pxb. During post-parse we validate that the domain's machinetype is 440fx-based (since the pxb device only works on 440fx-based machines), and <node> also gets a sanity check to assure that the NUMA node specified for the pxb (if any - it's optional) actually exists on the guest.
-