- Devel - libvirt List Archives

[libvirt] [PATCH v2 0/5] Introduce VIR_CONNECT_GET_ALL_DOMAINS_STATS_NOWAIT
by Michal Privoznik 19 Jun '18

19 Jun '18

v2 of: https://www.redhat.com/archives/libvir-list/2018-June/msg00546.html diff to v1: - Rename to STATS_NOWAIT - John's review worked in - added comment to qemuDomainObjBeginJobNowait Michal Privoznik (5): qemu_domain: Document qemuDomainObjBeginJob qemuDomainObjBeginJobInternal: Remove spurious @ret assignment qemu_domain: Introduce qemuDomainObjBeginJobNowait Introduce VIR_CONNECT_GET_ALL_DOMAINS_STATS_NOWAIT virsh: Introduce --nowait to domstats include/libvirt/libvirt-domain.h | 2 ++ src/libvirt-domain.c | 12 ++++++++ src/qemu/qemu_domain.c | 60 +++++++++++++++++++++++++++++++++++----- src/qemu/qemu_domain.h | 4 +++ src/qemu/qemu_driver.c | 15 ++++++++-- tools/virsh-domain-monitor.c | 7 +++++ tools/virsh.pod | 16 +++++++---- 7 files changed, 101 insertions(+), 15 deletions(-) -- 2.16.4

3 9

[libvirt] [PATCH] tests: add test file for smartcard database
by Anya Harter 19 Jun '18

19 Jun '18

