- Devel - libvirt List Archives

[libvirt] [PATCH 0/2] Misc fixes
by Cédric Bosdonnat 20 Apr '15

20 Apr '15

Hi all, Here are 2 small fixes: the first one just gets the apparmor right for SLES (and openSUSE). The second patch fixes a problem with lxc-enter-namespace on pretty recent kernels. They surely have nothing to do with each other ;) Cédric Bosdonnat (2): Apparmor qemu abstraction fixes for SLES Open /proc/PID/ns/* read-only to avoid getting permission denied examples/apparmor/libvirt-qemu | 9 +++++++++ src/util/virprocess.c | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- 2.1.4

4 5

[libvirt] [PATCH] qemu: lifecycle: guest get rebooted after reboot and shutdown
by zhang bo 20 Apr '15

20 Apr '15

Steps: 1 virsh reboot guest1 --mode=acpi 2 virsh shutdown guest1 --mode=agent Expected result: As the SHUTDOWN job is after REBOOT, we expected the guest to be *shutoff*. Exacted result: After the 2 steps above, the guest got *rebooted*. The reason to this problem: 1 in qemuDomainReboot(mode acpi), it sets priv->fakeReboot to 1. 2 after shutdown/reboot, qemu monitor IO trigged qemuProcessHandleShutdown(), which finds that priv->fakeReboot is 1, and reboot the guest. Root Cause of the problem: After further look into the problem, We found that the design of acpi/agent shutdown/reboot seems a little chaotic. ----------------------------------- sheet1 who sets fakeReboot ----------------------------------- shutdown reboot acpi Y(0) Y(1) agent N N It's apparently, *acpi-mode* jobs set fakeReboot. ----------------------------------- sheet2 who needs to check fakeReboot(qemuProcessHandleShutdown()) ----------------------------------- shutdown reboot acpi Y Y agent *Y* *N* Things become a little odd here. only agent-mode reboot doesn't check fakeReboot. We can tell from the above 2 sheets, that they're not consistent. *Agent-mode shutdown checks fakeReboot(trigger by SHUTDOWN monitorIO event), while it didn't set it before.* The chaos is not caused by libvirtd, it's a systematic problem, including guest os and qemu. (guest os writes ACPI, triggers qemu, qemu then triggers libvirtd) Solution: A simple solution is to make the 1st sheet consistent to the 2nd sheet, which is: ----------------------------------- sheet3 who should set fakeReboot: ----------------------------------- shutdown reboot acpi Y(0) Y(1) agent *Y(0)* N ----------------------------------- we let agent-mode shutdown set fakeReboot to 0. Signed-off-by: Zhang Bo <oscar.zhangbo(a)huawei.com> Signed-off-by: Wang Yufei <james.wangyufei(a)huawei.com> --- src/qemu/qemu_driver.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 7eb5a7d..c751dcf 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1959,6 +1959,8 @@ static int qemuDomainShutdownFlags(virDomainPtr dom, unsigned int flags) goto endjob; } + qemuDomainSetFakeReboot(driver, vm, isReboot); + if (useAgent) { qemuDomainObjEnterAgent(vm); ret = qemuAgentShutdown(priv->agent, agentFlag); @@ -1970,7 +1972,6 @@ static int qemuDomainShutdownFlags(virDomainPtr dom, unsigned int flags) */ if (!useAgent || (ret < 0 && (acpiRequested || !flags))) { - qemuDomainSetFakeReboot(driver, vm, isReboot); /* Even if agent failed, we have to check if guest went away * by itself while our locks were down. */ -- 1.7.12.4

2 2

[libvirt] Selective block device migration implementation
by Pavel Boldin 18 Apr '15

18 Apr '15

Dear Libvirt Developers, I'm working to implement feature request [1]. The feature request proposes to enhance `libvirt' code so the API caller can specify which block devices are to be migrated using e.g. parameters in the `virDomainMigrateToURI3' call. There is the following issues: 1. It is obvious to identify devices to be migrated using the `device_name'. However, these need to be serialized in either 1) a comma-separated string or in 2) a set of values named like `blockdevice%d' with `blockdevice' value holding amount of block devices to migrate. What is the desired approach here? Can block device name contain commas or should I neglect this possibility? 2. `libvirt' behavior in block devices migration was copied from the `QEMU' implementation that ignores read-only devices as well. So, `libvirt' code will need to pass this list to `QEMU' `migrate' QMP command and this argument should be implemented in the `QEMU'. Is there any implementation advices from your side? Pavel [1] https://bugzilla.redhat.com/show_bug.cgi?id=1203032

2 5

[libvirt] converting gatewaydev= from domU.cfg to libvirt.xml fails
by Olaf Hering 18 Apr '15

18 Apr '15

How should this be converted? /etc/init.d/boot.local tap=xentap tunctl -pt ${tap} ip addr add 1.1.1.1/29 dev ${tap} ip link set up dev ${tap} domU.cfg vif=[ 'mac=00:16:3e:13:01:00,ip=1.1.1.2,type=vif,gatewaydev=xentap,script=vif-route' ] The result from "convert-xml xen-xl domU,cfg" is: <interface type='ethernet'> <mac address='00:16:3e:13:01:00'/> <ip address='1.1.1.2' family='ipv4'/> <script path='vif-route'/> </interface> gatewaydev= is missing, the guest will not start. Olaf

2 2

[libvirt] [libvirt-php] memory overflow when using libvirt_list_networks
by Kash Pande 18 Apr '15

18 Apr '15

Finding lots of bad behaviour here: [Fri Apr 17 23:44:04.590626 2015] [:error] [pid 31714] [client 127.0.0.1:38103] PHP Warning: libvirt_list_networks(): this function is not supported by the connection driver: virConnectNumOfNetworks [Fri Apr 17 23:44:04.590655 2015] [:error] [pid 31714] [client 127.0.0.1:38103] PHP Fatal error: Out of memory (allocated 524288) (tried to allocate 18446744073709551608 bytes) There's no way to check if this exists... I noticed the following about versions: - this system works fine (Git): libvirt 1.2.9 Array ( [libvirt.release] => 9 [libvirt.minor] => 2 [libvirt.major] => 1 [connector.version] => 0.5.0 [connector.major] => 0 [connector.minor] => 5 [connector.release] => 0 ) - this system has problems (Git) libvirt 1.2.12 Array ( [libvirt.release] => 12 [libvirt.minor] => 2 [libvirt.major] => 1 [connector.version] => 0.5.0 [connector.major] => 0 [connector.minor] => 5 [connector.release] => 0 [type.release] => 12 [type.minor] => 2 [type.major] => 1 ) When I do a version check to only do network list for version under .12, I get this: [Fri Apr 17 23:44:43.608308 2015] [:error] [pid 31689] [client 127.0.0.1:38216] PHP Warning: libvirt_network_get(): this function is not supported by the connection driver: virNetworkLookupByName Which causes a cascade of other errors if you're not checking for problems each step along the way. Kash Pande Jentu Technologies, Inc http://jentu-networks.com

1 0

[libvirt] [PATCH v3 0/4] storage: handle scsi/iscsi error paths better
by John Ferlan 18 Apr '15

18 Apr '15

Rework of unpushed patches from series: http://www.redhat.com/archives/libvir-list/2015-April/msg00050.html Details: Patch 1 - Split out the non /dev/* checks into their own to start satisfying Jan's comment in his review of the former patch 3: http://www.redhat.com/archives/libvir-list/2015-April/msg00100.html Patch 2 - New - Flip the logic from assume success, change status to failure, and return to assume failure and only have success when everything completes successfully Patch 3 - Adjustments for previous patch 3 to make use of patch 1's split of the checking for using the /dev path. If we find that the /dev/* is not in use for the pool, then force an error earlier. This makes the check later on not need to compare the returned path to the generated 'devpath' to compensate for the logic in virStorageBackendStablePath which will strdup the incoming target path if something goes wrong in looking up the directory. Since both paths will use the new virStorageBackendPoolUseDevPath slightly differently, if devpath is the same as vol->target.path, then we know it's not because the pool target path was to blame. Patch 4 - Is the former patch 5, but now since patch 3 returns a failure in virStorageBackendSCSINewLun for that bad path, we can use it to be the error arbiter and bug fixer. Former patch 6 - no longer necessary, although it would circumvent any of the above patches being necessary to solve the bug... John Ferlan (4): storage: Split out the valid path check refactor virStorageBackendSCSINewLun scsi: Adjust return value for virStorageBackendSCSINewLun scsi: Adjust return values from processLU src/storage/storage_backend.c | 42 +++++++++---- src/storage/storage_backend.h | 1 + src/storage/storage_backend_scsi.c | 124 +++++++++++++++++++++---------------- 3 files changed, 100 insertions(+), 67 deletions(-) -- 2.1.0

2 14

[libvirt] [PATCH] libxl: include a XLU_Config in _libxlDriverConfig
by Olaf Hering 17 Apr '15

17 Apr '15

Upcoming changes for vscsi will use libxlutil.so to prepare the configuration for libxl. The helpers needs a xlu struct for logging. Provide one and reuse the existing output as log target. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> Cc: Jim Fehlig <jfehlig(a)suse.com> --- src/libxl/libxl_conf.c | 6 ++++++ src/libxl/libxl_conf.h | 2 ++ 2 files changed, 8 insertions(+) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 8b76fc7..43712b3 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -1421,6 +1421,12 @@ libxlDriverConfigNew(void) goto error; } + cfg->xlu = xlu_cfg_init(cfg->logger_file, "libvirt"); + if (!cfg->xlu) { + VIR_ERROR(_("cannot create xlu for libxenlight, disabling driver")); + goto error; + } + if (libxl_ctx_alloc(&cfg->ctx, LIBXL_VERSION, 0, cfg->logger)) { VIR_ERROR(_("cannot initialize libxenlight context, probably not " "running in a Xen Dom0, disabling driver")); diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index 59389d1..fd2459f 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -27,6 +27,7 @@ # define LIBXL_CONF_H # include <libxl.h> +# include <libxlutil.h> # include "internal.h" # include "libvirt_internal.h" @@ -90,6 +91,7 @@ struct _libxlDriverConfig { /* log stream for driver-wide libxl ctx */ FILE *logger_file; xentoollog_logger *logger; + XLU_Config *xlu; /* libxl ctx for driver wide ops; getVersion, getNodeInfo, ... */ libxl_ctx *ctx;

2 1

[libvirt] [PATCH] libxl: initialize allocated libxl_device_vfb array
by Olaf Hering 17 Apr '15

17 Apr '15

Its already allocated by calloc, but the init function sets ->devid. Just in case anything cares. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> Cc: Jim Fehlig <jfehlig(a)suse.com> --- src/libxl/libxl_conf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 6feb7d9..8b76fc7 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -1288,6 +1288,7 @@ libxlMakeVfbList(virPortAllocatorPtr graphicsports, } for (i = 0; i < nvfbs; i++) { + libxl_device_vfb_init(&x_vfbs[i]); libxl_device_vkb_init(&x_vkbs[i]); if (libxlMakeVfb(graphicsports, l_vfbs[i], &x_vfbs[i]) < 0)

1 1

[libvirt] [PATCH] domcaps: Check for architecture more wisely
by Michal Privoznik 17 Apr '15

17 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1209948 So we have this bug. The virConnectGetDomainCapabilities() API performs a couple of checks before it produces any result. One of the checks is if the architecture requested by user can be run by the binary (again user provided). However, the check is pretty dumb. It merely compares if the default binary architecture matches the one provided by user. However, a qemu binary can run multiple architectures. For instance: qemu-system-ppc64 can run: ppc, ppcle, ppc64, ppc64le and ppcemb. The default is ppc64, so if user requested something else, like ppc64le, the check would have failed without obvious reason. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_driver.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 921417c..d217481 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -18788,7 +18788,10 @@ qemuConnectGetDomainCapabilities(virConnectPtr conn, arch_from_caps = virQEMUCapsGetArch(qemuCaps); if (arch_from_caps != arch && - (arch_from_caps != VIR_ARCH_X86_64 || arch != VIR_ARCH_I686)) { + !((ARCH_IS_X86(arch) && ARCH_IS_X86(arch_from_caps)) || + (ARCH_IS_PPC(arch) && ARCH_IS_PPC(arch_from_caps)) || + (ARCH_IS_ARM(arch) && ARCH_IS_ARM(arch_from_caps)) || + (ARCH_IS_S390(arch) && ARCH_IS_S390(arch_from_caps)))) { virReportError(VIR_ERR_INVALID_ARG, _("architecture from emulator '%s' doesn't " "match given architecture '%s'"), -- 2.0.5

2 4

[libvirt] [PATCH] domain: conf: Better errors on bad os <type> values
by Cole Robinson 17 Apr '15

17 Apr '15

If no <os><type> was specified: before: unknown OS type no OS type after : xml error: an os <type> must be specified If an <os><type> is specified that's not in our capabiliities data: before: unknown OS type $type after : unsupported configuration: no support found for os <type> '$type' VIR_ERR_OS_TYPE is now unused (as it should be frankly) so drop its strings as well to save our translators some effort. --- src/conf/domain_conf.c | 9 +++++---- src/util/virerror.c | 5 +---- 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 4d7e3c9..a145e11 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -14638,8 +14638,8 @@ virDomainDefParseXML(xmlDocPtr xml, if (VIR_STRDUP(def->os.type, "xen") < 0) goto error; } else { - virReportError(VIR_ERR_OS_TYPE, - "%s", _("no OS type")); + virReportError(VIR_ERR_XML_ERROR, "%s", + _("an os <type> must be specified")); goto error; } } @@ -14656,8 +14656,9 @@ virDomainDefParseXML(xmlDocPtr xml, } if (!virCapabilitiesSupportsGuestOSType(caps, def->os.type)) { - virReportError(VIR_ERR_OS_TYPE, - "%s", def->os.type); + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("no support found for os <type> '%s'"), + def->os.type); goto error; } diff --git a/src/util/virerror.c b/src/util/virerror.c index 73dae95..aab36ae 100644 --- a/src/util/virerror.c +++ b/src/util/virerror.c @@ -900,10 +900,7 @@ virErrorMsg(virErrorNumber error, const char *info) errmsg = _("failed Xen syscall %s"); break; case VIR_ERR_OS_TYPE: - if (info == NULL) - errmsg = _("unknown OS type"); - else - errmsg = _("unknown OS type %s"); + errmsg = "%s"; break; case VIR_ERR_NO_KERNEL: errmsg = _("missing kernel information"); -- 2.3.5

2 2