October 2013 - Devel - libvirt List Archives

[libvirt] [PATCH 0/2] change the minimum blkio weight according to kernel version
by Chen Hanxiao 09 Oct '13

09 Oct '13

From: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> Since 2.6.39, kernel changed the minimum weight of device blkio. We need to follow them according to different kernel version. Chen Hanxiao (2): [libvirt][PATCH]cgroup: introduce kernel version check function for cgroup [libvirt][PATCH]blkio: change the minimum weight according to kernel version src/util/vircgroup.c | 76 ++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 65 insertions(+), 11 deletions(-) -- 1.8.2.1

2 6

[libvirt] [PATCH] tests: Add qemu test for multiple timers
by Cole Robinson 08 Oct '13

08 Oct '13

The following XML is the recommended default clock configuration for qemu: <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> However we weren't testing any of those timer elements. --- .../qemuxml2argv-clock-hpet-off.args | 5 ++++ .../qemuxml2argv-clock-hpet-off.xml | 30 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 2 ++ 3 files changed, 37 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-clock-hpet-off.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-clock-hpet-off.xml diff --git a/tests/qemuxml2argvdata/qemuxml2argv-clock-hpet-off.args b/tests/qemuxml2argvdata/qemuxml2argv-clock-hpet-off.args new file mode 100644 index 0000000..5d11d91 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-clock-hpet-off.args @@ -0,0 +1,5 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu -S -M \ +pc -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait \ +-rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-hpet -no-acpi -boot c \ +-usb -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none diff --git a/tests/qemuxml2argvdata/qemuxml2argv-clock-hpet-off.xml b/tests/qemuxml2argvdata/qemuxml2argv-clock-hpet-off.xml new file mode 100644 index 0000000..3aed49f --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-clock-hpet-off.xml @@ -0,0 +1,30 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 58165fd..286f1a3 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -421,6 +421,8 @@ mymain(void) DO_TEST("clock-variable", QEMU_CAPS_RTC); */ DO_TEST("clock-france", QEMU_CAPS_RTC); + DO_TEST("clock-hpet-off", QEMU_CAPS_RTC, QEMU_CAPS_NO_HPET, + QEMU_CAPS_NO_KVM_PIT); DO_TEST("cpu-kvmclock", QEMU_CAPS_ENABLE_KVM); DO_TEST("cpu-host-kvmclock", QEMU_CAPS_ENABLE_KVM, QEMU_CAPS_CPU_HOST); DO_TEST("kvmclock", QEMU_CAPS_KVM); -- 1.8.3.1

2 1

[libvirt] [PATCH] Ignore thin pool LVM devices
by Dusty Mabe 08 Oct '13

08 Oct '13

