Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 19 12月, 2019 1 次提交
    • D
      Introducing new address type='unassigned' for PCI hostdevs · 96999404
      由 Daniel Henrique Barboza 提交于 
      This patch introduces a new PCI hostdev address type called
'unassigned'. This new type gives users the option to add
PCI hostdevs to the domain XML in an 'unassigned' state, meaning
that the device exists in the domain, is managed by Libvirt
like any regular PCI hostdev, but the guest does not have
access to it.

This adds extra options for managing PCI device binding
inside Libvirt, for example, making all the managed PCI hostdevs
declared in the domain XML to be detached from the host and bind
to the chosen driver and, at the same time, allowing just a
subset of these devices to be usable by the guest.

Next patch will use this new address type in the QEMU driver to
avoid adding unassigned devices to the QEMU launch command line.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      96999404
  3. 17 12月, 2019 1 次提交
    • M
      schemas: Introduce disk type NVMe · e1b02289
      由 Michal Privoznik 提交于 
      There is this class of PCI devices that act like disks: NVMe.
Therefore, they are both PCI devices and disks. While we already
have <hostdev/> (and can assign a NVMe device to a domain
successfully) we don't have disk representation. There are three
problems with PCI assignment in case of a NVMe device:

1) domains with <hostdev/> can't be migrated

2) NVMe device is assigned whole, there's no way to assign only a
   namespace

3) Because hypervisors see <hostdev/> they don't put block layer
   on top of it - users don't get all the fancy features like
   snapshots

NVMe namespaces are way of splitting one continuous NVDIMM memory
into smaller ones, effectively creating smaller NVMe-s (which can
then be partitioned, LVMed, etc.)

Because of all of this the following XML was chosen to model a
NVMe device:

  <disk type='nvme' device='disk'>
    <driver name='qemu' type='raw'/>
    <source type='pci' managed='yes' namespace='1'>
      <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </source>
    <target dev='vda' bus='virtio'/>
  </disk>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>
      e1b02289
  5. 13 12月, 2019 2 次提交
    • H
      conf: create memory bandwidth monitor. · 40a070ae
      由 Huaqiang 提交于 
      Following domain configuration changes create two memory bandwidth
monitors: one is monitoring the bandwidth consumed by vCPU 0,
another is for vCPU 5.

```
               <cputune>
                 <memorytune vcpus='0-4'>
                   <node id='0' bandwidth='20'/>
                   <node id='1' bandwidth='30'/>
       +           <monitor vcpus='0'/>
                 </memorytune>
       +         <memorytune vcpus='5'>
       +           <monitor vcpus='5'/>
       +         </memorytune>

               </cputune>
    ```
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NHuaqiang <huaqiang.wang@intel.com>
      40a070ae
    • H
      cachetune schema: a looser check for the order of <cache> and <monitor> element · 1d0c3c3a
      由 Huaqiang 提交于 
      Originally, inside <cputune/cachetune>, it requires the <cache> element to
be in the position before <monitor>, and following configuration is not
permitted by schema, but it is better to let it be valid.

  <cputune>
    <cachetune vcpus='0-1'>
      <monitor level='3' vcpus='0-1'/>
            ^
            |__ Not permitted originally because it is in the place
                before <cache> element.

      <cache id='0' level='3' type='both' size='3' unit='MiB'/>
      <cache id='1' level='3' type='both' size='3' unit='MiB'/>
    </cachetune>
    ...
  </cputune>

And, let schema do more strict check by identifying following configuration to
be invalid, due to <cachetune> should contain at least one <cache> or <monitor>
element.

  <cputune>
    <cachetune vcpus='0-1'>
        ^
        |__ a <cachetune> SHOULD contain at least one <cache> or <monitor>

    </cachetune>
    ...
  </cputune>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NHuaqiang <huaqiang.wang@intel.com>
      1d0c3c3a
  7. 04 12月, 2019 2 次提交
  9. 15 11月, 2019 1 次提交
  11. 18 10月, 2019 1 次提交
    • J
      conf: Add 'x' and 'y' resolution into video XML definition · 72862797
      由 Julio Faracco 提交于 
      This commit adds resolution element with parameters 'x' and 'y' into video
