All Xen domains have a xenbus device. Implicitly add one if not
already explicitly specified in the domain config.
Signed-off-by: Jim Fehlig
---
Lot's of test churn!!
src/libxl/libxl_domain.c | 5 +
tests/sexpr2xmldata/sexpr2xml-boot-grub.xml
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
Add support for setting max_grant_frames in libxl domain config
object and include a test to check that it is properly converted
from XML to libxl domain config.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_conf.c| 9 ++
.../max-gntframes-hvm.json|
Add support in the domXML<->native config converter for
max_grant_frames. Include a test for the conversion.
Signed-off-by: Jim Fehlig
---
src/xenconfig/xen_xl.c| 56 +++
tests/xlconfigdata/test-max-gntframes.cfg | 13 ++
This patch series takes the long road on the way to adding support
for Xen's max_grant_frames to libvirt. Patch1 adds a new 'xenbus'
controller type that supports a maxGrantFrames attribute.
maxGrantFrames describes the maximum IO buffer space (or DMA space)
available in the xenbus controller for
This patch adds documentation of an -audiodev command line option, that
deprecates the old QEMU_* environment variables for audio backend
configuration. It's syntax is similar to existing options (-netdev,
-device, etc):
-audiodev driver_name,property=value,...
Although now it's possible to
On 3/6/19 7:17 AM, Andrea Bolognani wrote:
> Some devices (namely virtio-scsi, virtio-gpu, virtio-keyboard,
> virtio-tablet and virtio-mouse, plus virtio-crypto which is
> not supported by libvirt) don't follow the same rules as all
> other virtio devices, which is something that ought to be
>
On 3/6/19 7:17 AM, Andrea Bolognani wrote:
> While the parser and schema have to accept all possible models,
> virtio-(non-)transitional models are only applicable to
> type=passthrough and should be otherwise rejected.
>
> Signed-off-by: Andrea Bolognani
> ---
> src/libvirt_private.syms
On 2/27/19 1:07 PM, Andrea Bolognani wrote:
> See patch 2/2.
>
> Andrea Bolognani (2):
> tests: Add simple guests with graphics to qemuxml2argv
> qemu: Allow creating ppc64 guests with graphics and no USB mouse
>
> src/qemu/qemu_domain.c| 20 +++
>
We target both Debian 9 and Debian sid, with all
architectures libvirt can reasonably be cross-compiled to
with the exception of i686, which we still haven't quite
sorted out on the lcitool side.
Signed-off-by: Andrea Bolognani
---
buildenv-debian-9-cross-aarch64.Dockerfile| 95
This behaves mostly like a drop-in replacement for the
original shell script, with a few differences:
* the script figures out which Dockerfiles should be
generated by looking at the contents of the repository
rather than by asking lcitool. This makes it possible to
skip generation
lcitool can generate these Dockerfiles already, so we just
need to parse the relevant information encoded in the file
name and hand them over.
Signed-off-by: Andrea Bolognani
---
refresh | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/refresh
We're going to rewrite the script completely, and getting
the current implementation out of the way firts will make
the diffs more reasonable.
Signed-off-by: Andrea Bolognani
---
refresh | 30 --
1 file changed, 30 deletions(-)
delete mode 100755 refresh
diff --git
lcitool supports generating Dockerfiles targeting cross-compilation
of libvirt, so all that's left to do is teach the refresh script
how to pass the necessary information to lcitool.
Andrea Bolognani (4):
refresh: Drop shell implementation
refresh: Add Python implementation
refresh: Add
Fill in a default volume type for every pool type, as reported
by the VolGetInfo API. Now that we cover the whole enum, report
an error for invalid values.
Signed-off-by: Cole Robinson
---
v2: Use virReportEnumRangeError and handle the error in the caller
index ef754658f3..08970f8d6c 100644
---
On 3/8/19 7:40 AM, John Ferlan wrote:
>
>
> On 3/7/19 2:35 PM, Cole Robinson wrote:
>> Fill in a default volume type for every pool type, as reported
>> by the VolGetInfo API.
>>
>> Signed-off-by: Cole Robinson
>> ---
>> A more complete fix would take into account VolDef->type, so test
>>
On 3/8/19 8:34 AM, John Ferlan wrote:
On 2/24/19 9:15 AM, ZhiPeng LU wrote:
This patch adds functionality to allow libvirt to configure the '802.1ad'
modes(802.1ad double-tagged) on openvswitch networks.
For example:
On Thu, 2019-03-07 at 18:19 +0100, Pavel Hrdina wrote:
> Only PCI devices have '/sys/class/net//device/resource' so we
> need to skip this check for all other network devices.
>
> Without this patch and RDMA enabled libvirt will not detect any network
> device that doesn't have the path above
On Thu, 7 Mar 2019 at 15:23, Gerd Hoffmann wrote:
>
> The following changes since commit 32694e98b8d7a246345448a8f707d2e11d6c65e2:
>
> Merge remote-tracking branch
> 'remotes/ehabkost/tags/machine-next-pull-request' into staging (2019-03-06
> 18:52:19 +)
>
> are available in the Git
On 2/27/19 10:01 AM, Pavel Hrdina wrote:
> If we pass XML to virDomainDefineXML API with these two elements:
>
> ...
>
>
> ...
>
> libvirt correctly ignores these two elements and they will not appear
> in the parsed XML.
>
> However, if we use virDomainSetMetadata API and
On 2/24/19 9:15 AM, ZhiPeng LU wrote:
> This patch adds functionality to allow libvirt to configure the '802.1ad'
> modes(802.1ad double-tagged) on openvswitch networks.
> For example:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Signed-off-by:
On 3/7/19 4:57 PM, Michal Privoznik wrote:> On 3/1/19 11:29 AM, Boris
Fiuczynski wrote:
> ACKed and pushed.
>
> Michal
Thanks, Michael
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
Mit freundlichen Grüßen/Kind regards
On 3/7/19 2:35 PM, Cole Robinson wrote:
> Fill in a default volume type for every pool type, as reported
> by the VolGetInfo API.
>
> Signed-off-by: Cole Robinson
> ---
> A more complete fix would take into account VolDef->type, so test
> driver users could set this value via volume XML. That
For session mode, only XDG_CACHE_HOME is set, because we want to remain
integrating with services in user session, but for system mode, this
would have become reading/writing to '/' which carries the obvious issue
with permissions (also, '/' is the wrong location in 99.9% cases anyway).
v1 here:
https://www.redhat.com/archives/libvir-list/2019-March/msg00323.html
since v1:
As per conversation with Dan P.B:
- dropped XDG setting (apart from XDG_CACHE_HOME - we need that)
for session QEMU
- dropped setting HOME for session mode (HOME is passed from the session)
- dropped
By default, qemu user's home dir points to '/' which shouldn't be used
at all. We therefore pass the HOME variable from the current variable
iff not running as SUID, which means that for systemd we never set it.
This patch makes sure, that for system QEMU this is always set to
libDir/, session
Some modules/libraries within QEMU could make use of the XDG_ vars when
writing their data to the disk. Define the most common XDG variables
and point them to the specific driver's libDir, i.e.
XDG_CACHE_HOME -> /var/lib/libvirt//.cache
XDG_DATA_HOME -> /var/lib/libvirt//.local/share
...
> >
> > Sorry for the delay in responding. The problem is that all the V100 GPUs
> > support NVLink, but it may or may not be connected up. This is detected
> > at runtime during GPU initialization, which seems like much too heavy of
> > an operation to perform as part of passthrough
On Thu, Mar 07, 2019 at 02:28:03PM -0500, Cole Robinson wrote:
> Signed-off-by: Cole Robinson
> ---
Reviewed-by: Erik Skultety
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, 2019-03-07 at 14:35 -0500, Cole Robinson wrote:
> @@ -5164,13 +5164,26 @@ testStorageVolDelete(virStorageVolPtr vol,
> static int
> testStorageVolumeTypeForPool(int pooltype)
> {
> -switch (pooltype) {
> -case VIR_STORAGE_POOL_DIR:
> -case VIR_STORAGE_POOL_FS:
> -
On 3/7/19 9:17 PM, Thomas Huth wrote:
On 07/03/2019 18.15, Michal Privoznik wrote:
On 3/1/19 12:10 PM, Thomas Huth wrote:
When running virt-host-validate on an s390x host, the tool currently
warns
that it is "Unknown if this platform has IOMMU support". We can use the
common check for entries
On Thu, Mar 07, 2019 at 01:07:23PM -0300, Daniel Henrique Barboza wrote:
> Erik,
>
> It appears that patches 1 and 2 are good to go (and probably can be
> pushed separately from the other 2). Should I resend only patches 3
> and 4 when I get more info from NVIDIA about the detection code
> in
32 matches
Mail list logo
