- 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 3 次提交
-
-
由 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>
-
由 John Ferlan 提交于
Move the enum into a new src/util/virsecret.h, rename it to be virSecretLookupType. Add a src/util/virsecret.h in order to perform a couple of simple operations on the secret XML and virSecretLookupTypeDef for clearing and copying. This includes quite a bit of collateral damage, but the goal is to remove the "virStorage*" and replace with the virSecretLookupType so that it's easier to to add new lookups that aren't necessarily storage pool related. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 13 5月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
Move some parts of virStorageFileRemoveLastPathComponent into a separate function so they can be reused. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 5月, 2016 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1318993 Commit id 'dd519a29' caused a regression cloning a volume into a logical pool by removing just the 'allocation' adjustment during storageVolCreateXMLFrom. Combined with the change to not require the new volume input XML to have a capacity listed (commit id 'e3f1d2a8') left the possibility that a zero allocation value (e.g., not provided) would create a thin/sparse logical volume. When a thin lv becomes fully populated, then LVM sets the partition 'inactive' and the subsequent fdatasync() fails. Add a new 'has_allocation' flag to be set at XML parse time to indicate that allocation was provided. This is done so that if it's not provided the create-from code uses the capacity value since we document that if omitted, the volume will be fully allocated at time of creation. For a logical backend, that creation time is 'createVol', while for a file backend, creation doesn't set the size, but the 'createRaw' called during buildVolFrom will decide whether the file is sparse or not based on the provided capacity and allocation value. For volume clones that provide different allocation and capacity values to allow for sparse files, there is no change.
-
- 09 5月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
For disks sources described by a libvirt volume we don't need to do a complicated check since virStorageTranslateDiskSourcePool already correctly determines the actual disk type. Replace the checks using a new accessor that does not open-code the whole logic.
-
- 15 4月, 2016 1 次提交
-
-
由 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>
-
- 15 2月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Replace all occurrences of VMWare outside the news.
-
- 10 2月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
The virStringListLength function does not ever modify the passed string list. It merely counts the items in it. Make sure that we reflect this bit in the function header. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (crobinso: fix up spacing and squash in sheepdog bit suggested by Andrea)
-
- 06 1月, 2016 1 次提交
-
-
由 Wido den Hollander 提交于
If no port number was provided for a storage pool libvirt defaults to port 6789; however, librbd/librados already default to 6789 when no port number is provided. In the future Ceph will switch to a new port for the Ceph monitors since port 6789 is already assigned to a different application by IANA. Port 6789 is assigned to SMC-HTTPS and Ceph now has port 3300 assigned as the 'Ceph monitor' port. In this case it is the best solution to not hardcode any port number into libvirt and let librados handle the connection. Only if a user specifies a different port number we pass it down to librados, otherwise we leave it blank. Signed-off-by: NWido den Hollander <wido@widodh.nl> merge
-
- 07 8月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
Qemu reports physical size 0 for block devices. As 15fa84ac changed the behavior of qemuDomainGetBlockInfo to just query the monitor this created a regression since we didn't report the size correctly any more. This patch adds code to refresh the physical size of a block device by opening it and seeking to the end and uses it both in qemuDomainGetBlockInfo and also in qemuDomainGetStatsOneBlock that was broken since it was introduced in this respect. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250982
-
- 27 4月, 2015 1 次提交
-
-
由 zhang bo 提交于
snapshot and configFile are not freed, free them. Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>
-
- 22 4月, 2015 3 次提交
-
-
由 Peter Krempa 提交于
When a user would specify a backing chain index that is above the start point libvirt would report a rather unhelpful error: invalid argument: could not find backing store 1 in chain for 'sub/link2' This patch adds an explicit check that the index is below start point in the backing store and reports the following error if not: invalid argument: requested backing store index 1 is above 'sub/../qcow2' in chain for 'sub/link2' Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1177062
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Some storage protocols allow to have the @path field in struct virStorageSource set to NULL. Add NULLSTR() wrappers to handle this possibility until I finish the storage source error formatter.
-