- Devel - libvirt List Archives

[libvirt] missing libvirt-sock after compile and install libvirt 1.2.6
by Yuanzhen Gu 30 Jul '14

30 Jul '14

Hi folks, I compiled and installed libvirt latest version 1.2.6, based on this tutorial, http://blog.scottlowe.org/2012/11/05/compiling-libvirt-1-0-0-on-ubuntu-12-0… I have compiled qemu and installed too, and make a symbolic link to /usr/bin/qemu-system-x86_64 but my question is even I launch a vm in qemu, $virsh list showed nothing, further more, 1) if I use virtual machine manager, it get connection failiure, due to socket to '/var/run/libvirt/libvirt-sock'; No such file of dirctory. 2). there is missing libvirt-bin under /etc/init.d/, after compile and installed libvirt 1.2.6 3). I tried to start libvirtd daemon, sudo /usr/sbin/libvirtd/start shows "/usr/sbin/libvirtd: unexpected, non-option, command line arguments" 4). I've checked /var/log/libvirt/libvirtd.log which shows cannot find suitable emulator for x86_64 I've stuck here for whole afternoon yesterday, any help or suggestion is highly appreciated, thanks a lot in advance ! Best, Yuanzhen

3 4

[libvirt] [PATCH] docs: bhyve: document recent changes
by Roman Bogorodskiy 30 Jul '14

30 Jul '14

- mention that one disk and one network limitation is no longer actual for 1.2.6 and newer - add 'cdrom' device to the sample domain XML --- docs/drvbhyve.html.in | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in index e75eb83..9a97c57 100644 --- a/docs/drvbhyve.html.in +++ b/docs/drvbhyve.html.in @@ -42,9 +42,10 @@ in this sample domain XML. -A limitation that is not obvious from this sample domain XML is that currently only a -single network and a single disk device are supported for each domain (as PCI slot allocation code -in libvirt bhyve driver is yet to be implemented). +Note: an older versions of the libvirt bhyve driver had a limitation that only a +single network and a single disk device were supported for each domain. However, +since 1.2.6 the libvirt bhyve driver supports +up to 31 PCI devices. <pre> @@ -71,6 +72,11 @@ in libvirt bhyve driver is yet to be implemented). <source file='/path/to/bhyve_freebsd.img'/> <target dev='hda' bus='sata'/> </disk> + <disk type='file' device='cdrom'> + <driver name='file' type='raw'/> + <source file='/path/to/cdrom.iso'/> + <target dev='hdc' bus='sata'/> + </disk> <interface type='bridge'> <model type='virtio'/> <source bridge="virbr0"/> -- 1.9.0

2 2

[libvirt] [PATCH v6 0/2] turn on active commit
by Eric Blake 30 Jul '14

30 Jul '14

v5 was here, and got tentative ACKs: https://www.redhat.com/archives/libvir-list/2014-July/msg01414.html the only change is some reordering of logic in patch 2/2 (the former 4/4) to make sure that even for a super-fast commit where the event d occurs before the API call regains the lock that the event is correct. I'm still unsure whether to count this as a bug fix to a partial new feature and include it in 1.2.7, or defer it to 1.2.8. If we want it in this release, then getting it in before rc2 would be the nicest. Also at: http://repo.or.cz/w/libvirt/ericb.git/shortlog/refs/heads/gluster or git checkout git://repo.or.cz/libvirt/ericb.git gluster Eric Blake (2): blockcommit: track job type in xml blockcommit: turn on active commit docs/formatdomain.html.in | 15 ++++--- docs/schemas/domaincommon.rng | 13 ++++++ src/conf/domain_conf.c | 33 ++++++++++++++- src/conf/domain_conf.h | 1 + src/qemu/qemu_driver.c | 48 +++++++++++++++++++--- src/qemu/qemu_process.c | 39 +++++++++++++++++- .../qemuxml2argv-disk-active-commit.xml | 37 +++++++++++++++++ .../qemuxml2argvdata/qemuxml2argv-disk-mirror.xml | 6 +-- .../qemuxml2xmlout-disk-mirror-old.xml | 4 +- tests/qemuxml2xmltest.c | 1 + 10 files changed, 179 insertions(+), 18 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-active-commit.xml -- 1.9.3

3 6

[libvirt] [RFC] Adding a "none" model for video cards
by Jean-Baptiste Rouault 30 Jul '14

30 Jul '14

