1. 23 3月, 2015 1 次提交
  2. 16 3月, 2015 1 次提交
    • P
      conf: Make specifying <memory> optional · 4bca6192
      Peter Krempa 提交于
      Now that the size of guest's memory can be inferred from the NUMA
      configuration (if present) make it optional to specify <memory>
      explicitly.
      
      To make sure that memory is specified add a check that some form of
      memory size was specified. One side effect of this change is that it is
      no longer possible to specify 0KiB as memory size for the VM, but I
      don't think it would be any useful to do so. (I can imagine embedded
      systems without memory, just registers, but that's far from what libvirt
      is usually doing).
      
      Forbidding 0 memory for guests also fixes a few corner cases where 0 was
      not interpreted correctly and caused failures. (Arguments for numad when
      using automatic placement, size of the balloon). This fixes problems
      described in https://bugzilla.redhat.com/show_bug.cgi?id=1161461
      
      Test case changes are added to verify that the schema change and code
      behave correctly.
      4bca6192
  3. 09 3月, 2015 1 次提交
  4. 06 3月, 2015 1 次提交
  5. 05 3月, 2015 1 次提交
  6. 03 3月, 2015 1 次提交
  7. 02 3月, 2015 2 次提交
  8. 26 2月, 2015 1 次提交
    • L
      qemu: fix ifindex array reported to systemd · 4bbe1029
      Laine Stump 提交于
      Commit f7afeddc added code to report to systemd an array of interface
      indexes for all tap devices used by a guest. Unfortunately it not only
      didn't add code to report the ifindexes for macvtap interfaces
      (interface type='direct') or the tap devices used by type='ethernet',
      it ended up sending "-1" as the ifindex for each macvtap or hostdev
      interface. This resulted in a failure to start any domain that had a
      macvtap or hostdev interface (or actually any type other than
      "network" or "bridge").
      
      This patch does the following with the nicindexes array:
      
      1) Modify qemuBuildInterfaceCommandLine() to only fill in the
      nicindexes array if given a non-NULL pointer to an array (and modifies
      the test jig calls to the function to send NULL). This is because
      there are tests in the test suite that have type='ethernet' and still
      have an ifname specified, but that device of course doesn't actually
      exist on the test system, so attempts to call virNetDevGetIndex() will
      fail.
      
      2) Even then, only add an entry to the nicindexes array for
      appropriate types, and to do so for all appropriate types ("network",
      "bridge", and "direct"), but only if the ifname is known (since that
      is required to call virNetDevGetIndex().
      4bbe1029
  9. 20 2月, 2015 1 次提交
    • M
      virQEMUCapsCacheLookupCopy: Filter qemuCaps based on machineType · af204232
      Michal Privoznik 提交于
      Not all machine types support all devices, device properties, backends,
      etc. So until we create a matrix of [machineType, qemuCaps], lets just
      filter out some capabilities before we return them to the consumer
      (which is going to make decisions based on them straight away).
      Currently, as qemu is unable to tell which capabilities are (not)
      enabled for given machine types, it's us who has to hardcode the matrix.
      One day maybe the hardcoding will go away and we can create the matrix
      dynamically on the fly based on a few monitor calls.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      af204232
  10. 17 2月, 2015 2 次提交
    • M
      qemuBuildMemoryBackendStr: Report backend requirement more appropriately · 7832fac8
      Michal Privoznik 提交于
      So, when building the '-numa' command line, the
      qemuBuildMemoryBackendStr() function does quite a lot of checks to
      chose the best backend, or to check if one is in fact needed. However,
      it returned that backend is needed even for this little fella:
      
        <numatune>
          <memory mode="strict" nodeset="0,2"/>
        </numatune>
      
      This can be guaranteed via CGroups entirely, there's no need to use
      memory-backend-ram to let qemu know where to get memory from. Well, as
      long as there's no <memnode/> element, which explicitly requires the
      backend. Long story short, we wouldn't have to care, as qemu works
      either way. However, the problem is migration (as always). Previously,
      libvirt would have started qemu with:
      
        -numa node,memory=X
      
      in this case and restricted memory placement in CGroups. Today, libvirt
      creates more complicated command line:
      
        -object memory-backend-ram,id=ram-node0,size=X
        -numa node,memdev=ram-node0
      
      Again, one wouldn't find anything wrong with these two approaches.
      Both work just fine. Unless you try to migrated from the older libvirt
      into the newer one. These two approaches are, unfortunately, not
      compatible. My suggestion is, in order to allow users to migrate, lets
      use the older approach for as long as the newer one is not needed.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      7832fac8
    • M
      qemuxml2argvtest: Fake response from numad · 38064806
      Michal Privoznik 提交于
      Well, we can pretend that we've asked numad for its suggestion and let
      qemu command line be built with that respect. Again, this alone has no
      big value, but see later commits which build on the top of this.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      38064806
  11. 12 2月, 2015 1 次提交
  12. 11 2月, 2015 1 次提交
  13. 10 2月, 2015 1 次提交
  14. 03 2月, 2015 1 次提交
  15. 27 1月, 2015 2 次提交
    • D
      qemu: report TAP device indexes to systemd · f7afeddc
      Daniel P. Berrange 提交于
      Record the index of each TAP device created and report them to
      systemd, so they show up in machinectl status for the VM.
      f7afeddc
    • D
      Removing probing of secondary drivers · 55ea7be7
      Daniel P. Berrange 提交于
      For stateless, client side drivers, it is never correct to
      probe for secondary drivers. It is only ever appropriate to
      use the secondary driver that is associated with the
      hypervisor in question. As a result the ESX & HyperV drivers
      have both been forced to do hacks where they register no-op
      drivers for the ones they don't implement.
      
      For stateful, server side drivers, we always just want to
      use the same built-in shared driver. The exception is
      virtualbox which is really a stateless driver and so wants
      to use its own server side secondary drivers. To deal with
      this virtualbox has to be built as 3 separate loadable
      modules to allow registration to work in the right order.
      
      This can all be simplified by introducing a new struct
      recording the precise set of secondary drivers each
      hypervisor driver wants
      
      struct _virConnectDriver {
          virHypervisorDriverPtr hypervisorDriver;
          virInterfaceDriverPtr interfaceDriver;
          virNetworkDriverPtr networkDriver;
          virNodeDeviceDriverPtr nodeDeviceDriver;
          virNWFilterDriverPtr nwfilterDriver;
          virSecretDriverPtr secretDriver;
          virStorageDriverPtr storageDriver;
      };
      
      Instead of registering the hypervisor driver, we now
      just register a virConnectDriver instead. This allows
      us to remove all probing of secondary drivers. Once we
      have chosen the primary driver, we immediately know the
      correct secondary drivers to use.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      55ea7be7
  16. 16 1月, 2015 2 次提交
  17. 14 1月, 2015 1 次提交
    • D
      Give virDomainDef parser & formatter their own flags · 0ecd6851
      Daniel P. Berrange 提交于
      The virDomainDefParse* and virDomainDefFormat* methods both
      accept the VIR_DOMAIN_XML_* flags defined in the public API,
      along with a set of other VIR_DOMAIN_XML_INTERNAL_* flags
      defined in domain_conf.c.
      
      This is seriously confusing & error prone for a number of
      reasons:
      
       - VIR_DOMAIN_XML_SECURE, VIR_DOMAIN_XML_MIGRATABLE and
         VIR_DOMAIN_XML_UPDATE_CPU are only relevant for the
         formatting operation
       - Some of the VIR_DOMAIN_XML_INTERNAL_* flags only apply
         to parse or to format, but not both.
      
      This patch cleanly separates out the flags. There are two
      distint VIR_DOMAIN_DEF_PARSE_* and VIR_DOMAIN_DEF_FORMAT_*
      flags that are used by the corresponding methods. The
      VIR_DOMAIN_XML_* flags received via public API calls must
      be converted to the VIR_DOMAIN_DEF_FORMAT_* flags where
      needed.
      
      The various calls to virDomainDefParse which hardcoded the
      use of the VIR_DOMAIN_XML_INACTIVE flag change to use the
      VIR_DOMAIN_DEF_PARSE_INACTIVE flag.
      0ecd6851
  18. 13 1月, 2015 1 次提交
  19. 15 12月, 2014 1 次提交
    • M
      qemu: Allow system pages to <memoryBacking/> · 311b4a67
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1173507
      
      It occurred to me that OpenStack uses the following XML when not using
      regular huge pages:
      
        <memoryBacking>
          <hugepages>
            <page size='4' unit='KiB'/>
          </hugepages>
        </memoryBacking>
      
      However, since we are expecting to see huge pages only, we fail to
      startup the domain with following error:
      
        libvirtError: internal error: Unable to find any usable hugetlbfs
        mount for 4 KiB
      
      While regular system pages are not huge pages technically, our code is
      prepared for that and if it helps OpenStack (or other management
      applications) we should cope with that.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      311b4a67
  20. 11 12月, 2014 1 次提交
  21. 25 11月, 2014 2 次提交
  22. 21 11月, 2014 1 次提交
  23. 15 11月, 2014 1 次提交
  24. 12 11月, 2014 1 次提交
    • M
      qemuxml2argvtest: Run some test only on Linux · 8d659b17
      Michal Privoznik 提交于
      As I was reviewing bhyve commits, I've noticed qemuxml2argvtest
      failing for some test cases. This is not bug in qemu driver code
      rather than being unable to load qemuxml2argvmock on non-Linux
      platforms. For instance:
      
      318) QEMU XML-2-ARGV numatune-memnode
      ... libvirt:  error : internal error: NUMA node 0 is unavailable
      FAILED
      
      Rather than disabling qemuxml2argvtest on BSD (we do compile qemu
      driver there) disable only those test cases which require mocking.
      To achieve that goal new DO_TEST_LINUX() macro is introduced which
      invokes the test case on Linux only and consume arguments on other
      systems.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      8d659b17
  25. 07 11月, 2014 1 次提交
  26. 06 11月, 2014 1 次提交
  27. 04 11月, 2014 1 次提交
  28. 03 11月, 2014 1 次提交
  29. 20 10月, 2014 1 次提交
    • M
      tests: fix incorrect caps for shmem-invalid-size, shmem-small-size · e80be99f
      Maxime Leroy 提交于
      VIR_TEST_DEBUG=2 ./qemuxml2argvtest generates the following output:
      
      409) QEMU XML-2-ARGV shmem-invalid-size
      ... Got expected error: unsupported configuration: ivshmem device is not \
      	 supported with this QEMU binary
      OK
      410) QEMU XML-2-ARGV shmem-small-size
      ... Got expected error: unsupported configuration: ivshmem device is not \
      supported with this QEMU binary
      OK
      
      We should have:
      
      409) QEMU XML-2-ARGV shmem-invalid-size
      ... Got expected error: XML error: shmem size must be a power of two
      OK
      410) QEMU XML-2-ARGV shmem-small-size
      ... Got expected error: XML error: shmem size must be at least 1 MiB
      OK
      
      This commit fixes the issue by providing QEMU_CAPS_DEVICE_IVSHMEM caps
      for shmem-invalid-size, shmem-small-size test.
      Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>
      e80be99f
  30. 04 10月, 2014 2 次提交
  31. 03 10月, 2014 1 次提交
    • C
      qemu: Don't compare CPU against host for TCG · 445a09bd
      Cole Robinson 提交于
      Right now when building the qemu command line, we try to do various
      unconditional validations of the guest CPU against the host CPU. However
      this checks are overly applied. The only time we should use the checks
      are:
      
      - The user requests host-model/host-passthrough, or
      
      - When KVM is requsted. CPU features requested in TCG mode are always
        emulated by qemu and are independent of the host CPU, so no host CPU
        checks should be performed.
      
      Right now if trying to specify a CPU for arm on an x86 host, it attempts
      to do non-sensical validation and falls over.
      
      Switch all the test cases that were intending to test CPU validation to
      use KVM, so they continue to test the intended code.
      
      Amend some aarch64 XML tests with a CPU model, to ensure things work
      correctly.
      445a09bd
  32. 26 9月, 2014 1 次提交
  33. 24 9月, 2014 1 次提交
  34. 19 9月, 2014 1 次提交