XML domain group definition. Both, properties were added into an element
called 'resolution' and it was added inside 'model' element. They are set
as optional. This element does not follow QEMU properties 'xres' and
'yres' format. Both HTML documentation and schema were changed too. This
commit includes a simple test case to cover resolution for QEMU video
models. The new XML format for resolution looks like:

    <model ...>
      <resolution x='800' y='600'/>
    </model>
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
      72862797
  13. 10 10月, 2019 2 次提交
  15. 25 9月, 2019 2 次提交
  17. 10 9月, 2019 1 次提交
    • L
      conf: new "managed" attribute for target dev of <interface type='ethernet'> · 77f72a86
      由 Laine Stump 提交于 
      Although <interface type='ethernet'> has always been able to use an
existing tap device, this is just a coincidence due to the fact that
the same ioctl is used to create a new tap device or get a handle to
an existing device.

Even then, once we have the handle to the device, we still insist on
doing extra setup to it (setting the MAC address and IFF_UP).  That
*might* be okay if libvirtd is running as a privileged process, but if
libvirtd is running as an unprivileged user, those attempted
modifications to the tap device will fail (yes, even if the tap is set
to be owned by the user running libvirtd). We could avoid this if we
knew that the device already existed, but as stated above, an existing
device and new device are both accessed in the same manner, and
anyway, we need to preserve existing behavior for those who are
already using pre-existing devices with privileged libvirtd (and
allowing/expecting libvirt to configure the pre-existing device).

In order to cleanly support the idea of using a pre-existing and
pre-configured tap device, this patch introduces a new optional
attribute "managed" for the interface <target> element. This
attribute is only valid for <interface type='ethernet'> (since all
other interface types have mandatory config that doesn't apply in the
case where we expect the tap device to be setup before we
get it). The syntax would look something like this:

   <interface type='ethernet'>
      <target dev='mytap0' managed='no'/>
      ...
   </interface>

This patch just adds managed to the grammar and parser for <target>,
but has no functionality behind it.

(NB: when managed='no' (the default when not specified is 'yes'), the
target dev is always a name explicitly provided, so we don't
auto-remove it from the config just because it starts with "vnet"
(VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the
same pattern of names that libvirt itself uses when it automatically
creates the tap devices.)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      77f72a86
  19. 19 8月, 2019 1 次提交
  21. 12 8月, 2019 1 次提交
  23. 26 7月, 2019 1 次提交
  25. 15 7月, 2019 1 次提交
  27. 21 6月, 2019 1 次提交
  29. 20 6月, 2019 1 次提交
  31. 17 6月, 2019 1 次提交
  33. 03 6月, 2019 1 次提交
  35. 16 4月, 2019 1 次提交
  37. 03 4月, 2019 1 次提交
    • P
      conf: Parse and format 'backingStore' for disk <mirror> · 4e797f1a
      由 Peter Krempa 提交于 
      When the block copy operation is started with a reused external file in
incremental mode libvirt will need to open and insert the backing chain
for that file into qemu (in -blockdev mode). This means that we'll need
to track the backing chain and metadata such as node names for the full
chain of <mirror>.

This patch invokes the full backing chain formatter and parser for
<mirror> so that the chain can be kept with <mirror>.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      4e797f1a
  39. 14 3月, 2019 1 次提交
    • J
      conf: Add a new 'xenbus' controller type · 09eb1ae0
      由 Jim Fehlig 提交于 
      xenbus is virtual controller (akin to virtio controllers) for Xen
paravirtual devices. Although all Xen VMs have a xenbus, it has
never been modeled in libvirt, or in Xen native VM config format
for that matter.

Recently there have been requests to support Xen's max_grant_frames
setting in libvirt. max_grant_frames is best modeled as an attribute
of xenbus. It describes the maximum IO buffer space (or DMA space)
available in xenbus for use by connected paravirtual devices. This
patch introduces a new xenbus controller type that includes a
maxGrantFrames attribute.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      09eb1ae0
  41. 12 3月, 2019 2 次提交
  43. 05 3月, 2019 9 次提交
  45. 24 2月, 2019 1 次提交
  47. 06 2月, 2019 1 次提交
  49. 27 1月, 2019 1 次提交
    • R
      bhyve: implement support for commandline args · 0c8df110
      由 Roman Bogorodskiy 提交于 
      Implement support for passing custom command line arguments
to bhyve using the 'bhyve:commandline' element:

  <bhyve:commandline>
    <bhyve:arg value='-newarg'/>
  </bhyve:commandline>

 * Define virDomainXMLNamespace for the bhyve driver, which
   at this point supports only the 'commandline' element
   described above,
 * Update command generation code to inject these command line
   arguments between driver-generated arguments and the vmname
   positional argument.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      0c8df110
  51. 04 1月, 2019 1 次提交
  53. 02 1月, 2019 1 次提交