If domain is killed with `xl destroy`, libvirt will not notice it and
still report the domain as running. Also trying to destroy the domain
through libvirt will fail. The only way to recover from such a situation
is to restart libvirt daemon. The problem is that even though libxl
report
Since domain was suspended before and on failed wakeup is destroyed,
send an event.
Also, add missing libxlDomainCleanup.
Signed-off-by: Marek Marczykowski-Górecki
---
src/libxl/libxl_driver.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/libxl/libxl_driver.c
On 12/7/18 8:47 AM, Marek Marczykowski-Górecki wrote:
Hi,
If one kills a domain with `xl destroy`, libvirt will not notice it and
still report the domain as running. Also trying to destroy the domain
through libvirt will fail. The only way to recover from such a situation
is to restart libvirt
If virDomainDefCompatibleDevice fails because there is insufficient
domain def->mem.max_memory, then let's also print out that value in
the error message.
Signed-off-by: John Ferlan
---
src/conf/domain_conf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
https://bugzilla.redhat.com/show_bug.cgi?id=1624336
Details are in patch2, but essentially the issue is the check
for whether cold/hot plug of memory is supported occurs during
qemuDomainDefValidateMemoryHotplug; however, that is called
after virDomainDefCompatibleDevice, but is not called
https://bugzilla.redhat.com/show_bug.cgi?id=1624336
Add a check during virDomainDefCompatibleDevice whether the
domain supports cold/hotplug of a memory module even though
this duplicates the qemuDomainDefValidateMemoryHotplug check.
Without this check, the cold/hot plug would fail on the
The previous patch series created separate global libvirt chains for
virtual network rules
This goes further and creates chains per virtual network. The idea is
that when stopping networks, we can just delet the chains, instead of
every individual rule.
Unfortunately creating/deleting/flushing
Rather than putting all rules into libvirt's main private chains, create
a private chain per network. This will make it easier for administrators
to use hooks to customize the chains per network.
For the LIBVIRT_INP, LIBVIRT_OUT, LIBVIRT_FWO and LIBVIRT_FWI chains
it is also possible to set
The previous commit created chains for each virtual network. This commit
adjusts the code so that rules are now put in these new chains.
With two networks running, the filter table thus looks like
-N LIBVIRT_FWI
-N LIBVIRT_FWI_virbr0
-N LIBVIRT_FWI_virbr1
-N LIBVIRT_FWO
-N
Hi,
This series was run against 'syntax-check' test by patchew.org, which failed,
please find the details below:
Subject: [libvirt] [PATCH v2 0/4] Restructure firewall rules for virtual
networks into private chains
Message-id: 20181207162135.15093-1-berra...@redhat.com
Type: series
=== TEST
The previous commit created new chains to hold the firewall rules. This
commit changes the code that creates rules to place them in the new
private chains instead of the builtin top level chains.
With two networks running, the rules in the filter table now look like
-N LIBVIRT_FWI
-N
Some of the query callbacks want to know the firewall layer that was
being used for triggering the query to avoid duplicating that data.
Signed-off-by: Daniel P. Berrangé
---
src/nwfilter/nwfilter_ebiptables_driver.c | 17 ++---
src/util/virfirewall.c| 2 +-
Allow the platform driver impls to run logic before and after the
firewall reload process.
Signed-off-by: Daniel P. Berrangé
---
src/network/bridge_driver.c | 13 -
src/network/bridge_driver_linux.c| 11 +++
src/network/bridge_driver_nop.c | 11 +++
v1: https://www.redhat.com/archives/libvir-list/2018-November/msg00018.html
The virtual networks in NAT mode are supposed to only allow outbound
network access for guests. Unfortunately due to ordering of the firewall
rules libvirt creates, when you have multiple virtual networks, guests
on the
Historically firewall rules for virtual networks were added straight
into the base chains. This works but has a number of bugs and design
limitations:
- It is inflexible for admins wanting to add extra rules ahead
of libvirt's rules, via hook scripts.
- It is not clear to the admin that
From: ZhiPeng Lu
This patch adds functionality to allow libvirt to configure the 'dot1q-tunnel'
modes(802.1ad double-tagged) on openvswitch networks.
For example:
Signed-off-by: ZhiPeng Lu
---
v1->v2:
Hi,
If one kills a domain with `xl destroy`, libvirt will not notice it and
still report the domain as running. Also trying to destroy the domain
through libvirt will fail. The only way to recover from such a situation
is to restart libvirt daemon.
While (I think) the right answer is "don't use
On 18/12/07 11:57, Daniel P. Berrangé wrote:
> On Fri, Dec 07, 2018 at 12:25:18PM +0100, Tomasz Barański wrote:
> > Hello
> >
> > I'm working on supporting VNC console on FIPS-enabled oVirt hosts[1]. I
> > made qemu use SASL as authentication method instead of regular passwords.
> > However, no
The validation code for graphics has been in place for a while, but
because it is only executed from the device iterator, that validation
code was never truly run. The unfortunate side effect of this whole mess
was that a few capabilities were missing from the test suite, which in
turn meant that
As commit d8266ebe161 demonstrated, it's so easy to forget to add a
single capability which in turn can easily fool the test suite so that
tests expecting a failure can fail with a different error than we
expected, but still making those pass. Unfortunately for commit
d8266ebe161, it allowed a
So, this series fixes a few issues that are very tightly coupled, so buckle
up if you want to read further, if not, here you go:
TL;DR:
Issue: there's a test passing even though the code doesn't really work
Result: fix both the code and the test
LONG STORY:
The main issue is that we allow
One of the usages of the device iterator is to run config validation.
That's a problem for graphics devices, because they don't have any @info
data (graphics shouldn't have been considered as devices in the first
place), and simply passing NULL would crash a few callbacks invoked from
the
Since the code was never run, this stupid mistake could have only been
spotted by an accident.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_domain.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index
On Wed, Dec 05, 2018 at 05:57:04PM -0200, Eduardo Habkost wrote:
> Many of the current virtio-*-pci device types actually represent
> 3 different types of devices:
> * virtio 1.0 non-transitional devices
> * virtio 1.0 transitional devices
> * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
On Fri, Dec 07, 2018 at 12:25:18PM +0100, Tomasz Barański wrote:
> Hello
>
> I'm working on supporting VNC console on FIPS-enabled oVirt hosts[1]. I
> made qemu use SASL as authentication method instead of regular passwords.
> However, no matter what I do, I can't get it to accept credentials
Hello
I'm working on supporting VNC console on FIPS-enabled oVirt hosts[1]. I
made qemu use SASL as authentication method instead of regular passwords.
However, no matter what I do, I can't get it to accept credentials provided
with a VNC client.
Is there a way to get some qemu/SASL logs? I need
On Fri, Dec 07, 2018 at 10:45:00AM +0100, Ján Tomko wrote:
> On Thu, Dec 06, 2018 at 05:12:36PM +0100, Erik Skultety wrote:
> > Commit 255e0732 introduced a few graphics-related helpers. The problem
> > is that virDomainGraphicsNeedsAutoRenderNode returns true if it gets
> > NULL as a response
On Thu, Dec 06, 2018 at 05:12:36PM +0100, Erik Skultety wrote:
Commit 255e0732 introduced a few graphics-related helpers. The problem
is that virDomainGraphicsNeedsAutoRenderNode returns true if it gets
NULL as a response from virDomainGraphicsNeedsAutoRenderNode. That's
okay for egl-headless
On Thu, Dec 06, 2018 at 10:58:23AM -0500, Laine Stump wrote:
Commit 017dfa27d changed a few switch statements in the LXC code to
have all possible enum values, and in the process changed the switch
statement in virLXCControllerGetNICIndexes() to return an error status
for unsupported interface
On Thu, Dec 06, 2018 at 10:58:22AM -0500, Laine Stump wrote:
virLXCControllerGetNICIndexes() was deciding whether or not to add the
ifindex for an interface's ifname to the list of ifindexes sent to
CreateMachineWithNetwork based on the interface type stored in the
config. This would be
On 12/07/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
31 matches
Mail list logo
