- Devel - libvirt List Archives

[libvirt] [PATCH] virNetClientStreamQueuePacket: Set st->incomingEOF on the end of stream
by Michal Privoznik 07 Jun '17

07 Jun '17

While reworking client side of streams, I had to postpone payload decoding so that stream holes and stream data can be distinguished in virNetClientStreamRecvPacket. That's merely what 18944b7aea46d does. However, I accidentally removed one important bit: when server sends us an empty STREAM packet (with no payload) - meaning end of stream - st->incomingEOF flag needs to be set. It used to be before I touched the code. After I removed it, virNetClientStreamRecvPacket will try to fetch more data from the stream, but it will never come. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Thanks to Martin who helped me debug this. src/rpc/virnetclientstream.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/rpc/virnetclientstream.c b/src/rpc/virnetclientstream.c index a9bf271dc..54729c84f 100644 --- a/src/rpc/virnetclientstream.c +++ b/src/rpc/virnetclientstream.c @@ -278,6 +278,15 @@ int virNetClientStreamQueuePacket(virNetClientStreamPtr st, VIR_DEBUG("Incoming stream message: stream=%p message=%p", st, msg); + if (msg->bufferLength == msg->bufferOffset) { + /* No payload means end of the stream. */ + virObjectLock(st); + st->incomingEOF = true; + virNetClientStreamEventTimerUpdate(st); + virObjectUnlock(st); + return 0; + } + /* Unfortunately, we must allocate new message as the one we * get in @msg is going to be cleared later in the process. */ -- 2.13.0

2 2

[libvirt] [PATCH] virDomainNetDefParseXML: Fix typo
by Michal Privoznik 07 Jun '17

07 Jun '17

In 9cb891141c we've introduced some logic to clearing suggested macvtap/macvlan ifnames. The logic consists of comparing ifname string with strings that libvirt would generate. However, due to a typo only VIR_NET_GENERATED_MACVTAP_PREFIX was compared. Twice. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed as trivial. src/conf/domain_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 2e2e7334a..3e884225b 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -10074,7 +10074,7 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, if (ifname && flags & VIR_DOMAIN_DEF_PARSE_INACTIVE && (STRPREFIX(ifname, VIR_NET_GENERATED_MACVTAP_PREFIX) || - STRPREFIX(ifname, VIR_NET_GENERATED_MACVTAP_PREFIX))) { + STRPREFIX(ifname, VIR_NET_GENERATED_MACVLAN_PREFIX))) { VIR_FREE(ifname); } -- 2.13.0

1 0

[libvirt] [PATCHv2 00/15] Allow virtio devices to use vIOMMU
by Ján Tomko 07 Jun '17

07 Jun '17

https://bugzilla.redhat.com/show_bug.cgi?id=1283251 Ján Tomko (15): conf: eliminate monster condition in virDomainControllerDefFormat virDomainControllerDefFormat: do not mix attributes and subelements conf: add device_iotlb attribute to iommu qemu: format device-iotlb on intel-iommu command line qemuxml2xmltest: add virtio-options test Add virtio-related options to interfaces add virtio-related options to memballoon Add virtio-related options to disks Add virtio-related options to controllers Add virtio-related options to filesystems Add virtio-related options to rng devices Add virtio-related options to video Add virtio-related options to input devices qemuxml2argvtest: add virtio-options test case qemu: format virtio-related options on the command line docs/formatdomain.html.in | 87 ++++++++ docs/schemas/domaincommon.rng | 40 ++++ src/conf/domain_conf.c | 224 ++++++++++++++++++--- src/conf/domain_conf.h | 27 +++ src/qemu/qemu_capabilities.c | 15 +- src/qemu/qemu_capabilities.h | 5 + src/qemu/qemu_command.c | 69 +++++++ tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 3 + .../qemuxml2argv-intel-iommu-device-iotlb.args | 19 ++ .../qemuxml2argv-intel-iommu-device-iotlb.xml | 31 +++ .../qemuxml2argv-virtio-options.args | 57 ++++++ .../qemuxml2argv-virtio-options.xml | 104 ++++++++++ tests/qemuxml2argvtest.c | 18 ++ .../qemuxml2xmlout-intel-iommu-device-iotlb.xml | 1 + .../qemuxml2xmlout-virtio-options.xml | 104 ++++++++++ tests/qemuxml2xmltest.c | 2 + 16 files changed, 772 insertions(+), 34 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-intel-iommu-device-iotlb.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-intel-iommu-device-iotlb.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-options.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-options.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-intel-iommu-device-iotlb.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-options.xml -- 2.10.2

