1. 05 10月, 2017 9 次提交
  2. 04 10月, 2017 12 次提交
  3. 03 10月, 2017 2 次提交
  4. 02 10月, 2017 3 次提交
  5. 29 9月, 2017 1 次提交
  6. 28 9月, 2017 7 次提交
    • A
      qemu: Add TLS support for Veritas HyperScale (VxHS) · 6885b51e
      Ashish Mittal 提交于
      Alter qemu command line generation in order to possibly add TLS for
      a suitably configured domain.
      
      Sample TLS args generated by libvirt -
      
          -object tls-creds-x509,id=objvirtio-disk0_tls0,dir=/etc/pki/qemu,\
          endpoint=client,verify-peer=yes \
          -drive file.driver=vxhs,file.tls-creds=objvirtio-disk0_tls0,\
          file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,\
          file.server.type=tcp,file.server.host=192.168.0.1,\
          file.server.port=9999,format=raw,if=none,\
          id=drive-virtio-disk0,cache=none \
          -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,\
          id=virtio-disk0
      
      Update the qemuxml2argvtest with a couple of examples. One for a
      simple case and the other a bit more complex where multiple VxHS disks
      are added where at least one uses a VxHS that doesn't require TLS
      credentials and thus sets the domain disk source attribute "tls = 'no'".
      
      Update the hotplug to be able to handle processing the tlsAlias whether
      it's to add the TLS object when hotplugging a disk or to remove the TLS
      object when hot unplugging a disk.  The hot plug/unplug code is largely
      generic, but the addition code does make the VXHS specific checks only
      because it needs to grab the correct config directory and generate the
      object as the command line would do.
      Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      6885b51e
    • J
      qemu: Introduce qemuDomainPrepareDiskSource · 5c09486c
      John Ferlan 提交于
      Introduce a function to setup any TLS needs for a disk source.
      
      If there's a configuration or other error setting up the disk source
      for TLS, then cause the domain startup to fail.
      
      For VxHS, follow the chardevTLS model where if the src->haveTLS hasn't
      been configured, then take the system/global cfg->haveTLS setting for
      the storage source *and* mark that we've done so via the tlsFromConfig
      setting in storage source.
      
      Next, if we are using TLS, then generate an alias into a virStorageSource
      'tlsAlias' field that will be used to create the TLS object and added to
      the disk object in order to link the two together for QEMU.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      5c09486c
    • A
      util: Add TLS attributes to virStorageSource · f1705485
      Ashish Mittal 提交于
      Add an optional virTristateBool haveTLS to virStorageSource to
      manage whether a storage source will be using TLS.
      
      Sample XML for a VxHS disk:
      
      <disk type='network' device='disk'>
        <driver name='qemu' type='raw' cache='none'/>
        <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251' tls='yes'>
          <host name='192.168.0.1' port='9999'/>
        </source>
        <target dev='vda' bus='virtio'/>
      </disk>
      
      Additionally add a tlsFromConfig boolean to control whether the TLS
      setting was due to domain configuration or qemu.conf global setting
      in order to decide whether to Format the haveTLS setting for either
      a live or saved domain configuration file.
      
      Update the qemuxml2xmltest in order to add a test to show the proper
      parsing.
      
      Also update the docs to describe the tls attribute.
      Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      f1705485
    • J
      docs: Clean up the description for network disk protocol options · 70ad3052
      John Ferlan 提交于
      Clean up the description a bit to make it more readable and not
      appear as one long run-on paragraph.
      70ad3052
    • A
      conf: Introduce TLS options for VxHS block device clients · bd6fdcd8
      Ashish Mittal 提交于
      Add a new TLS X.509 certificate type - "vxhs". This will handle the
      creation of a TLS certificate capability for properly configured
      VxHS network block device clients.
      
      The following describes the behavior of TLS for VxHS block device:
      
        (1) Two new options have been added in /etc/libvirt/qemu.conf
            to control TLS behavior with VxHS block devices
            "vxhs_tls" and "vxhs_tls_x509_cert_dir".
        (2) Setting "vxhs_tls=1" in /etc/libvirt/qemu.conf will enable
            TLS for VxHS block devices.
        (3) "vxhs_tls_x509_cert_dir" can be set to the full path where the
            TLS CA certificate and the client certificate and keys are saved.
            If this value is missing, the "default_tls_x509_cert_dir" will be
            used instead. If the environment is not configured properly the
            authentication to the VxHS server will fail.
      Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      bd6fdcd8
    • J
      nwfilter: Fix possible segfault on sometimes consumed variable · 6209bb32
      John Ferlan 提交于
      The virNWFilterIPAddrMapAddIPAddr code can consume the @addr parameter
      on success when the @ifname is found in the ipAddressMap->hashTable
      hash table in the call to virNWFilterVarValueAddValue; however, if
      not found in the hash table, then @addr is formatted into a @val
      which is stored in the table and on return the caller would be
      expected to free @addr.
      
      Thus, the caller has no way to determine on success whether @addr was
      consumed, so in order to fix this create a @tmp variable which will
      be stored/consumed when virNWFilterVarValueAddValue succeeds. That way
      the caller can free @addr whether the function returns success or failure.
      6209bb32
    • P
      rpc: for messages with FDs always decode count of FDs from the message · 5c52aed1
      Pavel Hrdina 提交于
      The packet with passed FD has the following format:
      
          --------------------------
          | len | header | payload |
          --------------------------
      
      where "payload" has an additional count of FDs before the actual data:
      
          ------------------
          | nfds | payload |
          ------------------
      
      When the packet is received we parse the "header", which as a side
      effect updates msg->bufferOffset to point to the beginning of "payload".
      If the message call contains FDs, we need to also parse the count of
      FDs, which also updates the msg->bufferOffset.
      
      The issue here is that when we attempt to read the FDs data from the
      socket and we receive EAGAIN we finish the reading and call poll()
      to wait for the data the we need.  When the data arrives we already have
      the packet in our buffer so we read the "header" again but this time
      we don't read the count of FDs because we already have it stored.
      
      That means that the msg->bufferOffset is not updated to point to the
      actual beginning of the payload data, but it points to the count of
      FDs.  After all FDs are processed we dispatch the message to process
      it and decode the payload.  Since the msg->bufferOffset points to wrong
      data, we decode the wrong payload and the API call fails with
      error messages:
      
          Domain not found: no domain with matching uuid '67656e65-7269-6300-0c87-5003ca6941f2' ()
      
      Broken by commit 133c511b which fixed a FD and memory leak.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      5c52aed1
  7. 27 9月, 2017 6 次提交
    • P
      qemu: domain: Extract common clearing of VM private data · 3685e2dd
      Peter Krempa 提交于
      VM private data is cleared when the VM is turned off and also when the
      VM object is being freed. Some of the clearing code was duplicated.
      Extract it to a separate function.
      
      This also removes the now unnecessary function
      qemuDomainClearPrivatePaths.
      3685e2dd
    • E
      f54f3274
    • J
      Shrink volume even with ALLOCATE flag · 959fe7de
      Ján Tomko 提交于
      Calling fallocate on the new (smaller) capacity ensures
      that the whole file is allocated, but it does not reduce
      the file size.
      
      Also call ftruncate after fallocate.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1366446
      959fe7de
    • J
      virStorageFileResize: fallocate the whole capacity · 3f702f5a
      Ján Tomko 提交于
      We have been trying to implement the ALLOCATE flag to mean
      "the volume should be fully allocated after the resize".
      
      Since commit b0579ed9 we do not allocate from the existing
      capacity, but from the existing allocation value.
      However this value is a total of all the allocated bytes,
      not an offset.
      
      For a sparsely allocated file:
      $ perl -e 'print "x"x8192;' > vol1
      $ fallocate -p -o 0 -l 4096 vol1
      $ virsh vol-info vol1 default
      Capacity:       8.00 KiB
      Allocation:     4.00 KiB
      
      Treating allocation as an offset would result in an incompletely
      allocated file:
      $ virsh vol-resize vol1 --pool default 16384 --allocate
      Capacity:       16.00 KiB
      Allocation:     12.00 KiB
      
      Call fallocate from zero on the whole requested capacity to fully
      allocate the file. After that, the volume is fully allocated
      after the resize:
      $ virsh vol-resize vol1 --pool default 16384 --allocate
      $ virsh vol-info vol1 default
      Capacity:       16.00 KiB
      Allocation:     16.00 KiB
      3f702f5a
    • J
      use virFileAllocate in virStorageFileResize · 5463d959
      Ján Tomko 提交于
      Introduce a new function virFileAllocate that will call the
      non-destructive variants of safezero, essentially reverting
      my commit 1390c268
          safezero: fall back to writing zeroes even when resizing
      back to the state as of commit 18f03166
          virstoragefile: Have virStorageFileResize use safezero
      
      This means that _ALLOCATE flag will no longer work on platforms
      without the allocate syscalls, but it will not overwrite data
      either.
      5463d959
    • J
      virsh: Add/allow secret-uuid for pool-{define|create}-as · 63d3d895
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1476775
      
      For the virsh pool-{define|create}-as command, let's allow using
      --secret-uuid on the command line as an alternative to --secret-usage
      (added for commit id '89325806'), but ensure that they are mutually
       exclusive.
      63d3d895