- Devel - libvirt List Archives

[libvirt] Hyervisor Features elements
by bancfc＠openmailbox.org 15 Sep '14

15 Sep '14

Hello. Under Hypevisor Features for Domain elements, I noticed new features being added like <kvm> <hidden state='on'/> </kvm> Probably more will be added later I am guessing. -Is this a performance feature? -Can it also be applied to qemu only machine templates? (I don't use qemu only, but maintain templates for both that's the reason for asking)

2 1

[libvirt] [PATCH] storage: zfs: implement pool build and delete
by Roman Bogorodskiy 14 Sep '14

14 Sep '14

Provide an implementation for buildPool and deletePool operations for the ZFS storage backend. --- docs/schemas/storagepool.rng | 1 + src/storage/storage_backend_zfs.c | 57 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+) diff --git a/docs/schemas/storagepool.rng b/docs/schemas/storagepool.rng index 908cc11..da8e1f3 100644 --- a/docs/schemas/storagepool.rng +++ b/docs/schemas/storagepool.rng @@ -386,6 +386,7 @@ <element name='source'> <interleave> <ref name='sourceinfoname'/> + <ref name='sourceinfodev'/> </interleave> </element> </define> diff --git a/src/storage/storage_backend_zfs.c b/src/storage/storage_backend_zfs.c index d8201ac..9482706 100644 --- a/src/storage/storage_backend_zfs.c +++ b/src/storage/storage_backend_zfs.c @@ -325,6 +325,61 @@ virStorageBackendZFSDeleteVol(virConnectPtr conn ATTRIBUTE_UNUSED, return ret; } +static int +virStorageBackendZFSBuildPool(virConnectPtr conn ATTRIBUTE_UNUSED, + virStoragePoolObjPtr pool, + unsigned int flags) +{ + virCommandPtr cmd = NULL; + size_t i; + int ret = -1; + + virCheckFlags(0, -1); + + if (pool->def->source.ndevice == 0) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + "%s", _("missing source devices")); + return -1; + } + + cmd = virCommandNewArgList(ZPOOL, "create", + pool->def->source.name, NULL); + + for (i = 0; i < pool->def->source.ndevice; i++) + virCommandAddArg(cmd, pool->def->source.devices[i].path); + + if (virCommandRun(cmd, NULL) < 0) + goto cleanup; + + ret = 0; + + cleanup: + virCommandFree(cmd); + return ret; +} + +static int +virStorageBackendZFSDeletePool(virConnectPtr conn ATTRIBUTE_UNUSED, + virStoragePoolObjPtr pool, + unsigned int flags) +{ + virCommandPtr cmd = NULL; + int ret = -1; + + virCheckFlags(0, -1); + + cmd = virCommandNewArgList(ZPOOL, "destroy", + pool->def->source.name, NULL); + + if (virCommandRun(cmd, NULL) < 0) + goto cleanup; + + ret = 0; + + cleanup: + virCommandFree(cmd); + return ret; +} virStorageBackend virStorageBackendZFS = { .type = VIR_STORAGE_POOL_ZFS, @@ -333,6 +388,8 @@ virStorageBackend virStorageBackendZFS = { .refreshPool = virStorageBackendZFSRefreshPool, .createVol = virStorageBackendZFSCreateVol, .deleteVol = virStorageBackendZFSDeleteVol, + .buildPool = virStorageBackendZFSBuildPool, + .deletePool = virStorageBackendZFSDeletePool, .uploadVol = virStorageBackendVolUploadLocal, .downloadVol = virStorageBackendVolDownloadLocal, }; -- 2.0.2

2 3

[libvirt] Question : Configuring a VM with backing 1G huge pages across 2 NUMA nodes
by Vinod, Chegu 13 Sep '14

13 Sep '14

Hi Michal, 'have a kernel+qemu+libvirt setup with all recent upstream bits on a given host & was trying to configure a VM with backing 1G huge pages...spanning 2 NUMA nodes. The host had 3 1G huge pages on each of the 2 NUMA nodes : # cat /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages 3 # cat /sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages 3 And I had the following in the /etc/fstab hugetlbfs /hugepages_1G hugetlbfs pagesize=1GB 0 0 I added the following entries in the xml file for the 4G/4vcpu VM <memoryBacking> <hugepages> <page size='1048576' unit='KiB' nodeset='0'/> <page size='1048576' unit='KiB' nodeset='1'/> </hugepages> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <vcpupin vcpu='2' cpuset='8'/> <vcpupin vcpu='3' cpuset='9'/> </cputune> .... <numatune> <memory node="strict" nodeset="0-1"/> </numatune> .... <cpu> <numa> <cell id='0' cpus='0-1' memory='2097152'/> <cell id='1' cpus='2-3' memory='2097152'/> </numa> </cpu> The resulting qemu command looked like this : /usr/local/bin/qemu-system-x86_64 -name vm1 -S -machine pc-i440fx-2.2,accel=kvm,usb=off \ -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 \ -object memory-backend-file,prealloc=yes,mem-path=/hugepages_1G/libvirt/qemu,size=2048M,id=ram-node0,host-nodes=0-1,policy=bind -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 \ -object memory-backend-file,prealloc=yes,mem-path=/hugepages_1G/libvirt/qemu,size=2048M,id=ram-node1,host-nodes=0-1,policy=bind -numa node,nodeid=1,cpus=2-3,memdev=ram-node1 \ .... There were 3 1G pages available on each NUMA node on the host as shown above... and I noticed that the VM got backed by 3 1G pages from node0 and 1 1G page from node1. #cat /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/free_hugepages 0 # cat /sys/devices/system/node/node1/hugepages/hugepages-1048576kB/free_hugepages 2 Not sure if this was expected behavior given the options I specified in the xml file ? If yes...Is there some additional option to specify (in the XML file) such that only a given number of 1Gig huge pages per node are picked to back the VM (i.e. in the above case just 2 1G from each node) ? Thanks! Vinod

2 2

[libvirt] [RFC PATCHv2] network: try to eliminate default network conflict during package install
by Laine Stump 12 Sep '14

12 Sep '14

Sometimes libvirt is installed on a host that is already using the network 192.168.122.0/24. If the libvirt-daemon-config-network package is installed, this creates a conflict, since that package has been hard-coded to create a virtual network that also uses 192.168.122.0/24. In the past libvirt has attempted to warn of / remediate this situation by checking for conflicting routes when the network is started, but it turns out that isn't always useful (for example in the case that the *other* interface/network creating the conflict hasn't yet been started at the time libvirtd start its own networks). This patch attempts to catch the problem earlier - at install time. During the %post install script for libvirt-daemon-config-network, we use a case statement to look through the output of "ip route show" for a route that exactly matches 192.168.122.0/24, and if found we search for a similar route that *doesn't* match (e.g. 192.168.123.0/24). When we find an available route, we just replace all occurrences of "122" in the default.xml that is being created with the newly found 192.168 subnet. This could obviously be made more complicated - examine the template defaul.xml to automatically determine the existing network address and mask rather than hard coding it in the specfile, etc, but this scripting is simpler and gets the job done as long as we continue to use 192.168.122.0/24 in the template. (If anyone with mad bash skillz wants to suggest something to do that, by all means please do). This is intended to at least "further reduce" occurrence of the problems detailed in: https://bugzilla.redhat.com/show_bug.cgi?id=811967 --- Difference from V1: fixed some typos in the commit message as pointed out by Eric. Also switched from using comparison loops for route matching, to using a case statement as a low cost replacement for grep (again, as suggested by Eric). Unless there is an objection, I will push this patch later this afternoon so that we can try it out. In the off chance that it causes any disasters, we have plenty of time to revert before the next release :-) libvirt.spec.in | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index a6a58cf..90da0c2 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1728,8 +1728,37 @@ fi %if %{with_network} %post daemon-config-network if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; then + # see if the network used by default network creates a conflict, + # and try to resolve it + # NB: 192.168.122.0/24 is used in the default.xml template file; + # do not modify any of those values here without also modifying + # them in the template. + orig_sub=122 + sub=${orig_sub} + nl=' +' + routes="${nl}$(ip route show | cut -d' ' -f1)" + case ${routes} in + *"${nl}192.168.${orig_sub}.0/24${nl}"*) + # there was a match, so we need to look for an unused subnet + for new_sub in $(seq 123 254); do + case ${routes} in + *"${nl}192.168.${new_sub}.0/24${nl}"*) + ;; + *) + sub=$new_sub + break; + ;; + esac + done + ;; + *) + ;; + esac + UUID=`/usr/bin/uuidgen` - sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ + sed -e "s/${orig_sub}/${sub}/g" \ + -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ < %{_datadir}/libvirt/networks/default.xml \ > %{_sysconfdir}/libvirt/qemu/networks/default.xml ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml -- 1.9.3