For BZ 924672 the problem stems from the fact that thin pool logical volume devices show up in /sbin/lvs output just like normal logical volumes do. Since the thin pool devices show up libvirt assumes they are just normal logical volumes and assumes there will be a corresponding /dev/vgname/lvname device that has been created. This is not the case and you will receive the following error when starting the storage pool: error: cannot stat file '/dev/vgvirt/thinpool': No such file or directory This patch modifies virStorageBackendLogicalMakeVol() to ignore thin pool backing devices. --- src/storage/storage_backend_logical.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c index a1a37a1..74d26bd 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -85,6 +85,10 @@ virStorageBackendLogicalMakeVol(virStoragePoolObjPtr pool, if (attrs[4] != 'a') return 0; + /* BZ 924672 - Skip thin pools(t) and thin pool data(T) */ + if (attrs[0] == 't' || attrs[0] == 'T') + return 0; + /* See if we're only looking for a specific volume */ if (data != NULL) { vol = data; -- 1.8.3.1

2 2

[libvirt] [PATCH] qemu_migration: Avoid crashing if domain dies too quickly
by Michal Privoznik 08 Oct '13

08 Oct '13

I've noticed a SIGSEGV-ing libvirtd on the destination when the qemu died too quickly = in Prepare phase. What is happening here is: 1) [Thread 3493] We are in qemuMigrationPrepareAny() and calling qemuProcessStart() which subsequently calls qemuProcessWaitForMonitor() and qemuConnectMonitor(). So far so good. The qemuMonitorOpen() succeeds, however switching monitor to QMP mode fails as qemu died meanwhile. That is qemuMonitorSetCapabilities() returns -1. 2013-10-08 15:54:10.629+0000: 3493: debug : qemuMonitorSetCapabilities:1356 : mon=0x14a53da0 2013-10-08 15:54:10.630+0000: 3493: debug : qemuMonitorJSONCommandWithFd:262 : Send command '{"execute":"qmp_capabilities","id":"libvirt-1"}' for write with FD -1 2013-10-08 15:54:10.630+0000: 3493: debug : virEventPollUpdateHandle:147 : EVENT_POLL_UPDATE_HANDLE: watch=17 events=13 ... 2013-10-08 15:54:10.631+0000: 3493: debug : qemuMonitorSend:956 : QEMU_MONITOR_SEND_MSG: mon=0x14a53da0 msg={"execute":"qmp_capabilities","id":"libvirt-1"} fd=-1 2013-10-08 15:54:10.631+0000: 3262: debug : virEventPollRunOnce:641 : Poll got 1 event(s) 2) [Thread 3262] The event loop is trying to do the talking to monitor. However, qemu is dead already, remember? 2013-10-08 15:54:13.436+0000: 3262: error : qemuMonitorIORead:551 : Unable to read from monitor: Connection reset by peer 2013-10-08 15:54:13.516+0000: 3262: debug : virFileClose:90 : Closed fd 25 ... 2013-10-08 15:54:13.533+0000: 3493: debug : qemuMonitorSend:968 : Send command resulted in error internal error: early end of file from monitor: possible problem: 3) [Thread 3493] qemuProcessStart() failed. No big deal. Go to the 'endjob' label and subsequently to the 'cleanup'. Since the domain is not persistent and ret is -1, the qemuDomainRemoveInactive() is called. This has an (unpleasant) effect of virObjectUnref()-in the @vm object. Unpleasant because the event loop which is about to trigger EOF callback still holds a pointer to the @vm (not the reference). See the valgrind output below. 4) [Thread 3262] So the even loop starts triggering EOF: 2013-10-08 15:54:13.542+0000: 3262: debug : qemuMonitorIO:729 : Triggering EOF callback 2013-10-08 15:54:13.543+0000: 3262: debug : qemuProcessHandleMonitorEOF:294 : Received EOF on 0x14549110 'migt10' And the monitor is cleaned up. This results in calling qemuProcessHandleMonitorEOF with the @vm pointer passed. The pointer is kept in qemuMonitor struct. ==3262== Thread 1: ==3262== Invalid read of size 4 ==3262== at 0x77ECCAA: pthread_mutex_lock (in /lib64/libpthread-2.15.so) ==3262== by 0x52FAA06: virMutexLock (virthreadpthread.c:85) ==3262== by 0x52E3891: virObjectLock (virobject.c:320) ==3262== by 0x11626743: qemuProcessHandleMonitorEOF (qemu_process.c:296) ==3262== by 0x11642593: qemuMonitorIO (qemu_monitor.c:730) ==3262== by 0x52BD526: virEventPollDispatchHandles (vireventpoll.c:501) ==3262== by 0x52BDD49: virEventPollRunOnce (vireventpoll.c:648) ==3262== by 0x52BBC68: virEventRunDefaultImpl (virevent.c:274) ==3262== by 0x542D3D9: virNetServerRun (virnetserver.c:1112) ==3262== by 0x11F368: main (libvirtd.c:1513) ==3262== Address 0x14549128 is 24 bytes inside a block of size 136 free'd ==3262== at 0x4C2AF5C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3262== by 0x529B1FF: virFree (viralloc.c:580) ==3262== by 0x52E3703: virObjectUnref (virobject.c:270) ==3262== by 0x531557E: virDomainObjListRemove (domain_conf.c:2355) ==3262== by 0x1160E899: qemuDomainRemoveInactive (qemu_domain.c:2061) ==3262== by 0x1163A0C6: qemuMigrationPrepareAny (qemu_migration.c:2450) ==3262== by 0x1163A923: qemuMigrationPrepareDirect (qemu_migration.c:2626) ==3262== by 0x11682D71: qemuDomainMigratePrepare3Params (qemu_driver.c:10309) ==3262== by 0x53B0976: virDomainMigratePrepare3Params (libvirt.c:7266) ==3262== by 0x1502D3: remoteDispatchDomainMigratePrepare3Params (remote.c:4797) ==3262== by 0x12DECA: remoteDispatchDomainMigratePrepare3ParamsHelper (remote_dispatch.h:5741) ==3262== by 0x54322EB: virNetServerProgramDispatchCall (virnetserverprogram.c:435) The mon->vm is set in qemuMonitorOpenInternal() which is the correct place to increase @vm ref counter. The correct place to decrease the ref counter is then qemuMonitorDispose(). However, in order to avoid cyclic calling of dispose functions, we must use hack, and set priv->mon to NULL. The qemuDomainObjPrivateFree won't call us again then. This describes the last two chunks of the commit. The others are there for handling virObjectRef() and virObjectUnref() correctly. So far it doesn't work well with NULL virClassPtr :) Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Yet another one of those patches, where chasing it down took a half of a day and description what went wrong is longer than a few lines of fix. src/qemu/qemu_capabilities.c | 14 ++++++++++---- src/qemu/qemu_monitor.c | 12 ++++++++++++ 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 7c39c1c..17095b4 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -2587,7 +2587,8 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps, char *monpath = NULL; char *pidfile = NULL; pid_t pid = 0; - virDomainObj vm; + virDomainObjPtr vm = NULL; + virDomainXMLOptionPtr xmlopt = NULL; /* the ".sock" sufix is important to avoid a possible clash with a qemu * domain called "capabilities" @@ -2650,10 +2651,13 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps, goto cleanup; } - memset(&vm, 0, sizeof(vm)); - vm.pid = pid; + if (!(xmlopt = virDomainXMLOptionNew(NULL, NULL, NULL)) || + !(vm = virDomainObjNew(xmlopt))) + goto cleanup; + + vm->pid = pid; - if (!(mon = qemuMonitorOpen(&vm, &config, true, &callbacks, NULL))) { + if (!(mon = qemuMonitorOpen(vm, &config, true, &callbacks, NULL))) { ret = 0; goto cleanup; } @@ -2673,6 +2677,8 @@ cleanup: virCommandFree(cmd); VIR_FREE(monarg); VIR_FREE(monpath); + virObjectUnref(vm); + virObjectUnref(xmlopt); if (pid != 0) { char ebuf[1024]; diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index a601ee0..2cf68da 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -251,10 +251,21 @@ static char * qemuMonitorEscapeNonPrintable(const char *text) static void qemuMonitorDispose(void *obj) { qemuMonitorPtr mon = obj; + qemuDomainObjPrivatePtr priv = mon->vm->privateData; VIR_DEBUG("mon=%p", mon); if (mon->cb && mon->cb->destroy) (mon->cb->destroy)(mon, mon->vm, mon->callbackOpaque); + /* HACK: priv->mon is still non-NULL. If we are the last to hold the + * reference to mon->vm, the qemuDomainObjPrivateFree() will call + * qemuMonitorClose() and hence us again. IOW, dispose callback which calls + * dispose callback which calls dispose callback ... + * Moreover, not all domains have privateData - for instance a dummy domain + * object created in virQEMUCapsInitQMP(). */ + if (priv) + priv->mon = NULL; + virObjectUnref(mon->vm); + virCondDestroy(&mon->notify); VIR_FREE(mon->buffer); virJSONValueFree(mon->options); @@ -781,6 +792,7 @@ qemuMonitorOpenInternal(virDomainObjPtr vm, } mon->fd = fd; mon->hasSendFD = hasSendFD; + virObjectRef(vm); mon->vm = vm; mon->json = json; if (json) -- 1.8.1.5

2 1

Re: [libvirt] [virt-tools-list] [PATCH] build: fix linker error on FreeBSD
by Eric Blake 08 Oct '13

08 Oct '13

On 10/08/2013 10:21 AM, Giuseppe Scrivano wrote: > Commit 2d74822a9eb4856c7f5216bb92bcb76630660f72 renamed > "freebsdNodeGetCPUCount" to "appleFreebsdNodeGetCPUCount", leaving one > call to "freebsdNodeGetCPUCount". Fix this other case. ACK, although it looks like you intended this to go to libvir-list (now cc'd) > > Signed-off-by: Giuseppe Scrivano <gscrivan(a)redhat.com> > --- > src/nodeinfo.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/nodeinfo.c b/src/nodeinfo.c > index 320d8f8..702ad7c 100644 > --- a/src/nodeinfo.c > +++ b/src/nodeinfo.c > @@ -1056,8 +1056,8 @@ nodeGetCPUCount(void) > > VIR_FREE(cpupath); > return ncpu; > -#elif defined(__FreeBSD__) > - return freebsdNodeGetCPUCount(); > +#elif defined(__FreeBSD__) || defined(__APPLE__) > + return appleFreebsdNodeGetCPUCount (); > #else > virReportError(VIR_ERR_NO_SUPPORT, "%s", > _("host cpu counting not implemented on this platform")); > -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

2 3

[libvirt] [PATCH] Fix typo breaking cgroups for NBD backed filesystems
by Daniel P. Berrange 08 Oct '13

08 Oct '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> A typo in the setup of NBD backed filesystems meant the /dev/nbdN device would not be added to the cgroups device ACL. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/lxc/lxc_controller.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index e7e7acc..6cb36ff 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -423,7 +423,7 @@ static int virLXCControllerSetupNBDDeviceFS(virDomainFSDefPtr fs) * We now change it into a block device type, so that * the rest of container setup 'just works' */ - fs->type = VIR_DOMAIN_DISK_TYPE_BLOCK; + fs->type = VIR_DOMAIN_FS_TYPE_BLOCK; VIR_FREE(fs->src); fs->src = dev; -- 1.8.3.1

2 1

[libvirt] [PATCH] Initialize threading & error layer in LXC controller
by Daniel P. Berrange 08 Oct '13

08 Oct '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> In Fedora 20, libvirt_lxc crashes immediately at startup with a trace #0 0x00007f0cddb653ec in free () from /lib64/libc.so.6 #1 0x00007f0ce0e16f4a in virFree (ptrptr=ptrptr@entry=0x7f0ce1830058) at util/viralloc.c:580 #2 0x00007f0ce0e2764b in virResetError (err=0x7f0ce1830030) at util/virerror.c:354 #3 0x00007f0ce0e27a5a in virResetLastError () at util/virerror.c:387 #4 0x00007f0ce0e28858 in virEventRegisterDefaultImpl () at util/virevent.c:233 #5 0x00007f0ce0db47c6 in main (argc=11, argv=0x7fff4596c328) at lxc/lxc_controller.c:2352 Normally virInitialize calls virErrorInitialize and virThreadInitialize, but we don't link to libvirt.so in libvirt_lxc, and nor did we ever call the error or thread initializers. I have absolutely no idea how this has ever worked, let alone what caused it to stop working in Fedora 20. In addition not all code paths from virLogSetFromEnv will ensure virLogInitialize is called correctly, which is another possible crash scenario. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/lxc/lxc_controller.c | 4 +++- src/util/virlog.c | 6 ++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index ed73ab0..92fb2bb 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -2250,7 +2250,9 @@ int main(int argc, char *argv[]) if (setlocale(LC_ALL, "") == NULL || bindtextdomain(PACKAGE, LOCALEDIR) == NULL || - textdomain(PACKAGE) == NULL) { + textdomain(PACKAGE) == NULL || + virThreadInitialize() < 0 || + virErrorInitialize() < 0) { fprintf(stderr, _("%s: initialization failed\n"), argv[0]); exit(EXIT_FAILURE); } diff --git a/src/util/virlog.c b/src/util/virlog.c index 047a131..a54e209 100644 --- a/src/util/virlog.c +++ b/src/util/virlog.c @@ -547,6 +547,9 @@ virLogDefineFilter(const char *match, virCheckFlags(VIR_LOG_STACK_TRACE, -1); + if (virLogInitialize() < 0) + return -1; + if ((match == NULL) || (priority < VIR_LOG_DEBUG) || (priority > VIR_LOG_ERROR)) return -1; @@ -662,6 +665,9 @@ virLogDefineOutput(virLogOutputFunc f, virCheckFlags(0, -1); + if (virLogInitialize() < 0) + return -1; + if (f == NULL) return -1; -- 1.8.3.1

2 1

[libvirt] [PATCHv3 0/3] Change preference of default PCI passthrough type to VFIO
by Peter Krempa 08 Oct '13

08 Oct '13

Version 3 incorporates fixes for issues I found while testing this series a bit better than the previous one. The main objective of this series is to add checks if VFIO is enabled on a host and if it's the case use it as a default PCI passthrough type instead of the legacy KVM passthrough type. Peter Krempa (3): qemu: hostdev: Refactor PCI passhrough handling qemu: hostdev: Add checks if PCI passthrough is availabe in the host qemu: Prefer VFIO for PCI device passthrough docs/formatdomain.html.in | 9 ++- src/conf/domain_conf.h | 2 +- src/qemu/qemu_command.c | 28 ++++++--- src/qemu/qemu_hostdev.c | 143 ++++++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_hostdev.h | 5 ++ src/qemu/qemu_hotplug.c | 29 ++++++---- src/qemu/qemu_process.c | 18 ++++-- tests/qemuxml2argvtest.c | 11 ++++ 8 files changed, 214 insertions(+), 31 deletions(-) -- 1.8.3.2

3 12

[libvirt] [PATCHv4 0/4] Introduce APIs to extract DHCP leases info
by Nehal J Wani 08 Oct '13

08 Oct '13

This API returns the leases information stored in the DHCP leases file of dnsmasq for a given virtual network. It contacts the bridge network driver, which parses the leases file. It supports two methods: 1. Return info for all network interfaces connected to a given virtual network 2. Return information for a particular network interface in a given virtual network by providing its MAC Address v4 * Added support for DHCPv6, updated lease file parsing method v3 * Mostly small nits, change in MACRO names, use of virSocketAddrGetIpPrefix to retrieve IP prefix from @dom XML. Refer: https://www.redhat.com/archives/libvir-list/2013-September/msg00832.html v2 * Since DHCPv6 is supposed to be suported in future, virNetworkGetDHCPLeasesForMAC changed, prefix and virIPAddrType added in virNetworkDHCPLeases struct. Refer: https://www.redhat.com/archives/libvir-list/2013-September/msg00732.html v1 * Refer: https://www.redhat.com/archives/libvir-list/2013-September/msg00620.html * The need for these APIs were result of a RFC was proposed on the list. Refer: http://www.redhat.com/archives/libvir-list/2013-July/msg01603.html Nehal J Wani (4): net-dhcp-leases: Implement the remote protocol net-dhcp-leases: Implement the remote protocol net-dhcp-leases: Private implementation inside network driver net-dhcp-leases: Add virsh support daemon/remote.c | 157 ++++++++++++++++++++++++++++ include/libvirt/libvirt.h.in | 36 +++++++ python/generator.py | 3 + src/driver.h | 13 +++ src/libvirt.c | 177 +++++++++++++++++++++++++++++++ src/libvirt_public.syms | 3 + src/network/bridge_driver.c | 240 +++++++++++++++++++++++++++++++++++++++++++ src/remote/remote_driver.c | 169 +++++++++++++++++++++++++++++- src/remote/remote_protocol.x | 59 ++++++++++- src/remote_protocol-structs | 47 +++++++++ src/rpc/gendispatch.pl | 1 + tools/virsh-network.c | 150 +++++++++++++++++++++++++++ tools/virsh.pod | 6 ++ 13 files changed, 1057 insertions(+), 4 deletions(-) -- 1.7.11.7

4 32

[libvirt] [PATCH v2] fix a ambiguous output of the command:'virsh vol-create-as'
by Hongwei Bi 08 Oct '13

08 Oct '13

I created a storage volume(eg: test) from a storage pool(eg:vg10) using the following command:"virsh vol-create-as --pool vg10 --name test --capacity 300M." When I re-executed the above command, the output was as the following: "error: Failed to create vol test error: Storage volume not found: storage vol 'test' already exists" I think the output "Storage volume not found" is not appropriate. Because in fact storage vol test has been found at this time. And then I think virErrorNumber should includes VIR_ERR_STORAGE_EXIST which can also be used elsewhere. So I make this patch. The result is as following: "error: Failed to create vol test error: storage volume 'test' exists already" --- include/libvirt/virterror.h | 1 + src/storage/storage_driver.c | 4 ++-- src/util/virerror.c | 6 ++++++ 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h index c1960c8..fd14237 100644 --- a/include/libvirt/virterror.h +++ b/include/libvirt/virterror.h @@ -296,6 +296,7 @@ typedef enum { VIR_ERR_ACCESS_DENIED = 88, /* operation on the object/resource was denied */ VIR_ERR_DBUS_SERVICE = 89, /* error from a dbus service */ + VIR_ERR_STORAGE_VOL_EXISTS = 90, /* the storage vol already exists */ } virErrorNumber; /** diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 6c39284..d419a36 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1538,8 +1538,8 @@ storageVolCreateXML(virStoragePoolPtr obj, goto cleanup; if (virStorageVolDefFindByName(pool, voldef->name)) { - virReportError(VIR_ERR_NO_STORAGE_VOL, - _("storage vol '%s' already exists"), voldef->name); + virReportError(VIR_ERR_STORAGE_VOL_EXISTS, + _("'%s'"), voldef->name); goto cleanup; } diff --git a/src/util/virerror.c b/src/util/virerror.c index ca25678..3f55cec 100644 --- a/src/util/virerror.c +++ b/src/util/virerror.c @@ -1004,6 +1004,12 @@ virErrorMsg(virErrorNumber error, const char *info) else errmsg = _("Storage volume not found: %s"); break; + case VIR_ERR_STORAGE_VOL_EXISTS: + if (info == NULL) + errmsg = _("this storage volume exists already"); + else + errmsg = _("storage volume %s exists already"); + break; case VIR_ERR_STORAGE_PROBE_FAILED: if (info == NULL) errmsg = _("Storage pool probe failed"); -- 1.7.1

3 4