similar to: libvirt unavailable while a VM is in migration?]

14.09.2018 15:43, Jiri Denemark пишет: > On Thu, Sep 13, 2018 at 19:37:00 +0400, Dmitry Melekhov wrote: >> >> 13.09.2018 18:57, Jiri Denemark пишет: >>> On Thu, Sep 13, 2018 at 18:38:57 +0400, Dmitry Melekhov wrote: >>>> 13.09.2018 17:47, Jiri Denemark пишет: >>>>> On Thu, Sep 13, 2018 at 10:35:09 +0400, Dmitry Melekhov wrote:

13.09.2018 18:57, Jiri Denemark пишет: > On Thu, Sep 13, 2018 at 18:38:57 +0400, Dmitry Melekhov wrote: >> >> 13.09.2018 17:47, Jiri Denemark пишет: >>> On Thu, Sep 13, 2018 at 10:35:09 +0400, Dmitry Melekhov wrote: >>>> After some mistakes yesterday we ( me and my colleague ) think that it >>>> will be wise for libvirt to check config file existence

Hi, all I test virsh comand "domjobinfo" on x86-i386 and PPC64 host. But Both get nothing. # virsh version Compiled against library: libvir 0.9.13 Using library: libvir 0.9.13 Using API: QEMU 0.9.13 Running hypervisor: QEMU 1.1.50 # virsh list Id Name State ---------------------------------------------------- 21 f16-ppc-qcow2

13.09.2018 17:47, Jiri Denemark пишет: > On Thu, Sep 13, 2018 at 10:35:09 +0400, Dmitry Melekhov wrote: >> After some mistakes yesterday we ( me and my colleague ) think that it >> will be wise for libvirt to check config file existence on remote side > Which config file? > VM config file, namely qemu. We forgot to mount shared storage (namely gluster volume), on which we

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

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

On 01/14/2016 05:12 AM, Daniel P. Berrange wrote: > On Thu, Jan 14, 2016 at 10:51:47AM +0100, Jiri Denemark wrote: >> On Wed, Jan 13, 2016 at 16:25:14 +0100, Martin Kletzander wrote: >>> On Wed, Jan 13, 2016 at 10:18:42AM +0000, Richard W.M. Jones wrote: >>>> As people may know, we frequently encounter errors caused by libvirt >>>> when running the

On Thu, Jan 14, 2016 at 03:54:29PM +0000, Richard W.M. Jones wrote: > > FYI I'm testing the attached patch (written by Jiri Denemark). The > tests usually take a day to run. Yes this patch appears to fix all the problems. Can it be applied to libvirt? Rich. > diff --git i/src/security/security_dac.c w/src/security/security_dac.c > index 80709fe..378b922 100644 > ---

On 17/02/2017 19:50, Jiri Denemark wrote: > > Yeah storage migration should be safe regardless of the cache mode used. > Very good news, thanks. Let me be paranoid: is it *surely* safe? > > This looks like a bug in libvirt. The code doesn't check whether an > affected disk is going to be migrated (--copy-storage-all) or accessed > on the shared storage. > > Jirka

As scheduled, libvirt 0.9.0 was tagged and pushed today, it's available from FTP at: ftp://libvirt.org/libvirt/ This is a large release w.r.t. the amount of features and changes, and well worth bumping the middle version number. We are also getting closer to a 1.0.0 release ! Features: - Support cputune cpu usage tuning (Osier Yang and Nikunj A. Dadhania) - Add public APIs for storage

Following Dan advice, I decided to not wait for more patches and push the current git head as the release. Let's plan to have another release by this month end with the QEmu debugging and hacking APIs. The release is available as usual at ftp://libvirt.org/libvirt Quite a lot of bug fixes during the two months since 0.8.1, and a few new feature. It also tagged more commits as being

As planned and after most of the clang detected problems got fixed (thanks Eric !) the new release is available at: ftp://libvirt.org/libvirt/ It's a mixed release, it includes a number of improvements as well as many bug fixes and a few new features: Features: - support various persistent domain updates (KAMEZAWA Hiroyuki) - improvements on memory APIs (Taku Izumi) - Add

As planned the new release is available at: ftp://libvirt.org/libvirt/ It is a rather large release with near 400 commits included. From an user point of view the main improvement is likely to be when using migration as various work has been done to extend the protocol and to avoid having the migration command stop other concurrent operations (like virsh list). See below for a number of

On Fri, Sep 14, 2018 at 16:00:43 +0400, Dmitry Melekhov wrote: > 14.09.2018 15:43, Jiri Denemark пишет: > > On Thu, Sep 13, 2018 at 19:37:00 +0400, Dmitry Melekhov wrote: > >> > >> 13.09.2018 18:57, Jiri Denemark пишет: > >>> On Thu, Sep 13, 2018 at 18:38:57 +0400, Dmitry Melekhov wrote: > >>>> 13.09.2018 17:47, Jiri Denemark пишет: >

The problem desribed here: https://bugzilla.redhat.com/show_bug.cgi?id=593266 Please update http://www.libvirt.org/formatdomain.html and describe NEW xml tags, like <serial>xxxx</serial> for hard drive and all cpu tags, other if any. -- Segmentation fault

Dear all, I want to have a view of lxc CPU usage in openstack Dashboard. According the Openstack official site , Openstack Ceilometer can poll libvirt daemon to obtain CPU usage of a virtual machine. I tried the command locally on the libvirtd host "virsh -c lxc:/// domjobinfo", I got an error "error: this function is not supported by the connection driver:

With libvirt 6.9.0, qemu 5.1.0, and following configurations: libvirt: key_file = "/etc/ssl/libvirt/server.lan.key" cert_file = "/etc/ssl/libvirt/server.lan.crt" ca_file = "/etc/ssl/libvirt/ca.crt" log_filters="3:remote 4:event 3:util.json 3:rpc 1:*" log_outputs="1:file:/var/log/libvirt/libvirtd.log" qemu: default_tls_x509_cert_dir =

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

hello , thanks for comments . I tried now with force options for CPU flag which were not supported . Now the command with non fully supported CPU model gets executed , But i am surprised to see that still Guest cpu model is not changed and still same as host cpu model(SAndy Bridge) Why don't i see the model as HAswell now , could you please comment. Command used : virt-install

Hi all, I talked to our oVirt developers who use CentOS for upstream development. And that's what makes their lives hard because it takes a long time before they can start using new features of libvirt. The latest released CentOS version is 7.2 with libvirt 1.2.17, which is pretty old. But even when CentOS 7.3 with libvirt 2.0.0 gets released, it will already be old since libvirt 2.5.0 is