2 1

[libvirt] Inconsistent behavior between x86_64 and ppc64 when creating guests with NUMA node placement
by Michael Turek 12 Sep '14

12 Sep '14

Hello all, I was recently trying out NUMA placement for my guests on both x86_64 and ppc64 machines. When booting a guest on the x86_64 machine, the following specs were valid (obviously, just notable excepts from the xml): <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <vcpu placement='static'>4</vcpu> ... <cpu> <topology sockets='4' cores='1' threads='1'/> <numa> <cell cpus='0-2' memory='6144'/> <cell cpus='3' memory='2048'/> </numa> </cpu> However, on ppc64 this causes the following error: error: Failed to create domain from sample_guest.xml error: internal error: early end of file from monitor: possible problem: 2014-09-11T18:44:25.502140Z qemu-system-ppc64: total memory for NUMA nodes (8388608) should equal RAM size (200000000) The 200000000 is actually 8192 MB in bytes and hexidecimal. This is apparently just an issue with the error message. The following specs work on ppc64: <cpu> <topology sockets='4' cores='1' threads='1'/> <numa> <cell cpus='0-2' memory='6291456'/> <cell cpus='3' memory='2097152'/> </numa> </cpu> Note that the memory for each cell is 6144*1024 and 2048*1024 respectively. The issue is that the memory size for each NUMA cell should be specified in KiB, not MB (http://libvirt.org/formatdomain.html#resPartition "|memory| specifies the node memory in kibibyte"). In short, it seems that specifying NUMA cell memory in MB works on x86_64 but not on ppc64. Does anyone have any insight to what's causing this, or if I'm misunderstanding something? Any help is appreciated, thank you! Regards, Mike Turek

1 1

[libvirt] [PATCH RFC] network: try to eliminate default network conflict during package install
by Laine Stump 12 Sep '14

12 Sep '14

Sometimes libvirt is installed on a host that is already using the network 192.168.122.0/24. If the libvirt-daemon-config-network package is installed, this creates a conflict, since that package has been hard-coded to create a virtual network that also uses 192.168.122.0/24. In the past libvirt has attempted to warn of / remediate this situation by checking for conflicting routes when the network is started, but it turns out that isn't always useful (for example in the case that the *other* interface/network creating the conflict hasn't yet been started at the time libvirtd start its owm networks). This patch attempts to catch the problem earlier - at install time. During the %post install for libvirt-daemon-config-network, we look through the output of "ip route show" for a route that exactly matches 192.1 68.122.0/24, and if found we search for a similar route that *doesn't* match (e.g. 192.168.123.0/24). When we find an available route, we just replace all occurences of "122" in the default.xml that is being created with ${new_sub}. This could obviously be made more complicated - automatically determine the existing network address and mask from examining the template default.xml, etc, but this scripting is simpler and gets the job done as long as we continue to use 192.168.122.0/24 in the template. (If anyone with mad bash skillz wants to suggest something to do that, by all means please do). This is intended to at least "further reduce" the problems detailed in: https://bugzilla.redhat.com/show_bug.cgi?id=811967 I acknowledge that it doesn't help for cases of pre-built cloud images (or live images that are created on real hardware and then run in a virtual machine), but it should at least eliminate the troubles encountered by individuals doing one-off installs (and could be used to stifle complaints for live images, as long as libvirtd was running on the system where the live image compose took place (or the compose was itself done in a virtual machine that had a 192.168.122.0/24 interface address). --- The question here is: "Will this help some people's situation without causing new problems for anyone else?" I wouldn't mind pushing this patch, but also wouldn't mind if it was just the catalyst for discussion that leads to a better solution. We do need *some kind* of solution though, as more and more people are installing OSes that include the libvirt package in virtual machines, and are running into this problem with increasing frequency. libvirt.spec.in | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index a6a58cf..539d9ef 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1728,8 +1728,32 @@ fi %if %{with_network} %post daemon-config-network if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; then + # see if the network used by default network creates a conflict, + # and try to resolve it + orig_sub=122 + sub=${orig_sub} + net=192.168.${sub}.0/24 + routes=$(ip route show | cut -d' ' -f1) + for route in $routes; do + if [ "${net}" = "${route}" ]; then + # there was a match, so we need to look for an unused subnet + for new_sub in $(seq 123 254); do + new_net="192.168.${new_sub}.0/24" + usable=yes + for route in ${routes}; do + [ "${new_net}" = "${route}" ] && usable=no + done + if [ "${usable}" = "yes" ]; then + sub=${new_sub} + break; + fi + done + fi + done + UUID=`/usr/bin/uuidgen` - sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ + sed -e "s/${orig_sub}/${sub}/g" \ + -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ < %{_datadir}/libvirt/networks/default.xml \ > %{_sysconfdir}/libvirt/qemu/networks/default.xml ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml -- 1.9.3

4 4

[libvirt] [PATCH v4 0/7] wrap up virDomainBlockCopy
by Eric Blake 12 Sep '14

12 Sep '14

diff to v3: patch 1 now consumes the destination in the common helper instead of copying it patch 2 rebased accordingly patch 3 didn't need much work patch 4 finally tested patches 5-7 are new Also available at git://repo.or.cz/libvirt/ericb.git branch blockcopy, http://repo.or.cz/w/libvirt/ericb.git/shortlog/refs/heads/blockcopy Eric Blake (7): blockcopy: tweak how rebase calls into copy blockcopy: add qemu implementation of new API blockcopy: add qemu implementation of new tunables blockjob: allow finer bandwidth tuning for set speed blockjob: improve handling of bandwidth in virsh blockjob: automatically use bytes for bandwidth in virsh blockjob: allow forcing of bytes scale in virsh include/libvirt/libvirt.h.in | 31 ++++-- src/libvirt.c | 83 +++++++++----- src/qemu/qemu_driver.c | 255 +++++++++++++++++++++++++++++-------------- src/qemu/qemu_migration.c | 2 +- src/qemu/qemu_monitor.c | 8 +- src/qemu/qemu_monitor.h | 2 + src/qemu/qemu_monitor_json.c | 4 + src/qemu/qemu_monitor_json.h | 2 + tests/qemumonitorjsontest.c | 2 +- tools/virsh-domain.c | 226 ++++++++++++++++++++++++++++++-------- tools/virsh.pod | 50 +++++---- 11 files changed, 481 insertions(+), 184 deletions(-) -- 1.9.3

2 16

[libvirt] [PATCHv4 0/8] bulk stats: QEMU implementation
by Francesco Romani 12 Sep '14

12 Sep '14

This patchset enhances the QEMU support for the new bulk stats API to include equivalents of these APIs: virDomainBlockInfo virDomainGetInfo - for balloon stats virDomainGetCPUStats virDomainBlockStatsFlags virDomainInterfaceStats virDomainGetVcpusFlags virDomainGetVcpus This subset of API is the one oVirt relies on. Scale/stress test on an oVirt test environment is in progress. The patchset is organized as follows: - the first patch enhances the internal stats gathering API to accomodate the needs of the groups which extract information using QEMU monitor jobs. - the next five patches implement the bulk stats groups, extracting helpers where do refactoring to extract internal helpers every time it is feasible and convenient. - the seventh patch enhances the virsh domstats command with options to use the new bulk stats. - the last patch enhances the block stats group adding the wr_highest_offset information, needed by oVirt for thin provisioned disks. ChangeLog v4: fixes and cleanups - addressed reviewers comments (Peter, Wang Rui). - pushed domain check into group stats functions. This follows the strategy to gather and report as much data as possible, silently skipping errors along the way. - moved the block allocation patch to the end of the series. v3: more polishing and fixes after first review - addressed Eric's comments. - squashed patches which extracts helpers with patches which use them. - changed gathering strategy: now code tries to reap as much information as possible instead to give up and bail out with error. Only critical errors cause the bulk stats to fail. - moved away from the transfer semantics. I find it error-prone and not flexible enough, I'd like to avoid as much as possible. - rearranged helpers to have one single QEMU query job with many monitor jobs nested inside. - fixed docs. - implemented missing virsh domstats bits. in v2: polishing and optimizations. - incorporated feedback from Li Wei (thanks). - added documentation. - optimized block group to gather all the information with just one call to QEMU monitor. - stripped to bare bones merged the 'block info' group into the 'block' group - oVirt actually needs just one stat from there. - reorganized the keys to be more consistent and shorter. Francesco Romani (8): qemu: bulk stats: extend internal collection API qemu: bulk stats: implement CPU stats group qemu: bulk stats: implement balloon group qemu: bulk stats: implement VCPU group qemu: bulk stats: implement interface group qemu: bulk stats: implement block group virsh: add options to query bulk stats group qemu: bulk stats: add block allocation information include/libvirt/libvirt.h.in | 5 + src/libvirt.c | 61 +++++ src/qemu/qemu_driver.c | 575 +++++++++++++++++++++++++++++++++++++------ src/qemu/qemu_monitor.c | 26 ++ src/qemu/qemu_monitor.h | 21 ++ src/qemu/qemu_monitor_json.c | 227 ++++++++++++----- src/qemu/qemu_monitor_json.h | 4 + tools/virsh-domain-monitor.c | 35 +++ tools/virsh.pod | 4 +- 9 files changed, 822 insertions(+), 136 deletions(-) -- 1.9.3

3 18

[libvirt] [PATCHv2 0/2] conf: snapshot: Don't default-snapshot empty drives
by Peter Krempa 12 Sep '14

12 Sep '14

Series contains a duplicate submission of patch 1/2 with my ohter series. Peter Krempa (2): util: Add function to check if a virStorageSource is "empty" conf: snapshot: Don't default-snapshot empty drives src/conf/snapshot_conf.c | 8 +++++++- src/libvirt_private.syms | 1 + src/util/virstoragefile.c | 20 ++++++++++++++++++++ src/util/virstoragefile.h | 1 + 4 files changed, 29 insertions(+), 1 deletion(-) -- 2.1.0

2 7

[libvirt] [PATCHv2 0/2] Couple of NVRAM fixes
by Michal Privoznik 12 Sep '14

12 Sep '14

diff to v1: -patch 1/2 (2/2 in previous version) updated according to Laszlo's review Michal Privoznik (2): virDomainUndefineFlags: Allow NVRAM unlinking formatdomain: Update <loader/> example to match the rest docs/formatdomain.html.in | 2 +- include/libvirt/libvirt.h.in | 2 ++ src/qemu/qemu_driver.c | 20 +++++++++++++++++++- tools/virsh-domain.c | 20 ++++++++++++++++---- tools/virsh.pod | 6 +++++- 5 files changed, 43 insertions(+), 7 deletions(-) -- 1.8.5.5

2 5