Hi, I'm trying to run vexpress-a9 virtual machines (armv7l architecture) using libvirt. The vexpress-a9 doesn't support vga cards, but libvirt adds a video "cirrus" video card when there is a "graphics" element in the domain xml. This prevents the domain from booting. At the moment, the only workaround I found is to add the following to my xml file : <qemu:commandline> <qemu:arg value='-vga'/> <qemu:arg value='none'/> </qemu:commandline> What do you think about adding a "none" model type for video cards ? I know it is a bit strange to declare a video card in order to have none... I don't know the QEMU driver well, but maybe this could be handled by the driver ? i.e. "no VGA card when the machine is vexpress-a9". Regards, Jean-Baptiste -- Jean-Baptiste ROUAULT R&D Engineer - diateam : Architectes de l'information Phone : +33 (0)2 98 050 050 Fax : +33 (0)2 98 050 051

2 1

[libvirt] [PATCH] Domain config: write <features/> if some capabilities are set.
by Cédric Bosdonnat 30 Jul '14

30 Jul '14

If all features are set to default (including the capabilities policy), but some capabilities are toggled, we need to output the <features> element when formatting the config. --- src/conf/domain_conf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 2a8cdeb..421a44a 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -17860,7 +17860,8 @@ virDomainDefFormatInternal(virDomainDefPtr def, break; } - if (i != VIR_DOMAIN_FEATURE_LAST) { + if (i != VIR_DOMAIN_FEATURE_LAST || + virDomainDefHasCapabilitiesFeatures(def)) { virBufferAddLit(buf, "<features>\n"); virBufferAdjustIndent(buf, 2); -- 1.8.4.5

3 2

[libvirt] [RFC] Memory hotplug for qemu guests and the relevant XML parts
by Peter Krempa 30 Jul '14

30 Jul '14

Hi, qemu recently added support for memory hotplug (hot unplug will arrive later) since commit ~ bef3492d1169a54c966cecd0e0b1dd25e9341582 in qemu.git. For the hotplug to work the VM needs to be started with a certain number of "dimm" slots for plugging virtual memory modules. The memory of the VM at startup has to occupy at least one of the slots. Later on the management can decide to plug more memory to the guest by inserting a virtual memory module into the guest. For representing this in libvirt I'm thinking of using the <devices> section of our domain XML where we'd add a new device type: <memory type="ram"> <source .../>  <target .../>  <address type="acpi-dimm" slot="1"/> </memory> type="ram" to denote that we are adding RAM memory. This will allow possible extensions for example to add a generic pflash (type="flash", type="rom") device or other memory type mapped in the address space. To enable this infrastructure qemu needs two command line options supplied, one setting the maximum amount of supportable memory and the second one the maximum number of memory modules (capped at 256 due to ACPI). The current XML format for specifying memory looks like this: <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> I'm thinking of adding following attributes to the memory element: <memory slots='16' max-memory='1' max-memory-unit='TiB'/> This would then be updated to the actual size after summing sizes of the memory modules to: <memory slots='16' max-memory='1' max-memory-unit='TiB'/> unit='MiB'>512</memory> This would also allow a possibility to specify the line above and libvirt would then add a memory module holding the whole guest memory. Representing the memory module as a device will then allow us to use the existing hot(un)plug APIs to do the operations on the actual VM. For the ram memory type the source and target elements will allow to specify the following option. For backing the guest with normal memory: <source type="ram" size="500" unit="MiB" host-node="2"/> For hugepage-backed guest: <source type="hugepage" page-size="2048" count="1024" node="1"/> Note: node attribute target's host numa node and is optional. And possibly others possibly for the rom/flash types: <source type="file" path="/asdf"/> For targetting the RAM module the target element could have the following format: <target model="dimm" node='2' address='0xdeadbeef'/> "node" determines the guest numa node to connect the memory "module" to. The attribute is optional for non-numa guests or node 0 is assumed. "address" determines the address in the guest's memory space where the memory will be mapped. This is optional and not recommended being set by the user (except for special cases). For expansion the model="pflash" device may be added. For migration the target VM needs to be started with the hotplugged modules already specified on the command line, which is in line how we treat devices currently. My suggestion above contrasts with the approach Michal and Martin took when adding the numa and hugepage backing capabilities as they describe a node while this describes the memory device beneath it. I think those two approaches can co-exist whilst being mutually-exclusive. Simply when using memory hotplug, the memory will need to be specified using the memory modules. Non-hotplug guests could use the approach defined originally. That concludes my thoughts on this subject, but I'm open for discussion or other approach (I didn't start implementation yet). Thanks Peter

3 10

[libvirt] [PATCH] docs: fix an incorrect example for memoryBacking
by Chen Hanxiao 30 Jul '14

30 Jul '14

commit 136ad49740f017aabcac48d02d2df6ab7b0195e9 forgot to add an end-tags for hugepages. Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> --- docs/formatdomain.html.in | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 2f0be20..df3fc4a 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -620,6 +620,7 @@ <hugepages> <page size="1" unit="G" nodeset="0-3,5"/> <page size="2" unit="M" nodeset="4"/> + </hugepages> <nosharepages/> <locked/> </memoryBacking> -- 1.9.0

2 1

[libvirt] [PATCH 0/2] (for 1.2.7) network: Bring netdevs online later
by Matthew Rosato 29 Jul '14

29 Jul '14

The following patchset introduces code to defer setting netdevs online (and therefore registering MACs) until right before beginning guest CPU execution. The first patch introduces some infrastructure changes in preparation of the actual function added in the 2nd patch. Associated BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1081461 Changes since RFC: * Add a separate patch to introduce a flags field for macvlan/macvtap creation. * Use macvlan/tap IFUP flags to skip virNetDevSetOnline (for qemu only). * Add hotplug support. * For macvlan, save the current virNetDevVPortProfileOp in virDomainNetDef during qemuPhysIfaceConnect. As Laine mentioned, could use this field in a future patch to eliminate passing virNetDevVPortProfileOp everywhere. * Add qemu_interface.c and qemu_interface.h to encapsulate new functions. Matthew Rosato (2): util: Introduce flags field for macvtap creation network: Bring netdevs online later src/Makefile.am | 1 + src/conf/domain_conf.h | 2 ++ src/lxc/lxc_process.c | 3 +- src/qemu/qemu_command.c | 9 ++++-- src/qemu/qemu_hotplug.c | 7 +++++ src/qemu/qemu_interface.c | 65 +++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_interface.h | 33 ++++++++++++++++++++++ src/qemu/qemu_process.c | 4 +++ src/util/virnetdevmacvlan.c | 32 +++++++++++++-------- src/util/virnetdevmacvlan.h | 10 ++++++- 10 files changed, 150 insertions(+), 16 deletions(-) create mode 100644 src/qemu/qemu_interface.c create mode 100644 src/qemu/qemu_interface.h -- 1.7.9.5

3 9

[libvirt] [python PATCH] spec: Reorganize to satisfy buggy spectool
by Jiri Denemark 29 Jul '14

29 Jul '14

From: Jiri Denemark <Jiri.Denemark(a)gmail.com> spectool parses a specfile and strips everything but a preamble. However, if the first section is preceded by %if clause, it keeps it there which then makes rpmbuild complain about unmatched %if. Let's make the buggy tool happy by moving sections around so that the first one is not in any conditional. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt-python.spec.in | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/libvirt-python.spec.in b/libvirt-python.spec.in index b51571e..8a21003 100644 --- a/libvirt-python.spec.in +++ b/libvirt-python.spec.in @@ -22,14 +22,6 @@ BuildRequires: python3-nose BuildRequires: python3-lxml %endif -%if %{with_python3} -%package -n libvirt-python3 -Summary: The libvirt virtualization API python3 binding -Url: http://libvirt.org -License: LGPLv2+ -Group: Development/Libraries -%endif - # Don't want provides for python shared objects %{?filter_provides_in: %filter_provides_in %{python_sitearch}/.*\.so} %{?filter_setup} @@ -41,6 +33,12 @@ supplied by the libvirt library to use the virtualization capabilities of recent versions of Linux (and other OSes). %if %{with_python3} +%package -n libvirt-python3 +Summary: The libvirt virtualization API python3 binding +Url: http://libvirt.org +License: LGPLv2+ +Group: Development/Libraries + %description -n libvirt-python3 The libvirt-python package contains a module that permits applications written in the Python programming language to use the interface -- 2.0.2

2 1

[libvirt] [PATCH] storage: Refresh storage pool after upload
by John Ferlan 29 Jul '14

29 Jul '14

https://bugzilla.redhat.com/show_bug.cgi?id=1072653 Upon successful upload of a volume, the target volume and storage pool were not updated to reflect any changes as a result of the upload. Make use of the existing stream close callback mechanism to force a backend pool refresh to occur once the stream closes. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/libvirt.c | 8 +++++ src/libvirt_private.syms | 1 + src/storage/storage_driver.c | 78 ++++++++++++++++++++++++++++++++++++++++++++ tools/virsh.pod | 3 ++ 4 files changed, 90 insertions(+) diff --git a/src/libvirt.c b/src/libvirt.c index 143d319..992e4f2 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -13960,6 +13960,14 @@ virStorageVolDownload(virStorageVolPtr vol, * detect any errors. The results will be unpredictable if * another active stream is writing to the storage volume. * + * When the data stream is closed whether the upload is successful + * or not the target storage pool will be refreshed to reflect pool + * and volume changes as a result of the upload. Depending on + * the target volume storage backend and the source stream type + * for a successful upload, the target volume may take on the + * characteristics from the source stream such as format type, + * capacity, and allocation. + * * Returns 0, or -1 upon error. */ int diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index b1fb7c9..7ef68a1 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -825,6 +825,7 @@ virFDStreamCreateFile; virFDStreamOpen; virFDStreamOpenFile; virFDStreamOpenPTY; +virFDStreamSetInternalCloseCb; # libvirt_internal.h diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index efbe5ff..5fd5514 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -59,6 +59,12 @@ static virStorageDriverStatePtr driverState; static int storageStateCleanup(void); +typedef struct _virStorageVolStreamInfo virStorageVolStreamInfo; +typedef virStorageVolStreamInfo *virStorageVolStreamInfoPtr; +struct _virStorageVolStreamInfo { + char *pool_name; +}; + static void storageDriverLock(virStorageDriverStatePtr driver) { virMutexLock(&driver->lock); @@ -1956,6 +1962,52 @@ storageVolDownload(virStorageVolPtr obj, } +/** + * Frees opaque data provided for the stream closing callback + * + * @opaque Data to be freed. + */ +static void virStorageVolFDStreamCloseCbFree(void *opaque) +{ + virStorageVolStreamInfoPtr cbdata = opaque; + + VIR_FREE(cbdata->pool_name); + VIR_FREE(cbdata); +} + +/** + * Callback being called if a FDstream is closed. Frees device entries + * from data structures and removes lockfiles. + * + * @st Pointer to stream being closed. + * @opaque Domain's device information structure. + */ +static void virStorageVolFDStreamCloseCb(virStreamPtr st ATTRIBUTE_UNUSED, + void *opaque) +{ + + virStorageVolStreamInfoPtr cbdata = opaque; + virStoragePoolObjPtr pool = NULL; + virStorageBackendPtr backend; + + storageDriverLock(driverState); + if (!(pool = virStoragePoolObjFindByName(&driverState->pools, + cbdata->pool_name))) + goto cleanup; + + if (!(backend = virStorageBackendForType(pool->def->type))) + goto cleanup; + + virStoragePoolObjClearVols(pool); + if (backend->refreshPool(NULL, pool) < 0) + VIR_DEBUG("Failed to refresh storage pool"); + + cleanup: + if (pool) + virStoragePoolObjUnlock(pool); + storageDriverUnlock(driverState); +} + static int storageVolUpload(virStorageVolPtr obj, virStreamPtr stream, @@ -1966,6 +2018,7 @@ storageVolUpload(virStorageVolPtr obj, virStorageBackendPtr backend; virStoragePoolObjPtr pool = NULL; virStorageVolDefPtr vol = NULL; + virStorageVolStreamInfoPtr cbdata = NULL; int ret = -1; virCheckFlags(0, -1); @@ -1996,11 +2049,36 @@ storageVolUpload(virStorageVolPtr obj, goto cleanup; } + /* If we have a refreshPool, use the callback routine in order to + * refresh the pool after the volume upload stream closes. This way + * we make sure the volume and pool data are refreshed without user + * interaction and we can just lookup the backend in the callback + * routine in order to call the refresh API. + */ + if (backend->refreshPool) { + if (VIR_ALLOC(cbdata) < 0 || + VIR_STRDUP(cbdata->pool_name, pool->def->name) < 0) + goto cleanup; + } + ret = backend->uploadVol(obj->conn, pool, vol, stream, offset, length, flags); + /* Add cleanup callback - call after uploadVol since the stream + * is then fully set up + */ + if (cbdata) { + virFDStreamSetInternalCloseCb(stream, + virStorageVolFDStreamCloseCb, + cbdata, + virStorageVolFDStreamCloseCbFree); + cbdata = NULL; + } + cleanup: virStoragePoolObjUnlock(pool); + if (cbdata) + virStorageVolFDStreamCloseCbFree(cbdata); return ret; } diff --git a/tools/virsh.pod b/tools/virsh.pod index 849ae31..e377df9 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -2981,6 +2981,9 @@ of the amount of data to be uploaded. A negative value is interpreted as an unsigned long long value to essentially include everything from the offset to the end of the volume. An error will occur if the I<local-file> is greater than the specified length. +See the description for the libvirt virStorageVolUpload API for details +regarding possible target volume and pool changes as a result of the +pool refresh when the upload is attempted. =item B<vol-download> [I<--pool> I<pool-or-uuid>] [I<--offset> I<bytes>] [I<--length> I<bytes>] I<vol-name-or-key-or-path> I<local-file> -- 1.9.3

3 7