- 08 4月, 2017 5 次提交
-
-
由 Dawid Zamirski 提交于
-
由 Dawid Zamirski 提交于
This patch reworks the Hyper-V driver structs and the code generator to provide seamless support for both Hyper-V 2008 and 2012 or newer. This does not implement any new libvirt APIs, it just adapts existing 2008-only driver to also handle 2012 and newer by sharing as much driver code as possible (currently it's all of it :-)). This is needed to set the foundation before we can move forward with implementing the rest of the driver APIs. With the 2012 release, Microsoft introduced "v2" version of Msvm_* WMI classes. Those are largely the same as "v1" (used in 2008) but have some new properties as well as need different wsman request URIs. To accomodate those differences, most of work went into the code generator so that it's "aware" of possibility of multiple versions of the same WMI class and produce C code accordingly. To accomplish this the following changes were made: * the abstract hypervObject struct's data member was changed to a union that has "common", "v1" and "v2" members. Those are structs that represent WMI classes that we get back from wsman response. The "common" struct has members that are present in both "v1" and "v2" which the driver API callbacks can use to read the data from in version-independent manner (if version-specific member needs to be accessed the driver can check priv->wmiVersion and read from "v1" or "v2" as needed). Those structs are guaranteed to be memory aligned by the code generator (see the align_property_members implementation that takes care of that) * the generator produces *_WmiInfo for each WMI class "family" that holds an array of hypervWmiClassInfoPtr each providing information as to which request URI to use for each "version" of given WMI class as well as XmlSerializerInfo struct needed to unserilize WS-MAN responsed into the data structs. The driver uses those to make proper WS-MAN request depending on which version it's connected to. * the generator no longer produces "helper" functions such as hypervGetMsvmComputerSystemList as those were originally just simple wrappers around hypervEnumAndPull, instead those were hand-written now (to keep driver changes minimal). The reason is that we'll have more code coming implementing missing libvirt APIs and surely code patterns will emerge that would warrant more useful "utility" functions like that. * a hypervInitConnection was added to the driver which "detects" Hyper-V version by testing simple wsman request using v2 then falling back to v1, obviously if both fail, the we're erroring out. To express how the above translates in code: void hypervImplementSomeLibvirtApi(virConnectPtr conn, ...) { hypervPrivate *priv = conn->privateData; virBuffer query = VIR_BUFFER_INITIALIZER; hypervWqlQuery wqlQuery = HYPERV_WQL_QUERY_INITIALIZER; Msvm_ComputerSystem *list = NULL; /* typed hypervObject instance */ /* the WmiInfo struct has the data needed for wsman request and * response handling for both v1 and v2 */ wqlQuery.info = Msvm_ComputerSystem_WmiInfo; wqlQuery.query = &query; virBufferAddLit(&query, "select * from Msvm_ComputerSystem"); if (hypervEnumAndPull(priv, &wqlQuery, (hypervObject **) &list) < 0) { goto cleanup; } if (list == NULL) { /* none found */ goto cleanup; } /* works with v1 and v2 */ char *vmName = list->data.common->Name; /* access property that is in v2 only */ if (priv->wmiVersion == HYPERV_WMI_VERSION_V2) char *foo = list->data.v2->V2Property; else char *foo = list->data.v1->V1Property; cleanup: hypervFreeObject(priv, (hypervObject *)list); }
-
由 Dawid Zamirski 提交于
Currently named as hypervObjecUnified to keep code compilable/functional until all bits are in place. This struct is a result of unserializing WMI request response. Therefore, it needs to be able to deal with different "versions" of the same WMI class. To accomplish this, the "data" member was turned in to a union which: * has a "common" member that contains only WMI class fields that are safe to access and are present in all "versions". This is ensured by the code generator that takes care of proper struct memory alignment between "common", "v1", "v2" etc members. This memeber is to be used by the driver code wherever the API implementation can be shared for all supported hyper-v versions. * the "v1" and "v2" member can be used by the driver code to handle version specific cases. Example: Msvm_ComputerSystem *vm = NULL; ... hypervGetVirtualMachineList(priv, wqlQuery, *vm); ... /* safe for "v1" and "v2" */ char *vmName = vm->data.common->Name; /* or if one really needs special handling for "v2" */ if (priv->wmiVersion == HYPERV_WMI_VERSION_V2) { char *foo = vm->data.v2->SomeV2OnlyField; } In other words, driver should not concern itself with existence of "v1" or "v2" of WMI class unless absolutely necessary.
-
由 Dawid Zamirski 提交于
This struct is to be used to carry all the information necessary to issue wsman requests for given WMI class. Those will be defined by the generator code (as lists) so that they are handy for the driver code to "extract" needed info depending on which hyper-v we're connected to. For example: hypervWmiClassInfoListPtr Msvm_ComputerSystem_WmiInfo = { .count = 2 { { .name = "Msvm_ComputerSystem", .version = "v1", .rootUri = "http://asdf.com", ... }, { .name = "Msvm_ComputerSystem", .version = "v2", .rootUri = "http://asdf.com/v2", ... }, } }; Then the driver code will grab either "v1" or "v2" to pass info wsman API, depending on hypervPrivate->wmiVersion value.
-
由 Dawid Zamirski 提交于
Hyper-V 2012+ uses a new "v2" version of Msvm_* WMI classes so we will store that info in hypervPrivate so that it is easily accessbile in the driver API callbacks and handled accordingly.
-
- 07 4月, 2017 29 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1439132 Add "bsd" to the list of format types to not checked during blkid processing even though it supposedly knows the format - for some (now unknown) reason it's returning partition table not found. So let's just let PARTED handle "bsd" too. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1439132 Commit id 'a48c674f' added a check for format types "dvh" and "pc98" to use the parted print processing instead of using blkid processing in order to validate the label on the disk was what is expected for disk pool startup. However, commit id 'a4cb4a74' really messed things up by missing an else condition causing PARTEDFindLabel to always return DIFFERENT. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1439130Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
So far only QEMU_MONITOR_MIGRATION_CAPS_POSTCOPY was reset, but only in a single code path leaving post-copy enabled in quite a few cases. https://bugzilla.redhat.com/show_bug.cgi?id=1425003Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
It's only called from qemuMigrationReset now so it doesn't need to be exported and {tls,sec}Alias are always NULL. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This new API is supposed to reset all migration parameters to make sure future migrations won't accidentally use them. This patch makes the first step and moves qemuMigrationResetTLS call inside qemuMigrationReset. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Migration parameters are either reset by the main migration code path or from qemuProcessRecoverMigration* in case libvirtd is restarted during migration. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Finished qemuMigrationRun does not mean the migration itself finished (it might have just switched to post-copy mode). While resetting TLS parameters is probably OK at this point even if migration is still running, we want to consolidate the code which resets various migration parameters. Thus qemuMigrationResetTLS will be called from the Confirm phase (or at the end of the Perform phase in case of v2 protocol), when migration is either canceled or finished. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessRecoverMigrationOut doesn't explicitly call qemuMigrationResetTLS relying on two things: - qemuMigrationCancel resets TLS parameters - our migration code resets TLS before entering QEMU_MIGRATION_PHASE_PERFORM3_DONE phase But this is not obvious and the assumptions will be broken soon. Let's explicitly reset TLS parameters on all paths which do not kill the domain. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Let's use a bool variable to create a single shared path returning 0. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
There is no async job running when a freshly started libvirtd is trying to recover from an interrupted incoming migration. While at it, let's call qemuMigrationResetTLS every time we don't kill the domain. This is not strictly necessary since TLS is not supported when v2 migration protocol is used, but doing so makes more sense. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This reverts commit 68507d77 which was pushed accidentally.
-
由 Jiri Denemark 提交于
This reverts commit dfc711dc which was pushed accidentally.
-
由 Jiri Denemark 提交于
This reverts commit 959e72d3 which was pushed accidentally.
-
由 Jiri Denemark 提交于
This reverts commit 5f96b3fe which was pushed accidentally.
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Because of the changes done in the previous commit, @host is already a migratable CPU and there's no need to do any additional filtering. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We will need to store two more host CPU models and nested structs look better than separate items with long complicated names. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This new internal API makes a copy of virCPUDef while removing all features which would block migration. It uses cpu_map.xml as a database of such features, which should only be used as a fallback when we cannot get the data from a hypervisor. The main goal of this API is to decouple this filtering from virCPUUpdate so that the hypervisor driver can filter the features according to the hypervisor. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We want to ignore all files except *.pl in build-aux directory, however the unignore pattern "!/build-aux/*.pl" doesn't have any effect because a previous "/build-aux/" pattern ignores the directory itself rather than individual files in it. https://bugzilla.redhat.com/show_bug.cgi?id=1439994Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Martin Kletzander 提交于
And use it in virFileRead* Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
If formatting NUMA topology fails, the function returns immediatelly, but the buffer structure allocated on the stack references lot of heap-allocated memory and that would get lost in such case. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 06 4月, 2017 5 次提交
-
-
由 Jiri Denemark 提交于
qemuProcessVerifyHypervFeatures is supposed to check whether all requested hyperv features were actually honored by QEMU/KVM. This is done by checking the corresponding CPUID bits reported by the virtual CPU. In other words, it doesn't work for string properties, such as VIR_DOMAIN_HYPERV_VENDOR_ID (there is no CPUID bit we could check). We could theoretically check all 96 bits corresponding to the vendor string, but luckily we don't have to check the feature at all. If QEMU is too old to support hyperv features, the domain won't even start. Otherwise, it is always supported. Without this patch, libvirt refuses to start a domain which contains <features> <hyperv> <vendor_id state='on' value='...'/> </hyperv> </features> reporting internal error: "unknown CPU feature __kvm_hv_vendor_id. This regression was introduced by commit v3.1.0-186-ge9dbe701, which (by fixing the virCPUDataCheckFeature condition in qemuProcessVerifyHypervFeatures) revealed an old bug in the feature verification code. It's been there ever since the verification was implemented by commit v1.3.3-rc1-5-g95bbe4bf, which effectively did not check VIR_DOMAIN_HYPERV_VENDOR_ID at all. https://bugzilla.redhat.com/show_bug.cgi?id=1439424Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Ján Tomko 提交于
Introduce STRICT_FRAME_LIMIT_CFLAGS that will be used for production code and RELAXED_FRAME_LIMIT_CFLAGS for tests. Raising the limit for tests allows building them with clang with optimizations disabled.
-
由 Andrea Bolognani 提交于
This header file has been created so that we can expose internal functions to the test suite without making them public: those in qemu_capabilities.h bearing the comment /* Only for use by test suite */ are obvious candidates for being moved over.
-
由 Andrea Bolognani 提交于
The contents of volname would be leaked if the function were to be passed an invalid pooltype by the caller. Make sure the memory is released instead.
-
由 Boris Fiuczynski 提交于
Fixing make syntax-check broken by commit 4da534c0. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
- 05 4月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
This function runs an iscsi command and parses its output. However, due to the nature of things, virISCSIExtractSession() callback can be called multiple times. In each run it would allocate new memory and overwrite the variable where we keep pointer to it and thus leaking old allocations. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-