Add test case explicitly defining a smartcard host certificates database via the following xml: <smartcard mode='host-certificates'> <database>/tmp/foo</database> </smartcard> This case is not currently covered in the test suite. Signed-off-by: Anya Harter <aharter(a)redhat.com> --- .../smartcard-host-certificates-database.args | 28 +++++++++++++++ .../smartcard-host-certificates-database.xml | 21 +++++++++++ tests/qemuxml2argvtest.c | 2 ++ .../smartcard-host-certificates-database.xml | 35 +++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 5 files changed, 87 insertions(+) create mode 100644 tests/qemuxml2argvdata/smartcard-host-certificates-database.args create mode 100644 tests/qemuxml2argvdata/smartcard-host-certificates-database.xml create mode 100644 tests/qemuxml2xmloutdata/smartcard-host-certificates-database.xml diff --git a/tests/qemuxml2argvdata/smartcard-host-certificates-database.args b/tests/qemuxml2argvdata/smartcard-host-certificates-database.args new file mode 100644 index 0000000000..bc159f234d --- /dev/null +++ b/tests/qemuxml2argvdata/smartcard-host-certificates-database.args @@ -0,0 +1,28 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/home/test \ +USER=test \ +LOGNAME=test \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-i686 \ +-name QEMUGuest1 \ +-S \ +-machine pc,accel=tcg,usb=off,dump-guest-core=off \ +-m 214 \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\ +server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-no-acpi \ +-boot c \ +-device usb-ccid,id=ccid0,bus=usb.0,port=1 \ +-usb \ +-device ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,\ +cert3=cert3,db=/tmp/foo,id=smartcard0,bus=ccid0.0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 diff --git a/tests/qemuxml2argvdata/smartcard-host-certificates-database.xml b/tests/qemuxml2argvdata/smartcard-host-certificates-database.xml new file mode 100644 index 0000000000..fa35645736 --- /dev/null +++ b/tests/qemuxml2argvdata/smartcard-host-certificates-database.xml @@ -0,0 +1,21 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <devices> + <emulator>/usr/bin/qemu-system-i686</emulator> + <smartcard mode='host-certificates'> + <certificate>cert1</certificate> + <certificate>cert2</certificate> + <certificate>cert3</certificate> + <database>/tmp/foo</database> + </smartcard> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index f44cac9fef..194a8d2bab 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1404,6 +1404,8 @@ mymain(void) QEMU_CAPS_CCID_EMULATED); DO_TEST("smartcard-host-certificates", QEMU_CAPS_CCID_EMULATED); + DO_TEST("smartcard-host-certificates-database", + QEMU_CAPS_CCID_EMULATED); DO_TEST("smartcard-passthrough-tcp", QEMU_CAPS_CCID_PASSTHRU); DO_TEST("smartcard-passthrough-spicevmc", diff --git a/tests/qemuxml2xmloutdata/smartcard-host-certificates-database.xml b/tests/qemuxml2xmloutdata/smartcard-host-certificates-database.xml new file mode 100644 index 0000000000..55d54a4355 --- /dev/null +++ b/tests/qemuxml2xmloutdata/smartcard-host-certificates-database.xml @@ -0,0 +1,35 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-i686</emulator> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ccid' index='0'/> + <smartcard mode='host-certificates'> + <certificate>cert1</certificate> + <certificate>cert2</certificate> + <certificate>cert3</certificate> + <database>/tmp/foo</database> + <address type='ccid' controller='0' slot='0'/> + </smartcard> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </memballoon> + </devices> +</domain> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index f5805c7f50..4449954ad4 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -1163,6 +1163,7 @@ mymain(void) DO_TEST("smartcard-host", NONE); DO_TEST("smartcard-host-certificates", NONE); + DO_TEST("smartcard-host-certificates-database", NONE); DO_TEST("smartcard-passthrough-tcp", NONE); DO_TEST("smartcard-passthrough-spicevmc", NONE); DO_TEST("smartcard-controller", NONE); -- 2.17.1

2 1

[libvirt] [PATCH] qemu: Fix qemuMonitorCreateObjectProps
by John Ferlan 18 Jun '18

18 Jun '18

Commit id f0a23c0c3 introduced qemuMonitorCreateObjectProps to manage wrapping the object name and alias; however, calling virJSONValueObjectCreateVArgs and checking a unary ! return status meant when the CreateVAArgs function returned zero, then rather than generating a @propsret, the jump to cleanup would result in an unexpected failure and cause virsh to issue the "error: An error occurred, but the cause is unknown" error message for something like "virsh iothreadadd $DOM 10" (assuming that IOThread 10 didn't already exist). Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/qemu/qemu_monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index b29672d4f1..d6771c1d52 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -3051,7 +3051,7 @@ qemuMonitorCreateObjectProps(virJSONValuePtr *propsret, va_start(args, alias); - if (!(virJSONValueObjectCreateVArgs(&props, args))) + if (virJSONValueObjectCreateVArgs(&props, args) < 0) goto cleanup; if (!(*propsret = qemuMonitorCreateObjectPropsWrap(type, alias, &props))) -- 2.14.4

2 2

[libvirt] [libvirt-go-xml PATCH v2 0/2] Add support for domain launch security
by Erik Skultety 18 Jun '18

18 Jun '18

since v1: - added a launch security subtype for SEV to avoid having a 'type' XML attribute Erik Skultety (2): Add support for domain launch security Add support for SEV in domain capabilities XML domain.go | 162 ++++++++++++++++++++++++++++++++++++++++++++++++- domain_capabilities.go | 7 +++ 2 files changed, 168 insertions(+), 1 deletion(-) -- 2.14.4

2 5

[libvirt] [dockerfiles PATCH] README: Provide information about the images
by Andrea Bolognani 18 Jun '18

18 Jun '18

Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Note that this document will be displayed both for the repository containing the Dockerfiles https://github.com/libvirt/libvirt-dockerfiles and for the images produced by said Dockerfiles, eg. https://hub.docker.com/r/libvirt/buildenv-centos-7/ so the language is intentionally vague at times. I believe I've achieved a decent balance between the needs of the two scenarios, but I'm of course totally open to feedback :) README.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/README.md b/README.md index a84caf3..ccd7ad1 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,52 @@ Docker-based build environments for libvirt =========================================== + +These images come with all libvirt build dependencies, including +optional ones, already installed: this makes it possible to run +something like + + $ docker run \ + -v $(pwd):/libvirt \ + -w /libvirt \ + -it \ + buildenv-centos-7 + +from a git clone and start building libvirt right away. + +Image availability is influenced by libvirt's +[platform support policy](https://libvirt.org/platforms.html), +with the obvious caveat that non-Linux operating systems can't +be run on top of a Linux kernel and as such are not included. + + +Intended use +------------ + +The images are primarily intended for use on +[Travis CI](https://travis-ci.org/libvirt/libvirt). + +The primary CI environment for the libvirt project is hosted on +[CentOS CI](https://ci.centos.org/view/libvirt/); however, since +that environment feeds off the `master` branch of the various +projects, it can only detect issues after the code causing them +has already been merged. + +While testing on Travis CI doesn't cover as many platforms or the +interactions between as many components, it can be very useful as +a smoke test of sorts that allows developers to catch mistakes +before posting patches to the mailing list. + +As an alternative, images can be used locally without relying on +third-party services; in this scenario, the number of platforms +patches are tested against is only limited by image availability +and hardware resources. + + +Information about build dependencies +------------------------------------ + +The list of build dependencies for libvirt (as well as many +other virtualization-related projects) is taken from the +[libvirt-jenkins-ci](https://libvirt.org/git/?p=libvirt-jenkins-ci.git) +repository, which also contains the tooling used to generate +Dockerfiles. -- 2.17.1

2 1

[libvirt] [PATCH v2 0/3] qemu: Allow concurrent access to monitor and guest agent
by Michal Privoznik 18 Jun '18

18 Jun '18

v2 of: https://www.redhat.com/archives/libvir-list/2018-June/msg00700.html diff to v1: - extended THREADS.txt documentation - added more comments - merged 3/4 to 1/4 in original patch set (I think that's everything that was pointed out in John's review) Michal Privoznik (3): qemu: Introduce qemuDomainAgentJob qemu: Introduce APIs for manipulating qemuDomainAgentJob qemu: Switch code to use new agent job APIs src/qemu/THREADS.txt | 112 ++++++++++++++++++++++++++--- src/qemu/qemu_domain.c | 191 ++++++++++++++++++++++++++++++++++++++++--------- src/qemu/qemu_domain.h | 30 ++++++++ src/qemu/qemu_driver.c | 91 ++++++++++++++--------- 4 files changed, 345 insertions(+), 79 deletions(-) -- 2.16.4

1 3

[libvirt] [PATCH] events: Remove ATTRIBUTE_NONNULL for virObjectEventStateQueue[Remote]
by John Ferlan 18 Jun '18

18 Jun '18

Commit aad3a0b5f altered virObjectEventStateQueueRemote to move the "if (!event) return" call added in the previous commit 031eb8f6 to virObjectEventStateQueue. Neither commit altered the function prototype which used ATTRIBUTE_NONNULL(2). This caused Coverity build problems. Since @event is now checked, just remove the ATTRIBUTE_NONNULL check from both prototypes. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/conf/object_event.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Although a Coverity build breaker, that doesn't affect everyone so I'll wait for R-By or ACK for push. diff --git a/src/conf/object_event.h b/src/conf/object_event.h index 133f7ed914..70e9579e81 100644 --- a/src/conf/object_event.h +++ b/src/conf/object_event.h @@ -62,13 +62,13 @@ typedef void (*virConnectObjectEventGenericCallback)(virConnectPtr conn, void virObjectEventStateQueue(virObjectEventStatePtr state, virObjectEventPtr event) - ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); + ATTRIBUTE_NONNULL(1); void virObjectEventStateQueueRemote(virObjectEventStatePtr state, virObjectEventPtr event, int remoteID) - ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); + ATTRIBUTE_NONNULL(1); int virObjectEventStateDeregisterID(virConnectPtr conn, -- 2.14.4

2 1

[libvirt] [libvirt-go PATCH 0/2] Add bindings for recent libvirt SEV APIs
by Erik Skultety 18 Jun '18

18 Jun '18

*** BLURB HERE *** Erik Skultety (2): Add support for AMD SEV launch security info Add support for AMD SEV platform info connect.go | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ connect_compat.go | 12 +++++++++++ connect_compat.h | 7 +++++++ domain.go | 41 ++++++++++++++++++++++++++++++++++++++ domain_compat.go | 13 ++++++++++++ domain_compat.h | 6 ++++++ 6 files changed, 138 insertions(+) -- 2.14.4

2 5

[libvirt] [PATCH] qemuDomainDetachDeviceConfig: Don't free device from @dev
by Michal Privoznik 18 Jun '18

18 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1591561 For reasons I don't understand my original patch of 75f0fd51124 freed not only the chardev from domain but also the one from passed virDomainDeviceDefPtr. This caused no troubles until now, because those two pointers were separate, but after I've introduced virDomainDetachDeviceAlias() they became the same resulting in double free on detach. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_driver.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 42069ee617..7fe86d4d2e 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -8241,8 +8241,6 @@ qemuDomainDetachDeviceConfig(virDomainDefPtr vmdef, return -1; virDomainChrDefFree(chr); - virDomainChrDefFree(dev->data.chr); - dev->data.chr = NULL; break; case VIR_DOMAIN_DEVICE_FS: -- 2.16.4

2 1

[libvirt] [PATCH v2 0/3] cmdDomblkinfo: introduce --all to show all block devices info
by Chen Hanxiao 15 Jun '18

15 Jun '18

This series introduce --all to cmdDomblkinfo to show all block devices info in one cmd. Likes a combination of domblklist and domblkinfo. v2: add support --human for --all v1.1 fix a self test Chen Hanxiao (3): cmdDomblkinfo: introduce helper cmdDomblkinfoPrint cmdDomblkinfo: add --all to show all block devices info news: add cmdDomblkinfo --all option docs/news.xml | 8 +++ tools/virsh-domain-monitor.c | 125 +++++++++++++++++++++++++++++------ tools/virsh.pod | 5 +- 3 files changed, 118 insertions(+), 20 deletions(-) -- 2.17.1

2 8

[libvirt] [PATCH v2 0/5] travis: Use pre-built Docker images
by Andrea Bolognani 15 Jun '18

15 Jun '18

Changes from [v1]: * store Dockerfiles in git so that we can have automated builds on Docker Hub; * add MinGW builds; * change image naming convention, from eg. libvirt/build:fedora-28 to libvirt/buildenv-fedora-28. [v1] https://www.redhat.com/archives/libvir-list/2018-June/msg00920.html Andrea Bolognani (5): docker: Commit initial Dockerfiles travis: Drop Ubuntu 16.04 build travis: Use pre-built Docker images travis: Add CentOS 7 build travis: Add MinGW builds .docker/buildenv-centos-7.Dockerfile | 70 ++++++++++++++ .docker/buildenv-debian-8.Dockerfile | 76 +++++++++++++++ .docker/buildenv-debian-9.Dockerfile | 78 ++++++++++++++++ .docker/buildenv-debian-sid.Dockerfile | 78 ++++++++++++++++ .docker/buildenv-fedora-27.Dockerfile | 78 ++++++++++++++++ .docker/buildenv-fedora-28.Dockerfile | 78 ++++++++++++++++ .docker/buildenv-fedora-rawhide.Dockerfile | 102 +++++++++++++++++++++ .docker/buildenv-ubuntu-16.Dockerfile | 79 ++++++++++++++++ .docker/buildenv-ubuntu-18.Dockerfile | 79 ++++++++++++++++ .travis.yml | 101 ++++++-------------- 10 files changed, 745 insertions(+), 74 deletions(-) create mode 100644 .docker/buildenv-centos-7.Dockerfile create mode 100644 .docker/buildenv-debian-8.Dockerfile create mode 100644 .docker/buildenv-debian-9.Dockerfile create mode 100644 .docker/buildenv-debian-sid.Dockerfile create mode 100644 .docker/buildenv-fedora-27.Dockerfile create mode 100644 .docker/buildenv-fedora-28.Dockerfile create mode 100644 .docker/buildenv-fedora-rawhide.Dockerfile create mode 100644 .docker/buildenv-ubuntu-16.Dockerfile create mode 100644 .docker/buildenv-ubuntu-18.Dockerfile -- 2.17.1

2 14

[libvirt] [jenkins-ci POC 0/2] guests: Add Dockerfile generator
by Andrea Bolognani 15 Jun '18

15 Jun '18

See 2/2 for details. Andrea Bolognani (2): guests: Remove OS detection guests: Add Dockerfile generator guests/dockerfile-generator | 72 +++++++++++++++++++ guests/host_vars/libvirt-centos-7/docker.yml | 2 + guests/host_vars/libvirt-centos-7/main.yml | 4 ++ guests/host_vars/libvirt-debian-8/docker.yml | 2 + guests/host_vars/libvirt-debian-8/main.yml | 4 ++ guests/host_vars/libvirt-debian-9/docker.yml | 2 + guests/host_vars/libvirt-debian-9/main.yml | 4 ++ .../host_vars/libvirt-debian-sid/docker.yml | 2 + guests/host_vars/libvirt-debian-sid/main.yml | 4 ++ guests/host_vars/libvirt-fedora-27/docker.yml | 2 + guests/host_vars/libvirt-fedora-27/main.yml | 4 ++ guests/host_vars/libvirt-fedora-28/docker.yml | 2 + guests/host_vars/libvirt-fedora-28/main.yml | 4 ++ .../libvirt-fedora-rawhide/docker.yml | 2 + .../host_vars/libvirt-fedora-rawhide/main.yml | 4 ++ guests/host_vars/libvirt-freebsd-10/main.yml | 4 ++ guests/host_vars/libvirt-freebsd-11/main.yml | 4 ++ .../libvirt-freebsd-current/main.yml | 4 ++ guests/host_vars/libvirt-ubuntu-16/docker.yml | 2 + guests/host_vars/libvirt-ubuntu-16/main.yml | 4 ++ guests/host_vars/libvirt-ubuntu-18/docker.yml | 2 + guests/host_vars/libvirt-ubuntu-18/main.yml | 4 ++ guests/tasks/base.yml | 51 ------------- 23 files changed, 138 insertions(+), 51 deletions(-) create mode 100755 guests/dockerfile-generator create mode 100644 guests/host_vars/libvirt-centos-7/docker.yml create mode 100644 guests/host_vars/libvirt-debian-8/docker.yml create mode 100644 guests/host_vars/libvirt-debian-9/docker.yml create mode 100644 guests/host_vars/libvirt-debian-sid/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-27/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-28/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-rawhide/docker.yml create mode 100644 guests/host_vars/libvirt-ubuntu-16/docker.yml create mode 100644 guests/host_vars/libvirt-ubuntu-18/docker.yml -- 2.17.1

2 5

[libvirt] [PATCH 0/5] Introduce VIR_CONNECT_GET_ALL_DOMAINS_STATS_BEST_EFFORT
by Michal Privoznik 15 Jun '18

15 Jun '18

Problem is, if there is a long standing job on a domain fetching statistics might hiccup which might be a problem for mgmt apps that query stats every few seconds. Orthogonal to this, I think we should break our sync QEMU_JOB_* into two separate jobs: one for qemu monitor the other for qemu guest agent. Problem is, if thread A grabs QEMU_JOB_MODIFY and talks only to guest agent it prevents thread B from grabbing QEMU_JOB_QUERY which wants to talk only to qemu monitor. But this is a different can of worms and I haven't thought it through completely just yet. Michal Privoznik (5): qemu_domain: Document qemuDomainObjBeginJob qemuDomainObjBeginJobInternal: Remove spurious @ret assignment qemu_domain: Introduce qemuDomainObjBeginJobInstant Introcude VIR_CONNECT_GET_ALL_DOMAINS_STATS_BEST_EFFORT virsh: Introduce --best-effort to domstats include/libvirt/libvirt-domain.h | 1 + src/libvirt-domain.c | 10 +++++++++ src/qemu/qemu_domain.c | 47 ++++++++++++++++++++++++++++++++++------ src/qemu/qemu_domain.h | 4 ++++ src/qemu/qemu_driver.c | 15 ++++++++++--- tools/virsh-domain-monitor.c | 7 ++++++ tools/virsh.pod | 16 +++++++++----- 7 files changed, 85 insertions(+), 15 deletions(-) -- 2.16.4

3 20

[libvirt] [PATCH 0/2] SEV: Always format the <sev> element to the domcaps XML
by Erik Skultety 15 Jun '18

15 Jun '18

*** BLURB HERE *** Erik Skultety (2): schema: Fix the definition of SEV in domain capabilities schema conf: Fix formatting of <sev> element in domain capabilities XML docs/schemas/domaincaps.rng | 19 ++++++++++--------- src/conf/domain_capabilities.c | 20 ++++++++++++-------- tests/domaincapsschemadata/basic.xml | 1 + tests/domaincapsschemadata/bhyve_basic.x86_64.xml | 1 + tests/domaincapsschemadata/bhyve_fbuf.x86_64.xml | 1 + tests/domaincapsschemadata/bhyve_uefi.x86_64.xml | 1 + tests/domaincapsschemadata/full.xml | 1 + tests/domaincapsschemadata/libxl-xenfv-usb.xml | 1 + tests/domaincapsschemadata/libxl-xenfv.xml | 1 + tests/domaincapsschemadata/libxl-xenpv-usb.xml | 1 + tests/domaincapsschemadata/libxl-xenpv.xml | 1 + tests/domaincapsschemadata/qemu_1.7.0.x86_64.xml | 1 + .../qemu_2.12.0-virt.aarch64.xml | 1 + tests/domaincapsschemadata/qemu_2.12.0.ppc64.xml | 1 + tests/domaincapsschemadata/qemu_2.12.0.s390x.xml | 1 + tests/domaincapsschemadata/qemu_2.12.0.x86_64.xml | 1 + .../domaincapsschemadata/qemu_2.6.0-virt.aarch64.xml | 1 + tests/domaincapsschemadata/qemu_2.6.0.aarch64.xml | 1 + tests/domaincapsschemadata/qemu_2.6.0.ppc64.xml | 1 + tests/domaincapsschemadata/qemu_2.6.0.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.7.0.s390x.xml | 1 + tests/domaincapsschemadata/qemu_2.8.0-tcg.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.8.0.s390x.xml | 1 + tests/domaincapsschemadata/qemu_2.8.0.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.9.0-q35.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.9.0-tcg.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml | 1 + 27 files changed, 47 insertions(+), 17 deletions(-) -- 2.14.4

2 7

Re: [libvirt] [PATCH v4 3/3] hw/vfio/display: add ramfb support
by Alex Williamson 15 Jun '18

15 Jun '18

On Wed, 13 Jun 2018 10:41:49 +0200 Gerd Hoffmann <kraxel(a)redhat.com> wrote: > So we have a boot display when using a vgpu as primary display. > > Use vfio-pci-ramfb instead of vfio-pci to enable it. Using a different device here seems like it almost guarantees a very complicated path to support under libvirt. What necessitates this versus a simple ramfb=on option to vfio-pci? I'm also not sure I understand the usage model, SeaBIOS and OVMF know how to write to this display, but it seems that the guest does not. I suppose in the UEFI case runtime services can be used to continue writing this display, but BIOS doesn't have such an option, unless we're somehow emulating VGA here. So for UEFI, I can imagine this covers us from power on through firmware boot and up to guest drivers initializing the GPU (assuming the vGPU supports a kernel mode driver, does NVIDIA?), but for BIOS it seems we likely still have a break from the bootloader to GPU driver initialization. For instance, what driver is used to draw the boot animation (or blue screen) on SeaBIOS Windows VM? I'm assuming that this display and the vGPU display are one in the same, so there's some cut from one to the other. Thanks, Alex > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > --- > include/hw/vfio/vfio-common.h | 2 ++ > hw/vfio/display.c | 10 ++++++++++ > hw/vfio/pci.c | 15 +++++++++++++++ > 3 files changed, 27 insertions(+) > > diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h > index a9036929b2..a58d7e7e77 100644 > --- a/include/hw/vfio/vfio-common.h > +++ b/include/hw/vfio/vfio-common.h > @@ -26,6 +26,7 @@ > #include "qemu/queue.h" > #include "qemu/notify.h" > #include "ui/console.h" > +#include "hw/display/ramfb.h" > #ifdef CONFIG_LINUX > #include <linux/vfio.h> > #endif > @@ -143,6 +144,7 @@ typedef struct VFIODMABuf { > > typedef struct VFIODisplay { > QemuConsole *con; > + RAMFBState *ramfb; > struct { > VFIORegion buffer; > DisplaySurface *surface; > diff --git a/hw/vfio/display.c b/hw/vfio/display.c > index 59c0e5d1d7..409d5a2e3a 100644 > --- a/hw/vfio/display.c > +++ b/hw/vfio/display.c > @@ -124,6 +124,9 @@ static void vfio_display_dmabuf_update(void *opaque) > > primary = vfio_display_get_dmabuf(vdev, DRM_PLANE_TYPE_PRIMARY); > if (primary == NULL) { > + if (dpy->ramfb) { > + ramfb_display_update(dpy->con, dpy->ramfb); > + } > return; > } > > @@ -181,6 +184,8 @@ static int vfio_display_dmabuf_init(VFIOPCIDevice *vdev, Error **errp) > vdev->dpy->con = graphic_console_init(DEVICE(vdev), 0, > &vfio_display_dmabuf_ops, > vdev); > + if (strcmp(object_get_typename(OBJECT(vdev)), "vfio-pci-ramfb") == 0) > + vdev->dpy->ramfb = ramfb_setup(errp); > return 0; > } > > @@ -228,6 +233,9 @@ static void vfio_display_region_update(void *opaque) > return; > } > if (!plane.drm_format || !plane.size) { > + if (dpy->ramfb) { > + ramfb_display_update(dpy->con, dpy->ramfb); > + } > return; > } > format = qemu_drm_format_to_pixman(plane.drm_format); > @@ -300,6 +308,8 @@ static int vfio_display_region_init(VFIOPCIDevice *vdev, Error **errp) > vdev->dpy->con = graphic_console_init(DEVICE(vdev), 0, > &vfio_display_region_ops, > vdev); > + if (strcmp(object_get_typename(OBJECT(vdev)), "vfio-pci-ramfb") == 0) > + vdev->dpy->ramfb = ramfb_setup(errp); > return 0; > } > > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c > index 18c493b49e..6a2b42a595 100644 > --- a/hw/vfio/pci.c > +++ b/hw/vfio/pci.c > @@ -3234,9 +3234,24 @@ static const TypeInfo vfio_pci_dev_info = { > }, > }; > > +static void vfio_pci_ramfb_dev_class_init(ObjectClass *klass, void *data) > +{ > + DeviceClass *dc = DEVICE_CLASS(klass); > + > + dc->hotpluggable = false; > +} > + > +static const TypeInfo vfio_pci_ramfb_dev_info = { > + .name = "vfio-pci-ramfb", > + .parent = "vfio-pci", > + .instance_size = sizeof(VFIOPCIDevice), > + .class_init = vfio_pci_ramfb_dev_class_init, > +}; > + > static void register_vfio_pci_dev_type(void) > { > type_register_static(&vfio_pci_dev_info); > + type_register_static(&vfio_pci_ramfb_dev_info); > } > > type_init(register_vfio_pci_dev_type)

4 4

[libvirt] [dbus PATCH v2 00/17] StorageVolume APIs
by Katerina Koukiou 15 Jun '18

15 Jun '18

Changes from v1: - Fixes from reviews - And more: * tests: Moved all xml definitions for tests in separate file. * tests: Renamed all functions that are not supposed to be run as tests, so that they don't have test prefix. I found out that these were running as tests, when I added the new function for listing the volumes from the test driver. test driver doesn't offer any volumes, and the function failed. * tests: To get a test volume I created a pytest fixture, which I add in the setup of the tests that are manipulating with volumes. In this way, the get_test_storage_volume function remained same to the similar purpose functions as suggested in the previous review. Katerina Koukiou (17): Introduce StorageVol Interface Implement ListStorageVolumes for StoragePool Interface test: move XML definition of entities to seperate file tests: rename test_* functions which are not tests Implement StorageVolCreateXML method for StoragePool Interface Implement Name property for StorageVol Interface Implement Key property for StorageVol Interface Implement Path property for StorageVol Interface Implement GetXMLDesc method for StorageVol Interface Implement StorageVolLookupByKey method for Connect Interface Implement StorageVolLookupByName method for StoragePool Interface Implement StorageVolLookupByPath method for Connect Interface Implement Resize method for StorageVol Interface Implement Wipe method for StorageVol Interface Implement GetInfo method for StorageVol Interface Implement Delete method for StorageVol Interface Implement StorageVolCreateXMLFrom method for StoragePool Interface data/Makefile.am | 4 +- data/org.libvirt.Connect.xml | 12 ++ data/org.libvirt.StoragePool.xml | 28 ++++ data/org.libvirt.StorageVol.xml | 51 +++++++ src/Makefile.am | 4 +- src/connect.c | 66 +++++++++ src/connect.h | 1 + src/storagepool.c | 152 ++++++++++++++++++++ src/storagevol.c | 302 +++++++++++++++++++++++++++++++++++++++ src/storagevol.h | 9 ++ src/util.c | 35 +++++ src/util.h | 16 +++ tests/libvirttest.py | 37 ++++- tests/test_connect.py | 69 ++++----- tests/test_domain.py | 20 +-- tests/test_network.py | 14 +- tests/test_storage.py | 79 ++++++++-- tests/xmldata.py | 47 ++++++ 18 files changed, 871 insertions(+), 75 deletions(-) create mode 100644 data/org.libvirt.StorageVol.xml create mode 100644 src/storagevol.c create mode 100644 src/storagevol.h create mode 100644 tests/xmldata.py -- 2.15.0

2 21

[libvirt] [PATCH v2 0/6] travis: Various cleanups and fixes
by Andrea Bolognani 14 Jun '18

14 Jun '18

Changes from [v1]: * keep DOCKER_CMD around instead of removing it completely, which will help once we introduce MinGW builds; * the last two patches are new. [v1] https://www.redhat.com/archives/libvir-list/2018-June/msg00579.html Andrea Bolognani (6): travis: Skip macOS upgrade travis: Don't duplicate Docker invocation travis: Introduce MACOS_CMD travis: Rename DOCKER_CMD to LINUX_CMD travis: Fix error path travis: Skip first compilation for Linux builds .travis.yml | 74 ++++++++++++++++++++++++----------------------------- 1 file changed, 34 insertions(+), 40 deletions(-) -- 2.17.1

2 7

[libvirt] [PATCH 0/4] qemu: Allow concurrent access to monitor and guest agent
by Michal Privoznik 14 Jun '18

14 Jun '18

It is very easy to see these patches in action. Just apply the following diff: diff --git i/src/qemu/qemu_agent.c w/src/qemu/qemu_agent.c index 10c6ef09fa..dd48caecb7 100644 --- i/src/qemu/qemu_agent.c +++ w/src/qemu/qemu_agent.c @@ -1702,6 +1702,8 @@ qemuAgentGetTime(qemuAgentPtr mon, VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK) < 0) goto cleanup; + sleep(120); + if (virJSONValueObjectGetNumberUlong(reply, "return", &json_time) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("malformed return value")); This is to simulate a slow guest agent. Then all you need to do is run: 'virsh domtime $dom' and then 'virsh domstats $dom' from another terminal. Enjoy. Michal Privoznik (4): qemu: Introduce qemuDomainAgentJob qemu: Introduce APIs for manipulating qemuDomainAgentJob qemuDomainAgentJob: Introduce query and modify jobs qemu: Switch code to use new agent job APIs src/qemu/THREADS.txt | 62 ++++++++++++++++-- src/qemu/qemu_domain.c | 169 +++++++++++++++++++++++++++++++++++++++---------- src/qemu/qemu_domain.h | 29 +++++++++ src/qemu/qemu_driver.c | 91 ++++++++++++++++---------- 4 files changed, 281 insertions(+), 70 deletions(-) -- 2.16.4

2 15

[libvirt] [libvirt-go-xml PATCH 0/2] Add support for the AMD SEV feature
by Erik Skultety 14 Jun '18

14 Jun '18

*** BLURB HERE *** Erik Skultety (2): Add support for domain launch security Add support for SEV in domain capabilities XML domain.go | 135 ++++++++++++++++++++++++++++++++++++++++++++++++- domain_capabilities.go | 7 +++ 2 files changed, 141 insertions(+), 1 deletion(-) -- 2.14.4

2 5

[libvirt] [PATCH v4 0/2] Finish the conversion to virConfGetValue* functions
by Fabiano Fidêncio 14 Jun '18

14 Jun '18

This patchset finishes the conversion to virConfGetValue* functions, started by Daniel Berrange a few months ago. Please, mind that although we could make virConfGetValue* functions more generic in order to support numbers and booleans as strings, that doesn't seem the safest path to take. The side-effect of this is that we will have to live with some specific code doing that as part of vmx and xen_common. Once this patchset gets merged, https://wiki.libvirt.org/page/BiteSizedTasks#Finish_conversion_to_virConfGe… can be removed. - Changes since v1: All the "values" from virConfGetValueString() are freed - Changes since v2: All comments from Ján Tomko have been addressed; A few leaks were (possibly) found and they're addressed in the last patch of the series; - Changes since v3: All commentes from Ján Tomko have been addressed in order to lower the non-whitespace changes in the first patch; Fabiano Fidêncio (2): xen_common: Split per-Vif logic from xenParseVif() xen_common: convert to typesafe virConf acessors src/xenconfig/xen_common.c | 535 +++++++++++++++++++++++---------------------- 1 file changed, 273 insertions(+), 262 deletions(-) -- 2.14.3

2 4

[libvirt] [libvirt-python PATCH v2 0/2] Provide coverage for the AMD SEV APIs
by Erik Skultety 14 Jun '18

14 Jun '18

Add support for the recently introduced AMD SEV APIs. since v1: - fixed indentation issues - built against a refreshed master and fixed some compilation errors - added virNodeGetSEVInfo to the XML api override list Erik Skultety (2): Add support for virDomainGetLaunchSecurityInfo Add support for virNodeGetSEVInfo generator.py | 2 ++ libvirt-override-api.xml | 12 ++++++++ libvirt-override.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 88 insertions(+) -- 2.14.4

2 5

[libvirt] [PATCHv2] docs: schema: Add missing <interleave> element to input device
by Lily Zhu 14 Jun '18

14 Jun '18

For the 2 optional sub-elements - <alias> and <address> of input device, make the order of them interchangeable in the XML. Signed-off-by: Lily Zhu <lizhu(a)redhat.com> --- docs/schemas/domaincommon.rng | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 1d06a5e..7c7f956 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -4309,12 +4309,14 @@ </element> </group> </choice> - <optional> - <ref name="alias"/> - </optional> - <optional> - <ref name="address"/> - </optional> + <interleave> + <optional> + <ref name="alias"/> + </optional> + <optional> + <ref name="address"/> + </optional> + </interleave> </element> </define> <define name="hub"> -- 1.8.3.1

2 1

[libvirt] Call to virDomainIsActive hangs forever
by Mathieu Tarral 14 Jun '18

14 Jun '18

Hi ! I'm submitting my messages on this mailing list to request a bit of help on a case that I have where a Python application makes a call to virDomainIsActive, and the call never returns. I have tried to investigate, but as there are no debug symbols for libvirt on Debian Stretch, i can only have the following GDB backtrace: (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f49026f5b76 in virCondWait () from /usr/lib/libvirt.so.0 #2 0x00007f4902808bab in ?? () from /usr/lib/libvirt.so.0 #3 0x00007f490280a433 in virNetClientSendWithReply () from /usr/lib/libvirt.so.0 #4 0x00007f490280abe2 in virNetClientProgramCall () from /usr/lib/libvirt.so.0 #5 0x00007f49027e0ea4 in ?? () from /usr/lib/libvirt.so.0 #6 0x00007f49027ea1bb in ?? () from /usr/lib/libvirt.so.0 #7 0x00007f49027b0ef3 in virDomainIsActive () from /usr/lib/libvirt.so.0 #8 0x00007f4902b7fbd0 in libvirt_virDomainIsActive () from /usr/lib/python3/dist-packages/libvirtmod.cpython-35m-x86_64-linux-gnu.so #9 0x0000558eeec696df in PyCFunction_Call () at ../Objects/methodobject.c:109 The libvirt driver used is QEMU, and i have a specific monitoring in place using virtual machine introspection: https://github.com/KVM-VMI/kvm-vmi Now this specific monitoring somehow triggers this bug, and at this point, i don't know if it's a corner case in the libvirt QEMU driver or not. That's why i would like to have your lights on this. libvirt version: 3.0.0-4 -> Could you tell me where i should look in the code ? -> Do you have more information about this virCondWait ? Which condition is it waiting for ? -> How can i get the symbols without having the recompile libvirt and install it system wide, erasing the binaries installed by the package ? Best regards, -- Mathieu Tarral

5 11

[libvirt] [dbus PATCH 00/15] StorageVolume APIs
by Katerina Koukiou 14 Jun '18

14 Jun '18

StorageVols logically should be nested under StoragePools, however this implementation does not nest the StorageVol interface under StorageVols. Reason is that the current gdbus.c implementation would not allow nesting of objects. Phrdina checked the posibility of rewritting the gdbus.c to support such requirements, but the effort stopped, since such implentation would interfere with the current lazy loading of objects. Thus, this solution appears to be the only viable. Katerina Koukiou (15): Introduce StorageVol Interface Implement ListStorageVolumes for StoragePool Interface Implement StorageVolCreateXML method for StoragePool Interface Implement Name property for StorageVol Interface Implement Key property for StorageVol Interface Implement Path property for StorageVol Interface Implement GetXMLDesc method for StorageVol Interface Implement StorageVolLookupByKey method for Connect Interface Implement StorageVolLookupByName method for StoragePool Interface Implement StorageVolLookupByPath method for Connect Interface Implement Resize method for StorageVol Interface Implement Wipe method for StorageVol Interface Implement GetInfo method for StorageVol Interface Implement Delete method for StorageVol Interface Implement StorageVolCreateXMLFrom method for StoragePool Interface data/Makefile.am | 3 +- data/org.libvirt.Connect.xml | 12 ++ data/org.libvirt.StoragePool.xml | 28 ++++ data/org.libvirt.StorageVol.xml | 51 +++++++ src/Makefile.am | 3 +- src/connect.c | 65 ++++++++ src/connect.h | 1 + src/storagepool.c | 153 +++++++++++++++++++ src/storagevol.c | 321 +++++++++++++++++++++++++++++++++++++++ src/storagevol.h | 9 ++ src/util.c | 35 +++++ src/util.h | 16 ++ tests/libvirttest.py | 17 +++ tests/test_connect.py | 15 ++ tests/test_storage.py | 57 +++++++ 15 files changed, 784 insertions(+), 2 deletions(-) create mode 100644 data/org.libvirt.StorageVol.xml create mode 100644 src/storagevol.c create mode 100644 src/storagevol.h -- 2.15.0

3 35

Re: [libvirt] [Qemu-devel] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
by Eduardo Habkost 14 Jun '18

14 Jun '18

CCing libvir-list. On Mon, Jun 11, 2018 at 11:29:24PM +0200, Igor Mammedov wrote: > On Mon, 11 Jun 2018 16:06:07 -0300 > Eduardo Habkost <ehabkost(a)redhat.com> wrote: > > > On Mon, Jun 11, 2018 at 03:16:25PM +0200, Igor Mammedov wrote: > > > On Fri, 8 Jun 2018 10:21:05 -0300 > > > Eduardo Habkost <ehabkost(a)redhat.com> wrote: > > > > > > > On Thu, Jun 07, 2018 at 02:00:09PM +0200, Igor Mammedov wrote: > > > > > When using --daemonize, the initial lead process will fork a child and > > > > > then wait to be notified that setup is complete via a pipe, before it > > > > > exits. When using --preconfig there is an extra call to main_loop() > > > > > before the notification is done from os_setup_post(). Thus the parent > > > > > process won't exit until the mgmt application connects to the monitor > > > > > and tells QEMU to leave the RUN_STATE_PRECONFIG. The mgmt application > > > > > won't connect to the monitor until daemonizing has completed though. > > > > > > > > > > This is a chicken and egg problem, leading to deadlock at startup. > > > > > > > > > > The only viable way to fix this is to call os_setup_post() before > > > > > the early main_loop() call when --preconfig is used. This has the > > > > > downside that any errors from this point onwards won't be handled > > > > > well by the mgmt application, because it will think QEMU has started > > > > > successfully, so not be expecting an abrupt exit. Moving as much user > > > > > input validation as possible to before the main_loop() call might help, > > > > > but mgmt application should stop assuming that QEMU has started > > > > > successfuly and use other means to collect errors from QEMU (logfile). > > > > > > > > > > Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> > > > > > Signed-off-by: Igor Mammedov <imammedo(a)redhat.com> > > > > > --- > > > > > v5: > > > > > * use original Daniel's patch [1], but addapt it to apply on top of > > > > > "[PATCH v3 1/2] cli: Don't run early event loop if no --preconfig was specified" > > > > > with extra comment and massage commit message a little bit. > > > > > v6: > > > > > * hide os_setup_post_done flag inside of os_setup_post() as it was in v4 > > > > > > > > > > CC: berrange(a)redhat.com > > > > > CC: mreitz(a)redhat.com > > > > > CC: pbonzini(a)redhat.com > > > > > CC: ehabkost(a)redhat.com > > > > > CC: ldoktor(a)redhat.com > > > > > CC: eblake(a)redhat.com > > > > > --- > > > > > os-posix.c | 6 ++++++ > > > > > vl.c | 6 ++++++ > > > > > 2 files changed, 12 insertions(+) > > > > > > > > > > diff --git a/os-posix.c b/os-posix.c > > > > > index 9ce6f74..0246195 100644 > > > > > --- a/os-posix.c > > > > > +++ b/os-posix.c > > > > > @@ -309,8 +309,14 @@ void os_daemonize(void) > > > > > > > > > > void os_setup_post(void) > > > > > { > > > > > + static bool os_setup_post_done; > > > > > int fd = 0; > > > > > > > > > > + if (os_setup_post_done) { > > > > > + return; > > > > > + } > > > > > + os_setup_post_done = true; > > > > > + > > > > > if (daemonize) { > > > > > if (chdir("/")) { > > > > > error_report("not able to chdir to /: %s", strerror(errno)); > > > > > diff --git a/vl.c b/vl.c > > > > > index fa44138..457ff2a 100644 > > > > > --- a/vl.c > > > > > +++ b/vl.c > > > > > @@ -4578,6 +4578,12 @@ int main(int argc, char **argv, char **envp) > > > > > parse_numa_opts(current_machine); > > > > > > > > > > /* do monitor/qmp handling at preconfig state if requested */ > > > > > + if (!preconfig_exit_requested && is_daemonized()) { > > > > > + /* signal parent QEMU to exit, libvirt treats it as a sign > > > > > + * that monitor socket is ready to accept connections > > > > > + */ > > > > > + os_setup_post(); > > > > > + } > > > > > > > > I was looking at the daemonize logic, and noticed it we have a > > > > huge amount of code between this line and the next > > > > os_setup_post() call that could either: > > > > > > > > * call exit() and/or error_report(); or > > > logging would work to the extent mentioned in commit message, > > > i.e. it' would work fine when log file is used otherwise it > > > errors will go to /dev/null > > > > > > so it should be more or less fine on this point > > > > My worry is that most users of error_report() involve an exit() > > call too. > > > > Once we have an active monitor, we must never call exit() > > directly. Even qmp_quit() doesn't call exit() directly. > Is there any reason why exit() can't be called? QMP clients don't expect the QMP socket to be closed except when using the 'quit' command. > > > > > * be unable to finish machine initialization because of > > > > chdir("/"), change_root(), or change_process_uid(). > > > this one really no go. > > > I see 2 options here, > > > > > > * move init code that opens files to early stage (before preconfig monitor) > > > or split it to open files early. > > > (I've spotted several obvious places fwcfg/vnc/replay_start/migration) > > > but there might be code somewhere in callbacks that would do it too, > > > so it rather risky to go this route. > > > (I'd do this anyways one place at the time using sanitizing > > > initialization sequence pretext.) > > > > We might have QMP commands that take file paths as input, so is > > this really an option? > I'd think that in future we would want to enable object_add in preconfig > to create backends at runtime, so yes we can't do chroot at this point > > > > > * split out signaling part that tells parent process to exit into > > > separate helper that's called once before/from main_loop(). > > > This option seems low risk and additionally error output to > > > stderr will work as it does currently (until os_setup_post()) > > > > My assumption is that separating the chdir()/stdout/stderr logic > > from the fork/daemonize/exit steps wouldn't be possible without > > breaking expectations about -daemonize. > it's already separated and that's what creates one side of problem. Is it? Right now '$QEMU -daemonize' will never call exit(0) before the child process it spawned did the chdir()/stdout/stderr/etc trick. > What I suggest is to leave it as is and move out only > len = write(daemon_pipe, &status, 1); > part of os_setup_post() to sync with parent process. That shouldn't > affect daemonizing flow on QEMU side and would let libvirt reuse parent's > exit as sync point to detect moment when monitor is available. > (patch is in testing, I'll post it tomorrow if it doesn't break tests) This will affect the daemonizing flow, won't it? It will make QEMU exit(0) before the child does the chdir()/stderr/stdout/etc cleanup. A well-behaved daemon shouldn't do this. This is probably not a problem for libvirt (which only uses -daemonize as a sync point for QMP), but possibly a problem for other users of -daemonize. > > In worst case if we can't do the later in QEMU, mgmt would have to cope with > monitor in preconfig mode without relying on parent exit(0) sync point. > (a typical daemon would fork/chroot and co in one place and clients would use > other means to detect socket availability other than watching parent process > exiting) Do we really need to make -daemonize and -preconfig work together? libvirt uses -daemonize only for its initial capability probing, which shouldn't require -preconfig at all. Even on that case, I wonder why libvirt doesn't simply create a server socket and waits for QEMU to connect instead of using -daemonize as a sync point. -- Eduardo

5 10