similar to: Determining domain job kind from job stats?

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

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 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 virDomainGetJobStats or provided in > >> VIR_DOMAIN_EVENT_ID_JOB_COMPLETED

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 started. All jobs currently reported using virDomainGetJobStats API or

Greetings, I am writing a code using libvirt API to migrate VM between two physical hosts *(QEMU/KVM) , *say some *n *number of times. *1)* I am using right now* virDomainPtr virDomainMigrate (.......) *and to calculate the total migration time I am using something like this: *clock_gettime(CLOCK_MONOTONIC_RAW,&begin); * *migrate*(domainToMigrate,nodeToMigrate);

Hi, some custom CPU models are reported from virConnectGetDomainCapabilities as usable='yes' on a physical machine while as usable='no' inside a VM running on the same machine. That's not completely surprising. But what surprises me is that those models are still reported from virConnectCompareCPU as supported (VIR_CPU_COMPARE_SUPERSET) in the nested environment and VMs can

Jiri Denemark <jdenemar@redhat.com> writes: > On Fri, Dec 07, 2018 at 11:52:38 +0100, Milan Zamazal wrote: >> Hi, some custom CPU models are reported from >> virConnectGetDomainCapabilities as usable='yes' on a physical machine > >> while as usable='no' inside a VM running on the same machine. That's >> not completely surprising. >>

[Starting to move to the development list.] Milan Zamazal <mzamazal@redhat.com> writes: > Jiri Denemark <jdenemar@redhat.com> writes: > >> On Fri, Feb 17, 2017 at 12:38:24 +0100, Milan Zamazal wrote: >>> >>> There are basically two problems: >>> >>> - When the job completion callback is called, I need to distinguish what >>>

Please, do not post to several libvirt lists at once. > I am writing a code using libvirt API to migrate VM between two physical > hosts *(QEMU/KVM) , *say some *n *number of times. > > *1)* I am using right now* virDomainPtr virDomainMigrate (.......) *and to > calculate the total migration time I am using something like this: > >

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 >

"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). >> >>

"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

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

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,

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

Daniel P. Berrangé <berrange@redhat.com> writes: > On Thu, Sep 10, 2020 at 04:26:40PM +0200, Milan Zamazal wrote: >> 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

Hi, I've found out that NVDIMM size and label size matter for regular (non-NV) DIMM hot plug. If the NVDIMM is not aligned correctly, the guest OS will not accept the hot plugged memory and will complain with messages such as Block size [0x8000000] unaligned hotplug range: start 0x225000000, size 0x10000000 The start address above is also reported within <memory> element of the hot