On Fri, Nov 30, 2018 at 12:50:26PM -0500, Jason Baron wrote:
> Guest network devices can set 'overflow' when there are a number of multicast
> ips configured. For virtio_net, the limit is only 64. In this case, the list
> of mac addresses is empty and the 'overflow' condition is set. Thus, the
Guest network devices can set 'overflow' when there are a number of multicast
ips configured. For virtio_net, the limit is only 64. In this case, the list
of mac addresses is empty and the 'overflow' condition is set. Thus, the guest
will currently receive no multicast traffic in this state.
When
On Thu, Nov 29, 2018 at 03:20:16PM +0100, Erik Skultety wrote:
Since we need to specify the rendernode option onto QEMU cmdline, we
need this union member to retain consistency in how we build the
cmdline.
Signed-off-by: Erik Skultety
---
src/conf/domain_conf.h | 3 +++
1 file changed, 3
On Thu, Nov 29, 2018 at 03:20:15PM +0100, Erik Skultety wrote:
Now that we have QAPI introspection of display types in QEMU upstream,
we can check whether the 'rendernode' option is supported with
egl-headless display type.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_capabilities.c
Thanks for the quick peek on patch1; however, I was hoping to have these
patches be considered for the current release seeing as patch2 fixes a
condition introduced in the release and because the next release won't
be until mid January or so. The downside of not pushing patch2 is that
running
On 11/30/18 9:53 AM, Wang King wrote:
> The issue occurs when I make repeated calls to virDomainReboot with
> VIR_DOMAIN_REBOOT_DEFAULT flag. In the first call to reboot domain,
> the qemu driver chose ACPI path, and set priv->fakeReboot to true.
> Then in a second call, qemu driver chose agent to
On Thu, Nov 29, 2018 at 03:20:14PM +0100, Erik Skultety wrote:
We're going to need a bit more logic for egl-headless down the road so
prepare a helper just like for the other display types.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_command.c | 18 --
1 file changed, 16
On Thu, Nov 29, 2018 at 03:20:13PM +0100, Erik Skultety wrote:
Up until now, we formatted 'rendernode=' onto QEMU cmdline only if the
user specified it in the XML, otherwise we let QEMU do it for us. This
causes permission issues because by default the /dev/dri/renderDX
permissions are as
On Thu, Nov 29, 2018 at 03:20:12PM +0100, Erik Skultety wrote:
A few simple helpers that allow us to determine whether a graphics can
and will need to make use of a DRM render node.
Signed-off-by: Erik Skultety
---
src/conf/domain_conf.c | 41
This commit includes a test case for multiple network definitions. It is
useful right now, but it will be more useful when the index used by LXC
version 3.X is implemented to support this new settings. The version 3.X
is using indexes to specify each network settings.
Signed-off-by: Julio Faracco
This commit fixes a bug when you have multiple network settings defined.
Basically, if you set an IPv6 or IPv4 gateway, it carries on next
network settings. It is happening because the data is not being
initialized when a new network type is defined. So, the old data still
persists into the
This serie fixes a bug related to IPv{4,6} gateway settings when it is
defined and used with multiple network definitions. Basically, this data
is being carried on to the next network settings because the pointer is
not being cleaned up/initialized properly. The idea behind the fix was
create a
The issue occurs when I make repeated calls to virDomainReboot with
VIR_DOMAIN_REBOOT_DEFAULT flag. In the first call to reboot domain,
the qemu driver chose ACPI path, and set priv->fakeReboot to true.
Then in a second call, qemu driver chose agent to reboot which set
fakeReboot to false. But
13 matches
Mail list logo
