- 24 11月, 2017 3 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Move network device validation into a separate function.
-
由 Peter Krempa 提交于
Move the code so that both the new image and old image can be verified in the same function.
-
- 23 11月, 2017 16 次提交
-
-
由 Michal Privoznik 提交于
Since we already have such support for libxl all we need is qemu driver adjustment. And a test case. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
This capability says if qemu is capable of specifying distances between NUMA nodes on the command line. Unfortunately, there's no real way to check this and thus we have to go with version check. QEMU introduced this in 0f203430dd8 (and friend) which was released in 2.10.0. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
The function returns true/false depending on distance configuration being present in the domain XML. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
There's no point in checking if numa->mem_nodes[node].ndistances is set if we check for numa->mem_nodes[node].distances. However, it makes sense to check if the sibling node (@cellid) caller passed falls within boundaries. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
When QEMU dies, we read its output stored in a log file and use it for reporting a hopefully useful error. However, virReportError will trim the message to (VIR_ERROR_MAX_LENGTH - 1) characters, which means the end of the log (which likely contains the error message we want to report) may get lost. We should trim the beginning of the log instead. https://bugzilla.redhat.com/show_bug.cgi?id=1335534Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
And use it instead of a magic 1024 constant. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
When reading QEMU log for reporting it as an error message, we want to skip "char device redirected to" line. However, this string is not printed at the beginning of a line, which means STRPREFIX will never find it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Martin Kletzander 提交于
Do not access any data if strlen() == 0. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Peter Krempa 提交于
Explain that certain attributes formatted with -drive are in fact attributes of the drive itself and not the storage backing it.
-
由 Peter Krempa 提交于
That's a disk frontend attribute. Move the code to a separate function since it's non-trivial and call it from the frontend attribute formatter.
-
由 Peter Krempa 提交于
Isolate it from the other code.
-
由 Peter Krempa 提交于
Move all logic depending on whether we are solely formatting -drive (no -device along with it) into one block.
-
由 Peter Krempa 提交于
Move together sections which are conditionaly executed depending on whether -device will be used together with the -drive.
-
由 Peter Krempa 提交于
Disk serial is not a property of the image but of the disk frontend. Account for this appropriately.
-
由 Peter Krempa 提交于
Historically we've formatted a lot of the attributes of a disk (disk geometry, etc) with -drive. Since we use -device now, they should be formatted there. Extract them to a separate function for keeping compatibility with SDcards which still use only -drive. Start this by moving the geometry into a separate function.
-
由 Peter Krempa 提交于
When doing block commit we need to allow write for members of the backing chain so that we can commit the data into them. qemuDomainDiskChainElementPrepare was used for this which since commit 786d8d91 calls qemuDomainNamespaceSetupDisk which has very adverse side-effects, namely it relabels the nodes to the same label it has in the main namespace. This was messing up permissions for the commit operation since its touching various parts of a single backing chain. Since we are are actually not introducing new images at that point add a flag for qemuDomainDiskChainElementPrepare which will refrain from calling to the namespace setup function. Calls from qemuDomainSnapshotCreateSingleDiskActive and qemuDomainBlockCopyCommon do introduce new members all calls from qemuDomainBlockCommit do not, so the calls are anotated accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1506072
-
- 20 11月, 2017 7 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1434451 Just like in 9324f67a we need to put default pci-root alias onto the command line instead of the one provided by user. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1434451 Just like in 9324f67a we need to put default sata alias (which is hardcoded to "ide", obvious, right?) onto the command line instead of the one provided by user. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This function only queries domain @def. It doesn't change it. Therefore it should take const pointer. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
The compiler can warn us if we add a value to the virDomainChrSerialTargetType enumeration but forget to handle it properly in the code. Let's take advantage of that. This commit is best viewed with 'git diff -w'. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pino Toscano 提交于
Add a separate capability for the sclplmconsole device, and check it specifically instead of using QEMU_CAPS_DEVICE_SCLPCONSOLE for that too. Signed-off-by: NPino Toscano <ptoscano@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pino Toscano 提交于
Give a better name to the capability for the sclpconsole device. Signed-off-by: NPino Toscano <ptoscano@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
Up until now we assumed the spapr-vty device would always be present, which is not very nice. Check for its availability before using it instead. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 18 11月, 2017 12 次提交
-
-
由 Marc-André Lureau 提交于
Starting from qemu 2.11, the `-device vmcoreinfo` will create a fw_cfg entry for a guest to store dump details, necessary to process kernel dump with KASLR enabled and providing additional kernel details. In essence, it is similar to -fw_cfg name=etc/vmcoreinfo,file=X but in this case it is not backed by a file, but collected by QEMU itself. Since the device is a singleton and shouldn't use additional hardware resources, it is presented as a <feature> element in the libvirt domain XML. The device is arm/x86 only for now (targets that support fw_cfg+dma). Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1395248Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
Because the cache banks are initialized based on the order in which their respective directories exist on the filesystem, they can appear in different order. This is here mainly for tests because the cache directory might have different order of children nodes and tests would fail otherwise. It should not be the case with sysfs, but one can never be sure. And this does not take almost any extra time, mainly because it gets initialized once per driver. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
Sometimes the size of the bitmap matters and it might not be guessed correctly when parsing from some type of input. For example virBitmapNewData() has Byte granularity, virBitmapNewString() has nibble granularity and so on. virBitmapParseUnlimited() can be tricked into creating huge bitmap that's not needed (e.g.: "0-2,^99999999"). This function provides a way to shrink the bitmap. It is not supposed to free any memory. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
Already introduced in the past with 9479642f, but then renamed to virBitmapIntersect by a908e9e4. This time we'll really use it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
Our bitmaps can be represented as data (raw bytes for which we have virBitmapNewData() and virBitmapToData()), human representation (list of numbers in a string for which we have virBitmapParse() and virBitmapFormat()) and hexadecimal string (for which we have only virBitmapToString()). So let's add the missing complement for the last one so that we can parse hexadecimal strings. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
Truncate the output so that it is only as big as is needed to fit all the bits, not all the units from the map. This will be needed in the future in order to properly format bitmaps for kernel's sysfs files. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
It is literally only a wrapper around virBitmapNewData() and virBitmapFormat(), only the naming was wrong since it was introduced. And because we have virBitmap*String functions where the meaning of the 'String' is constant, this might confuse someone. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
This follows the virBitmapToData() function and, similarly to virBitmapNewData(), we'll be able to have virBitmapNewString() later on without name confusion. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
We can't output better memory sizes if we want to be compatible with libvirt older than the one which introduced /memory/unit, but for new things we can just output nicer capacity to the user if available. And this function enables that. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jim Fehlig 提交于
Commit 03d0959a introduced a compilation error in src/xenconfig/xen_xl.c on ARM. Found by Xen's osstest http://logs.test-lab.xenproject.org/osstest/logs/116216/build-armhf-libvirt/6.ts-libvirt-build.log
-
- 17 11月, 2017 1 次提交
-
-
由 John Ferlan 提交于
Resolve a storage driver crash as a result of a long running storageVolCreateXML when the virStorageVolPoolRefreshThread is run as a result of when a storageVolUpload completed and ran the virStoragePoolObjClearVols without checking if the creation code was currently processing a buildVol after incrementing the driver->asyncjob count. The refreshThread will now check the pool asyncjob count before attempting to pursue the pool refresh. Adjust the documentation to describe the condition. Crash from valgrind is as follows (with a bit of editing): ==21309== Invalid read of size 8 ==21309== at 0x153E47AF: storageBackendUpdateVolTargetInfo ==21309== by 0x153E4C30: virStorageBackendUpdateVolInfo ==21309== by 0x153E52DE: virStorageBackendVolRefreshLocal ==21309== by 0x153DE29E: storageVolCreateXML ==21309== by 0x562035B: virStorageVolCreateXML ==21309== by 0x147366: remoteDispatchStorageVolCreateXML ... ==21309== Address 0x2590a720 is 64 bytes inside a block of size 336 free'd ==21309== at 0x4C2F2BB: free ==21309== by 0x54CB9FA: virFree ==21309== by 0x55BC800: virStorageVolDefFree ==21309== by 0x55BF1D8: virStoragePoolObjClearVols ==21309== by 0x153D967E: virStorageVolPoolRefreshThread ... ==21309== Block was alloc'd at ==21309== at 0x4C300A5: calloc ==21309== by 0x54CB483: virAlloc ==21309== by 0x55BDC1F: virStorageVolDefParseXML ==21309== by 0x55BDC1F: virStorageVolDefParseNode ==21309== by 0x55BE5A4: virStorageVolDefParse ==21309== by 0x153DDFF1: storageVolCreateXML ==21309== by 0x562035B: virStorageVolCreateXML ==21309== by 0x147366: remoteDispatchStorageVolCreateXML ...
-
- 16 11月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
This is similar to the virDomainQemuMonitorCommand API, it can change the domain state in a way that libvirt may not understand. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-