2 33

[libvirt] Remotable Libvirt
by Peter 07 Jun '17

07 Jun '17

Hi Everyone, We are working towards building on the virtualization management functionality in cockpit (http://cockpit-project.org/) and wanted to get some feedback on the best way to integrate with libvirt. As a quick overview, cockpit aims to talk to existing remotable system APIs. Usually these API’s take the form of dbus, REST or executable commands. The majority of cockpit is implemented in javascript. There is no cockpit backend that knows how to change a hostname for example. The cockpit backend knows how to handle a dbus payload. The javascript running in the users browser knows how to use the systemd dbus API at org.freedesktop.hostname1 to manage the system hostname. Right now some of the basics have been implemented by spawning commands on the system. This isn't ideal because it involves parsing / screen scraping output and doesn't support receiving events so we have to poll (ei run the command again) to keep the UI up to date. As far as I know libvirt doesn't currently have a remoteable API. It does have a daemon that communicates with clients via a XDR RPC. (https://libvirt.org/internals/rpc.html) However from what I'm hearing the RPC is considered an internal implementation and shouldn't be used by external applications. Is that still the case? Is there any chance of getting talking the daemon directly using the XDR standard for a subset of methods blessed as part of the externally supported API? An alternative is to implement a standards based remotable API, using something like dbus or REST, that can be used by external applications. I imagine that this would be at a bit of a higher level than the current RPC and contain at least some of the logic around the actions it performs rather than being a direct passthrough to the daemon. Of course that is a pretty big undertaking and would, in my opinion, only be worth it if there is broader interest in the community and use cases beyond what cockpit would like to.

10 23

[libvirt] [PATCH v2] qemu: Fix serial stub console allocation
by Erik Skultety 07 Jun '17

07 Jun '17

When adding the aliased serial stub console, the structure wasn't properly allocated (VIR_ALLOC instead of virDomainChrDefNew) which then resulted in SIGSEGV in virDomainChrSourceIsEqual during a serial device coldplug. https://bugzilla.redhat.com/show_bug.cgi?id=1434278 Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- src/qemu/qemu_hotplug.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 4a7d99725..6701bd9bc 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1802,15 +1802,17 @@ qemuDomainChrPreInsert(virDomainDefPtr vmdef, if (virDomainChrPreAlloc(vmdef, chr) < 0) return -1; - /* Due to some crazy backcompat stuff, the first serial device is an alias - * to the first console too. If this is the case, the definition must be - * duplicated as first console device. */ + /* Due to historical reasons, the first console is an alias to the + * first serial device (if such exists). If this is the case, we need to + * create an object for the first console as well. + */ if (vmdef->nserials == 0 && vmdef->nconsoles == 0 && chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL) { if (!vmdef->consoles && VIR_ALLOC(vmdef->consoles) < 0) return -1; - if (VIR_ALLOC(vmdef->consoles[0]) < 0) { + /* We'll be dealing with serials[0] directly, so NULL is fine here. */ + if (!(vmdef->consoles[0] = virDomainChrDefNew(NULL))) { VIR_FREE(vmdef->consoles); return -1; } @@ -1841,7 +1843,7 @@ qemuDomainChrInsertPreAllocCleanup(virDomainDefPtr vmdef, /* Remove the stub console added by qemuDomainChrPreInsert */ if (vmdef->nserials == 0 && vmdef->nconsoles == 1 && chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL) { - VIR_FREE(vmdef->consoles[0]); + virDomainChrDefFree(vmdef->consoles[0]); VIR_FREE(vmdef->consoles); vmdef->nconsoles = 0; } -- 2.13.0

2 2

[libvirt] [PATCH v2 00/20] Fix regression caused by recent CPU driver changes
by Jiri Denemark 07 Jun '17

07 Jun '17

https://bugzilla.redhat.com/show_bug.cgi?id=1441662 when I was enhancing libvirt's guest CPU configuration code to be able to really ensure stable guest CPU ABI, I added a new attribute //cpu/@check which is nicely backward compatible... an old libvirt will just ignore it. However, even if check='full' will be ignored, an old libvirt will still see the updated CPU definition (features added or removed by the hypervisor will be shown there). And because we need QEMU 2.9.0 to check what features are going to be added or removed before we actually start the domain, migrating such domain to an older libvirt or QEMU may fail if QEMU enables a feature which is not supported by the host CPU. Known features causing problems are, e.g., x2apic, hypervisor, and arat. To make things even worse, updating a CPU definition with the automatically added/removed features can be done since QEMU 1.5.0. Even save/restore or snapshot revert on a single host running new libvirt and QEMU < 2.9.0 is now affected by this regression. This series fixes the regression by storing the original guest CPU definition in migratable XML and sending the updated CPU in a side channel (a migration or save cookie). Version 2: - see individual patches for changes Jiri Denemark (20): conf: Make error reporting in virCPUDefIsEqual optional conf: Refactor virCPUDefParseXML conf: Make virDomainSnapshotDefFormat easier to read conf: Pass xmlopt to virDomainSnapshotDefFormat qemu: Rename xml_len in virQEMUSaveHeader as data_len qemu: Fix memory leaks in qemuDomainSaveImageOpen qemu: Introduce virQEMUSaveData{New,Free} qemu: Introduce virQEMUSaveDataFinish qemu: Refactor qemuDomainSaveHeader qemu: Introduce virQEMUSaveData structure conf: Introduce virSaveCookie conf: Add save cookie callbacks to xmlopt qemu: Implement virSaveCookie object and callbacks qemu: Store save cookie in save images and snapshots qemu: Remember CPU def from domain start qemu: Report the original CPU in migratable xml qemu: Always send persistent XML during migration qemu: Send updated CPU in migration cookie qemu: Store updated CPU in save cookie qemu: Use updated CPU when starting QEMU if possible docs/formatsnapshot.html.in | 6 + docs/schemas/domainsnapshot.rng | 7 + po/POTFILES.in | 1 + src/Makefile.am | 1 + src/bhyve/bhyve_domain.c | 2 +- src/conf/cpu_conf.c | 192 ++++++++-------- src/conf/cpu_conf.h | 12 +- src/conf/domain_conf.c | 30 ++- src/conf/domain_conf.h | 7 +- src/conf/snapshot_conf.c | 40 +++- src/conf/snapshot_conf.h | 3 + src/conf/virsavecookie.c | 144 ++++++++++++ src/conf/virsavecookie.h | 62 +++++ src/cpu/cpu.c | 5 +- src/esx/esx_driver.c | 2 +- src/libvirt_private.syms | 10 + src/libxl/libxl_conf.c | 2 +- src/lxc/lxc_conf.c | 2 +- src/openvz/openvz_driver.c | 2 +- src/phyp/phyp_driver.c | 2 +- src/qemu/qemu_capabilities.c | 2 +- src/qemu/qemu_conf.c | 3 +- src/qemu/qemu_domain.c | 207 +++++++++++++++-- src/qemu/qemu_domain.h | 22 ++ src/qemu/qemu_driver.c | 468 ++++++++++++++++++++++++++------------ src/qemu/qemu_migration.c | 18 +- src/qemu/qemu_migration_cookie.c | 31 ++- src/qemu/qemu_migration_cookie.h | 5 + src/qemu/qemu_process.c | 37 ++- src/qemu/qemu_process.h | 2 + src/security/virt-aa-helper.c | 2 +- src/test/test_driver.c | 3 +- src/uml/uml_driver.c | 2 +- src/vbox/vbox_common.c | 6 +- src/vmware/vmware_driver.c | 3 +- src/vmx/vmx.c | 2 +- src/vz/vz_driver.c | 3 +- src/xen/xen_driver.c | 2 +- src/xenapi/xenapi_driver.c | 2 +- tests/bhyveargv2xmltest.c | 2 +- tests/cputest.c | 5 +- tests/domainsnapshotxml2xmltest.c | 1 + tests/testutils.c | 2 +- 43 files changed, 1047 insertions(+), 315 deletions(-) create mode 100644 src/conf/virsavecookie.c create mode 100644 src/conf/virsavecookie.h -- 2.13.0

2 30

[libvirt] [PATCH go-xml] 1,rename DomainInterfaceBoot to DomainDeviceBoot; 2,support disk boot order
by zhenwei.pi 07 Jun '17

07 Jun '17

--- domain.go | 5 +++-- domain_test.go | 6 +++++- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/domain.go b/domain.go index 1d91dc3..7d8f6d6 100644 --- a/domain.go +++ b/domain.go @@ -98,6 +98,7 @@ type DomainDisk struct { ReadOnly *DomainDiskReadOnly `xml:"readonly"` Shareable *DomainDiskShareable `xml:"shareable"` Address *DomainAddress `xml:"address"` + Boot *DomainDeviceBoot `xml:"boot"` } type DomainFilesystemDriver struct { @@ -171,7 +172,7 @@ type DomainInterfaceLink struct { State string `xml:"state,attr"` } -type DomainInterfaceBoot struct { +type DomainDeviceBoot struct { Order uint `xml:"order,attr"` } @@ -193,7 +194,7 @@ type DomainInterface struct { Target *DomainInterfaceTarget `xml:"target"` Alias *DomainInterfaceAlias `xml:"alias"` Link *DomainInterfaceLink `xml:"link"` - Boot *DomainInterfaceBoot `xml:"boot"` + Boot *DomainDeviceBoot `xml:"boot"` Script *DomainInterfaceScript `xml:"script"` Driver *DomainInterfaceDriver `xml:"driver"` Address *DomainAddress `xml:"address"` diff --git a/domain_test.go b/domain_test.go index b83d4ae..3d015c7 100644 --- a/domain_test.go +++ b/domain_test.go @@ -87,6 +87,9 @@ var domainTestData = []struct { Bus: "virtio", }, Serial: "fishfood", + Boot: &DomainDeviceBoot{ + Order: 1, + }, }, DomainDisk{ Type: "block", @@ -189,6 +192,7 @@ var domainTestData = []struct { ` <source file="/var/lib/libvirt/images/demo.qcow2"></source>`, ` <target dev="vda" bus="virtio"></target>`, ` <serial>fishfood</serial>`, + ` <boot order="1"></boot>`, ` </disk>`, ` <disk type="block" device="disk">`, ` <driver name="qemu" type="raw"></driver>`, @@ -710,7 +714,7 @@ var domainTestData = []struct { Link: &DomainInterfaceLink{ State: "up", }, - Boot: &DomainInterfaceBoot{ + Boot: &DomainDeviceBoot{ Order: 1, }, Driver: &DomainInterfaceDriver{ -- 2.7.4

2 1

[libvirt] libvirt binding for Rust
by Sahid Orentino Ferdjaoui 07 Jun '17

07 Jun '17

Hello, I started a work on a libvirt binding for Rust [0]. Not all of the API is implemeted but I think it's now in a usable state. https://docs.rs/crate/virt https://github.com/sahid/libvirt-rs The code is licensed under LGPL-2.1, it's tested by a CI running libvirt 1.2.0, 2.5.0, 3.3.0. There are unit tests, integration tests and some examples to exercise the code (some parts are still not covered) I also have checked the code with valgrind to avoid any memory leaks. https://travis-ci.org/sahid/libvirt-rs Do you think that we can consider it ready to be hosted by libvirt.org GIT server ? That could help to get new contributors also interested by Rust and improve the code and coverage of the API. Thanks, s.

3 4

[libvirt] More CI options
by Martin Kletzander 07 Jun '17

07 Jun '17

Since the addition of Travis CI builds, there is some more progress towards more testing. I was just wondering if anyone was thinking about (or is already working on) some settings for other CI environments as well. For example if configured AppVeyor, we could have MSVC builds as well. And there are more of those, I didn't compare all of them, but the more environments we have, the more build failures we might catch. Or even test failures, maybe. Martin

2 3

[libvirt] [PATCH 0/2] qemu: Allow block-copy for persistent VMs under same conditions as for transient
by Peter Krempa 07 Jun '17

07 Jun '17

Peter Krempa (2): qemu: Conditionally allow block-copy for persistent domains virsh: Add support for VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB include/libvirt/libvirt-domain.h | 3 +++ src/libvirt-domain.c | 3 +++ src/qemu/qemu_driver.c | 9 ++++++--- tools/virsh-domain.c | 10 +++++++++- tools/virsh.pod | 4 ++++ 5 files changed, 25 insertions(+), 4 deletions(-) -- 2.12.2

2 4