similar to: Certificate checking on TLS migrations to an IP address

Daniel P. Berrangé <berrange@redhat.com> writes: > On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote: >> Daniel P. Berrangé <berrange@redhat.com> writes: >> > >> > On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote: >> >> Hi, I'm trying to add TLS migrations to oVirt, but I've hit a problem >> >> with

Daniel P. Berrangé <berrange@redhat.com> writes: > On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote: >> Hi, I'm trying to add TLS migrations to oVirt, but I've hit a problem >> with certificate checking. > >> >> oVirt uses the destination host IP address, rather than the host name, >> in the migration URI passed to

Milan Zamazal <mzamazal@redhat.com> writes: > Daniel P. Berrangé <berrange@redhat.com> writes: > >> On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote: >>> Daniel P. Berrangé <berrange@redhat.com> writes: >>> >> >>> > On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote: >>> >> Hi, I'm trying

On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote: > Daniel P. Berrangé <berrange@redhat.com> writes: > > > On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote: > >> Hi, I'm trying to add TLS migrations to oVirt, but I've hit a problem > >> with certificate checking. > > > >> > >> oVirt uses the destination

On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote: > Hi, I'm trying to add TLS migrations to oVirt, but I've hit a problem > with certificate checking. > > oVirt uses the destination host IP address, rather than the host name, > in the migration URI passed to virDomainMigrateToURI3. One reason for > doing that is that a separate migration network may be used

"Daniel P. Berrange" <dan@berrange.com> writes: > On Wed, Aug 26, 2020 at 10:35:22PM +0200, Milan Zamazal wrote: >> Hi, >> > >> we have a problem in oVirt that highly available VMs don't restart after >> host poweroff because Vdsm identifies the case as a user initiated >> shutdown (https://bugzilla.redhat.com/1800966). >> >>

Hi, we have a problem in oVirt that highly available VMs don't restart after host poweroff because Vdsm identifies the case as a user initiated shutdown (https://bugzilla.redhat.com/1800966). When poweroff is run on the host, libvirt-guests service takes an action. `virsh shutdown' is run on the VM, the guest OS is shut down cleanly and libvirt reports a shutdown event with

Michal Prívozník <mprivozn@redhat.com> writes: > On 09/19/2018 12:39 PM, Milan Zamazal wrote: >> Hi, I'm playing with dynamic ownership and not all objects have their >> owners changed. > >> >> Is dynamic_ownership and its scope documented somewhere, besides the >> comment in qemu.conf? >> >> And what kinds of objects are handled by

Hi, I'm playing with dynamic ownership and not all objects have their owners changed. Is dynamic_ownership and its scope documented somewhere, besides the comment in qemu.conf? And what kinds of objects are handled by dynamic ownership? While some objects seem to be handled, other objects are apparently unaffected. For instance /dev/hwrng or a USB host device keep their root owners and are

Hi guys, I met a problem when I use tls to connect libvirt. When I set the CN in client.info, server.info as hostname(FDQN), the tls check will fail with ip; and vice versa, when set CN as ip address, the tls check will fail with hostname. Only use what we set in can succeed. If this is expected? or I there was some issue in my env. or setup steps? 1. set tls env with hostname, then it will

On Thu, Jul 09, 2020 at 14:14:32 +0200, Milan Zamazal wrote: > Milan Zamazal <mzamazal@redhat.com> writes: > > > Hi, > > > > I would like to clarify how to make snapshots of running VMs with > > emulated TPM devices. As far as I understand QEMU documentation, it's > > possible to make snapshots of running VMs with TPM, but it's important >

Hi, when retrieving an mdev device info using `virsh nodedev-dumpxml' or the libvirt API, something like the following is returned: <capability type='mdev_types'> <type id='nvidia-210'> <name>GRID M60-2B4</name> <deviceAPI>vfio-pci</deviceAPI> <availableInstances>4</availableInstances>

"Daniel P. Berrange" <berrange@redhat.com> writes: > On Fri, Mar 17, 2017 at 11:55:13AM +0100, Milan Zamazal wrote: >> Hi, we experienced a strange, non-reproducible error after a successful >> migration to another host. When we called virDomainDestroyFlags with >> VIR_DOMAIN_DESTROY_GRACEFUL flag after the migration on the source host, >> we got

Jiri Denemark <jdenemar@redhat.com> writes: > On Fri, Feb 17, 2017 at 12:38:24 +0100, Milan Zamazal wrote: >> Jiri Denemark <jdenemar@redhat.com> writes: >> >> > On Fri, Feb 10, 2017 at 21:50:19 +0100, Milan Zamazal wrote: >> >> Hi, is there a reliable way to find out to what kind of job does the >> >> information returned from

On Thu, Jul 09, 2020 at 17:54:23 +0200, Milan Zamazal wrote: > Peter Krempa <pkrempa@redhat.com> writes: > > > On Thu, Jul 09, 2020 at 14:14:32 +0200, Milan Zamazal wrote: > >> Milan Zamazal <mzamazal@redhat.com> writes: > >> > > > >> > Hi, > >> > > >> > I would like to clarify how to make snapshots of running

Hi, I would like to clarify how to make snapshots of running VMs with emulated TPM devices. As far as I understand QEMU documentation, it's possible to make snapshots of running VMs with TPM, but it's important to retain the state of swtpm. Does libvirt assist with that in any way or is it completely user's responsibility? libvirt pauses the VM internally when making a snapshot,

Jiri Denemark <jdenemar@redhat.com> writes: > On Fri, Feb 10, 2017 at 21:50:19 +0100, Milan Zamazal wrote: >> Hi, is there a reliable way to find out to what kind of job does the >> information returned from virDomainGetJobStats or provided in >> VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event callback belong to? > > No, libvirt expects that the caller knows what job it

Peter Krempa <pkrempa@redhat.com> writes: > On Fri, Oct 12, 2018 at 19:33:54 +0200, Milan Zamazal wrote: >> Hi, when working on hot unplugs of various devices, I've found out that >> hot unplugging <lease> device doesn't generate >> VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED event. <lease> also doesn't have an >> alias, so it wouldn't be

I have several hardware and software phones connected to Asterisk 1.2.1 from Debian via SIP or IAX2 and I have defined call transfer codes in features.conf. Everything works with the only exception: When I call a _SIP_ _software_ phone (namely Ekiga or Kphone), I can't transfer the call from the _callee_ via the configured DTMF codes. It seems Asterisk completely ignores the sent DTMF codes

Daniel P. Berrangé <berrange@redhat.com> writes: > On Thu, Jul 02, 2020 at 01:21:15PM +0200, Milan Zamazal wrote: >> Hi, >> > >> I've met two situations with NVDIMM support in libvirt where I'm not >> sure all the parties (libvirt & I) do the things correctly. >> >> The first problem is with memory alignment and size changes. In