1. 04 5月, 2018 1 次提交
  2. 12 4月, 2018 2 次提交
  3. 20 3月, 2018 3 次提交
  4. 19 3月, 2018 1 次提交
  5. 16 3月, 2018 4 次提交
  6. 23 2月, 2018 1 次提交
  7. 22 2月, 2018 1 次提交
  8. 16 10月, 2017 3 次提交
    • L
      hyperv: Map Limit to max_memory and VirtualQuantity to cur_balloon · a765e309
      Ladi Prosek 提交于
      Hyper-V uses its own specific memory management so no mapping is going to
      be perfect. However, it is more correct to map Limit to max_memory (it
      really is the upper limit of what the VM may potentially use) and keep
      cur_balloon equal to total_memory.
      
      The typical value returned from Hyper-V in Limit is 1 TiB, which is not
      really going to work if interpreted as "startup memory" to be ballooned
      away later.
      Signed-off-by: NLadi Prosek <lprosek@redhat.com>
      a765e309
    • L
      hyperv: Escape WQL queries · 5ae2d9c2
      Ladi Prosek 提交于
      The code was vulnerable to SQL injection. Likely not a security issue due to
      WMI SQL and other constraints but still lame. For example:
      
        virsh # dominfo \"
        error: failed to get domain '"'
        error: internal error: SOAP fault during enumeration: code 's:Sender', subcode
        'n:CannotProcessFilter', reason 'The data source could not process the filter.
        The filter might be missing or it might be invalid. Change the filter and try
        the request again.  ', detail 'The WS-Management service cannot process the
        request. The WQL query is invalid. '
      
      This commit fixes the Hyper-V driver by escaping all WMI SQL string parameters.
      
      The same command with the fix:
      
        virsh # dominfo \"
        error: failed to get domain '"'
        error: Domain not found: No domain with name "
      Signed-off-by: NLadi Prosek <lprosek@redhat.com>
      5ae2d9c2
    • L
      hyperv: Fix hypervInitConnection error reporting · bb8c2a76
      Ladi Prosek 提交于
      "%s is not a Hyper-V server" is not a correct generalization of all possible
      error conditions of hypervEnumAndPull. For example:
      
        $ virsh --connect hyperv://localhost/?transport=http
        Enter username for localhost [administrator]:
        Enter administrator's password for localhost: <enters incorrect password>
        error: failed to connect to the hypervisor
        error: internal error: localhost is not a Hyper-V server
      
      This commit removes the general virReportError from hypervInitConnection and
      also the "Invalid query" virReportError from hypervSerializeEprParam, which
      does not correctly describe the error either (virBufferCheckError has
      already set a meaningful error message at that point).
      
      The same scenario with the fix:
      
        $ virsh --connect hyperv://localhost/?transport=http
        Enter username for localhost [administrator]:
        Enter administrator's password for localhost: <enters incorrect password>
        error: failed to connect to the hypervisor
        error: internal error: Transport error during enumeration: User, password or
        similar was not accepted (26)
      Signed-off-by: NLadi Prosek <lprosek@redhat.com>
      bb8c2a76
  9. 19 9月, 2017 1 次提交
    • A
      python: Don't hardcode interpreter path · f34fdd5a
      Andrea Bolognani 提交于
      This is particularly useful on operating systems that don't ship
      Python as part of the base system (eg. FreeBSD) while still working
      just as well as it did before on Linux.
      
      While at it, make it explicit that our scripts are only going to
      work with Python 2, and remove the usage of unbuffered I/O, which
      as far as I can tell has no effect on the output files.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      f34fdd5a
  10. 08 8月, 2017 2 次提交
  11. 08 7月, 2017 5 次提交
    • S
      hyperv: Add support for virDomainSetMemory · 48c537f3
      Sri Ramanujam 提交于
      Introduces support for virDomainSetMemory. This also serves an an
      example for how to use the new method invocation API with a more
      complicated method, this time including an EPR and embedded param.
      48c537f3
    • S
      hyperv: support virDomainSendKey · 8efd5b64
      Sri Ramanujam 提交于
      This commit adds support for virDomainSendKey. It also serves as an
      example of how to use the new method invocation APIs with a single
      "simple" type parameter.
      8efd5b64
    • S
      hyperv: add hypervInvokeMethod · 8c28c76a
      Sri Ramanujam 提交于
      This commit adds support for invoking methods on remote objects
      via hypervInvokeMethod.
      8c28c76a
    • S
      hyperv: Generate object property type information · e4a2f5a2
      Sri Ramanujam 提交于
      Update the generator to generate basic property type information for
      each CIM object representation. Right now, it generates arrays of
      hypervCimType structs:
      
      struct _hypervCimType {
          const char *name;
          const char *type;
          bool isArray;
      };
      e4a2f5a2
    • S
      hyperv: Functions to work with invocation parameters · 638a5efd
      Sri Ramanujam 提交于
      This commit introduces functionality for creating and working with
      invoke parameters. This commit does not include any code for serializing
      and actually performing the method invocations; it merely defines the
      functions and API for using invocation parameters in driver code.
      
      HYPERV_DEFAULT_PARAM_COUNT was chosen because almost no method
      invocations have more than 4 parameters.
      
      Functions added:
      * hypervInitInvokeParamsList
      * hypervFreeInvokeParams
      * hypervAddSimpleParam
      * hypervAddEprParam
      * hypervCreateEmbeddedParam
      * hypervSetEmbeddedProperty
      * hypervAddEmbeddedParam
      * hypervFreeEmbeddedParam
      638a5efd
  12. 19 4月, 2017 1 次提交
    • D
      hyperv: recognize array property as distinct type. · bb9fca7b
      Dawid Zamirski 提交于
      When hyperv code generator for WMI classes identifies common
      properties, it needs to take into account array type as a distinct
      type, i.e string != string[]. This is the case where v1 of the
      Msvm_VirtualSystemSettingData has Notes property as string whereas v2
      uses Notes[], therefore they have to be treated as different fields and
      cannot be placed in the "common" struct.
      bb9fca7b
  13. 08 4月, 2017 4 次提交
    • D
      hyperv: add support for Hyper-V 2012 and newer · 3372f8fb
      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);
      }
      3372f8fb
    • D
      hyperv: update hypervObject struct. · 87f2bd3c
      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.
      87f2bd3c
    • D
      hyperv: introduce hypervWmiClassInfo struct. · a5689ad2
      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.
      a5689ad2
    • D
      hyperv: store WMI version in hypervPrivate. · a993f1b4
      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.
      a993f1b4
  14. 03 4月, 2017 1 次提交
    • M
      virGetDomain: Set domain ID too · 5683b213
      Michal Privoznik 提交于
      So far our code is full of the following pattern:
      
        dom = virGetDomain(conn, name, uuid)
        if (dom)
            dom->id = 42;
      
      There is no reasong why it couldn't be just:
      
        dom = virGetDomain(conn, name, uuid, id);
      
      After all, client domain representation consists of tuple (name,
      uuid, id).
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      5683b213
  15. 01 4月, 2017 1 次提交
  16. 15 9月, 2016 1 次提交
  17. 11 7月, 2016 1 次提交
    • P
      conf: Add private data for virDomainVcpuDef · 5fe0b6b0
      Peter Krempa 提交于
      Allow to store driver specific data on a per-vcpu basis.
      
      Move of the virDomainDef*Vcpus* functions was necessary as
      virDomainXMLOptionPtr was declared below this block and I didn't want to
      split the function headers.
      5fe0b6b0
  18. 08 6月, 2016 1 次提交
  19. 04 2月, 2016 1 次提交
  20. 09 12月, 2015 2 次提交
  21. 30 11月, 2015 1 次提交
    • M
      conf: Split virDomainObjList into a separate file · 90f3c0d7
      Michal Privoznik 提交于
      Our domain_conf.* files are big enough. Not only they contain XML
      parsing code, but they served as a storage of all functions whose
      name is virDomain prefixed. This is just wrong as it gathers not
      related functions (and modules) into one big file which is then
      harder to maintain. Split virDomainObjList module into a separate
      file called virdomainobjlist.[ch].
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      90f3c0d7
  22. 24 11月, 2015 1 次提交
  23. 22 9月, 2015 1 次提交