- 02 6月, 2017 2 次提交
-
-
由 Julio Faracco 提交于
The host address or the socket path have already been checked at the begining of the function virStorageSourceParseNBDColonString(). So, when the parameter is not a unix socket, there is no reason to check the address again because if it does not exists, the logic will fail in the first IF conditional. Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
-
由 Julio Faracco 提交于
VIR_STRDUP returns -1 if the string copy was not successful. So, the current comparison/logic is throwing an error when VIR_STRDUP() returns 1. Only when source is NULL, it is considering as a success which is not right. Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
-
- 15 5月, 2017 1 次提交
-
-
由 Daniel P. Berrange 提交于
The metadata libvirt cares about is identical for version 3 as for previous versions, so we merely need list the new version number. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 05 4月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Imagine that this function is called twice over the same disk source. While in the first run all allocated memory is freed, not all pointers are set to NULL (e.g. def->srcpool). So when called again, these poitners are freed again resulting in double free. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 04 4月, 2017 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1371892 The 'capacity' value (e.g. guest logical size) for a LUKS volume is smaller than the 'physical' value of the file in the file system, so we need to account for that. When peeking at the encryption information about the volume add a fetch of the payload_offset which is described as the offset to the start of the volume data (in 512 byte sectors) in QEMU's QCryptoBlockLUKSHeader. Then adjust the ->capacity appropriately when we determine that the volume target encryption has a payload_offset value.
-
- 27 3月, 2017 4 次提交
-
-
由 Eric Blake 提交于
We keep forgetting that older setups don't like 'index': CC util/libvirt_util_la-virsysinfo.lo cc1: warnings being treated as errors util/virstoragefile.c: In function 'virStorageSourceFindByNodeName': util/virstoragefile.c:3804: error: declaration of 'index' shadows a global declaration [-Wshadow] /usr/include/string.h:489: error: shadowed declaration is here [-Wshadow] Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Martin Kletzander 提交于
STREQ_NULLABLE returns true if both parameters are NULL. And that's not what we want here. We just want to skop comparing source nodes that don't have that info set. The function wouldn't make much sense with nodeName == NULL, so we don't need to check that. Moreover, the function's declaration uses ATTRIBUDE_NONNULL for nodeName, which not only means that function expects the parameter not to be NULL, but actually tells the compiler that it can optimize out the NULL checks. That way it could end up calling strcmp on NULL (either nodeformat or nodebacking). GCC figures this out if libvirt is compiled with lv_cv_static_analysis=yes, unfortunately not everyone uses that. Caused by cbc6d535. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Peter Krempa 提交于
'nodeformat' should be used for strings which describe the storage format object, and 'nodebacking' for the actual storage object itself.
-
由 Peter Krempa 提交于
The function has very specific semantics. Split out the part that parses the backing store specification string into a separate helper so that it can be reused later while keeping the wrapper with existing semantics. Note that virStorageFileParseChainIndex is pretty well covered by the test suite.
-
- 22 2月, 2017 2 次提交
-
-
由 Tomáš Golembiovský 提交于
The 'raw' block driver in Qemu is not directly interesting from libvirt's perspective, but it can be layered above some other block drivers and this may be interesting for the user. The patch adds support for the 'raw' block driver. The driver is treated simply as a pass-through and child driver in JSON is queried to get the necessary information. Signed-off-by: NTomáš Golembiovský <tgolembi@redhat.com>
-
由 Tomáš Golembiovský 提交于
Split virStorageSourceParseBackingJSON into two functions so that the core can be reused by other functions. The new function called virStorageSourceParseBackingJSONInternal accepts virJSONValuePtr. Signed-off-by: NTomáš Golembiovský <tgolembi@redhat.com>
-
- 10 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
The code at the very bottom of the DAC secdriver that calls chown() should be fine with read-only data. If something needs to be prepared it should have been done beforehand. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 17 12月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Similarly to 29bb0669 forbid paths used with blockjobs to be relative. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1300177
-
- 14 12月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
Almost none of our virJSONValue*Get* functions accept const virJSONValue pointers and it wouldn't even make sense since we sometimes modify what we get. And because there is no reason for preventing callers of virJSONValueObjectForeachKeyValue from modifying the values they get in each iteration we can just stop doing it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 13 12月, 2016 3 次提交
-
-
由 John Ferlan 提交于
Instead of having duplicated code in qemuStorageLimitsRefresh and virStorageBackendUpdateVolTargetInfo to get capacity specific data about the storage backing source or volume -- create a common API to handle the details for both. As a side effect, virStorageFileProbeFormatFromBuf returns to being a local/static helper to virstoragefile.c For the QEMU code - if the probe is done, then the format is saved so as to avoid future such probes. For the storage backend code, there is no need to deal with the probe since we cannot call the new API if target->format == NONE. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Instead of having duplicated code in qemuStorageLimitsRefresh and virStorageBackendUpdateVolTargetInfoFD to fill in the storage backing source or volume allocation, capacity, and physical values - create a common API that will handle the details for both. The common API will fill in "default" capacity values as well - although those more than likely will be overridden by subsequent code. Having just one place to make the determination of what the values should be will make things be more consistent. For the QEMU code - the data filled in will be for inactive domains for the GetBlockInfo and DomainGetStatsOneBlock API's. For the storage backend code - the data will be filled in during the volume updates. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Commit id '8dc27259' introduced virStorageSourceUpdateBlockPhysicalSize in order to retrieve the physical size for a block backed source device for an active domain since commit id '15fa84ac' changed to use the qemuMonitorGetAllBlockStatsInfo and qemuMonitorBlockStatsUpdateCapacity API's to (essentially) retrieve the "actual-size" from a 'query-block' operation for the source device. However, the code only was made functional for a BLOCK backing type and it neglected to use qemuOpenFile, instead using just open. After the open the block lseek would find the end of the block and set the physical value, close the fd and return. Since the code would return 0 immediately if the source device wasn't a BLOCK backed device, the physical would be displayed incorrectly, such as follows in domblkinfo for a file backed source device: Capacity: 1073741824 Allocation: 0 Physical: 0 This patch will modify the algorithm to get the physical size for other backing types and it will make use of the qemuDomainStorageOpenStat helper in order to open/stat the source file depending on its type. The qemuDomainGetStatsOneBlock will no longer inhibit printing errors, but it will still ignore them leaving the physical value set to 0. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 25 11月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
We have couple of functions that operate over NULL terminated lits of strings. However, our naming sucks: virStringJoin virStringFreeList virStringFreeListCount virStringArrayHasString virStringGetFirstWithPrefix We can do better: virStringListJoin virStringListFree virStringListFreeCount virStringListHasString virStringListGetFirstWithPrefix Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 11月, 2016 1 次提交
-
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
- 12 9月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Commit id 'a48c7141' altered how to determine if a volume was encrypted by adding a peek at an offset into the file at a specific buffer location. Unfortunately, all that was compared was the first "char" of the buffer against the expect "int" value. Restore the virReadBufInt32BE to get the complete field in order to compare against the expected value from the qcow2EncryptionInfo or qcow1EncryptionInfo "modeValue" field. This restores the capability to create a volume with encryption, then refresh the pool, and still find the encryption for the volume.
-
- 06 9月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
RBD in qemu still uses only the legacy 'filename' syntax. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1371758
-
由 Peter Krempa 提交于
Commit 2ed772cd forgot to set proper protocol. This was also present in the test data. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372251
-
- 20 8月, 2016 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1367259 Crash occurs because 'secrets' is being dereferenced in call: if (qemuDomainSecretSetup(conn, priv, secinfo, disk->info.alias, VIR_SECRET_USAGE_TYPE_VOLUME, NULL, &src->encryption->secrets[0]->seclookupdef, true) < 0) (gdb) p *src->encryption $1 = {format = 2, nsecrets = 0, secrets = 0x0, encinfo = {cipher_size = 0, cipher_name = 0x0, cipher_mode = 0x0, cipher_hash = 0x0, ivgen_name = 0x0, ivgen_hash = 0x0}} (gdb) bt priv=priv@entry=0x7fffc03be160, disk=disk@entry=0x7fffb4002ae0) at qemu/qemu_domain.c:1087 disk=0x7fffb4002ae0, vm=0x7fffc03a2580, driver=0x7fffc02ca390, conn=0x7fffb00009a0) at qemu/qemu_hotplug.c:355 Upon entry to qemuDomainAttachVirtioDiskDevice, src->encryption points at a valid 'secret' buffer w/ nsecrets == 1; however, the call to qemuDomainDetermineDiskChain will call virStorageFileGetMetadata and eventually virStorageFileGetMetadataInternal where the src->encryption was overwritten when probing the volume. Commit id 'a48c7141' added code to virStorageFileGetMetadataInternal to determine if the disk/volume would use/need encryption and allocated a meta->encryption. This overwrote an existing encryption buffer already provided by the XML This patch adds a check for meta->encryption already present before just allocating and overwriting an existing buffer. It then checks the existing encryption data to ensure the XML provided format for the disk matches the expected format read from the disk and errors if there is a mismatch.
-
- 16 8月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
qemu uses 'url' instead of 'uri'. They unfortunately look very similar. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1367260
-
- 28 7月, 2016 2 次提交
-
-
由 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>
-
由 Daniel P. Berrange 提交于
Refactor the virStorageFileMatchesNNN methods so that they don't take a struct FileFormatInfo parameter, but instead get the actual raw dat items they needs. This will facilitate reuse in other contexts. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 27 7月, 2016 10 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Allow using 'ssh' protocol in backing chains and later for disks themselves.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
iSCSI is a bit odd in this aspect since it only supports URIs but using the 'filename' property and does not have any alternative syntax.
-
由 Peter Krempa 提交于
Along with the legacy URI based syntax add support for the brand-new fully object based syntax.
-
由 Peter Krempa 提交于
http(s), ftp(s) and tftp use URIs for volume definitions in the JSON pseudo protocol so it's pretty straightforward to add support for them.
-
由 Peter Krempa 提交于
JSON pseudo protocol for qemu allows to explicitly specify devices. Add convertor to the internal type.
-
由 Peter Krempa 提交于
Add a modular parser that will allow to parse 'json' backing definitions that are supported by qemu. The initial implementation adds support for the 'file' driver. Due to the approach qemu took to implement the JSON backing strings it's possible to specify them in two approaches. The object approach: json:{ "file" : { "driver":"file", "filename":"/path/to/file" } } And a partially flattened approach: json:{"file.driver":"file" "file.filename":"/path/to/file" } Both of the above are supported by qemu and by the code added in this commit. The current implementation de-flattens the first level ('file.') if possible and required. Other handling may be added later but currently only one level was possible anyways.
-
由 Peter Krempa 提交于
As we already test that the extraction of the backing store string works well additional tests for the backing store string parser can be made simpler. Export virStorageSourceNewFromBackingAbsolute and use it to parse the backing store strings, format them using virDomainDiskSourceFormat and match them against expected XMLs.
-
- 25 6月, 2016 2 次提交
-
-
由 John Ferlan 提交于
Add the ability to detect a luks encrypted device. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
The version field historically has been a 4 byte data; however, an upcoming new type will use a 2 byte version. So let's adjust for that now. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 6月, 2016 2 次提交
-
-
由 John Ferlan 提交于
Add utility to format the virSecretLookupTypeDefPtr in XML Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Move to virsecret.c and rename to virSecretLookupParseSecret. Also convert to usage xmlNodePtr and virXMLPropString rather than virXPathString. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-