Re: [libvirt] [PATCH v3 00/12] Add user namespace support for libvirt lxc
On 06/11/2013 02:02 PM, Richard Weinberger wrote: > Am 11.06.2013 05:12, schrieb Gao feng: >> On 06/11/2013 04:51 AM, Richard Weinberger wrote: >>> Am 10.06.2013 21:53, schrieb Richard Weinberger: Am 10.06.2013 21:17, schrieb Richard Weinberger: > Hi! > > Am 04.06.2013 13:03, schrieb Daniel P. Berrange: >>> It's still under review. needs some ACK. >>> If you can help to test or ACK this patchset, it will be very helpful. >>> :) >>> >>> Actually, I just want to ping... >> >> I've been away on holiday for 2 weeks, so not had a chance to review >> it yet. I'll get to it this week. I hope we'll get this in the 1.0.6 >> release this month. > > Finally I've found some time to test version 4 of the userns patch set. > But I'm unable to create a container. > > ---cut--- > linux:~ # LANG=C /opt/libvirt/bin/virsh -c lxc:/// create c1.conf > error: Failed to create domain from c1.conf > error: Interner Fehler guest failed to start: PATH=/bin:/sbin TERM=linux > container=lxc-libvirt container_uuid=3f86c48b-b027-4838-ba17-6202a1d7398b > LIBVIRT_LXC_UUID=3f86c48b-b027-4838-ba17-6202a1d7398b LIBVIRT_LXC_NAME=c1 > /bin/bash > error receiving signal from container: Input/output error > ---cut--- > > lxcContainerWaitForContinue() in src/lxc/lxc_controller.c fails with EIO. > Maybe because the clone()'ed child dies and the file descriptor used for > synchronization becomes invalid. > > Here my container config: > ---cut--- > > c1 > 102400 > > exe > /bin/bash > > > > > > > > > > > > > > ---cut--- > > Any ideas how to debug this further? > This is Linux 3.9.0 with all namespaces enabled. Whoops, forgot to add the libvirtd debug output: ---cut--- 2013-06-10 19:41:24.661+: 29211: debug : virCommandRunAsync:2241 : About to run PATH=/usr/lib64/mpi/gcc/openmpi/bin:/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr /opt/libvirt/lib/libvirt_lxc --name c1 --console 20 --security=none --handshake 23 --background 2013-06-10 19:41:24.663+: 29211: debug : virFileClose:90 : Closed fd 24 2013-06-10 19:41:24.663+: 29211: debug : virCommandRunAsync:2246 : Command result 0, with PID 29303 2013-06-10 19:41:24.664+: 29303: debug : virFileClose:90 : Closed fd 3 2013-06-10 19:41:24.665+: 29303: debug : virFileClose:90 : Closed fd 4 2013-06-10 19:41:24.666+: 29303: debug : virFileClose:90 : Closed fd 5 2013-06-10 19:41:24.666+: 29303: debug : virFileClose:90 : Closed fd 6 2013-06-10 19:41:24.667+: 29303: debug : virFileClose:90 : Closed fd 7 2013-06-10 19:41:24.667+: 29303: debug : virFileClose:90 : Closed fd 8 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 9 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 10 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 11 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 12 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 13 2013-06-10 19:41:24.669+: 29303: debug : virFileClose:90 : Closed fd 14 2013-06-10 19:41:24.669+: 29303: debug : virFileClose:90 : Closed fd 15 2013-06-10 19:41:24.670+: 29303: debug : virFileClose:90 : Closed fd 16 2013-06-10 19:41:24.670+: 29303: debug : virFileClose:90 : Closed fd 17 2013-06-10 19:41:24.670+: 29303: debug : virFileClose:90 : Closed fd 18 2013-06-10 19:41:24.671+: 29303: debug : virFileClose:90 : Closed fd 19 2013-06-10 19:41:24.671+: 29303: debug : virFileClose:90 : Closed fd 22 2013-06-10 19:41:24.790+: 29211: debug : virCommandRun:2115 : Result status 0, stdout: '(null)' stderr: '(null)' ---cut--- Looks like libvirt_lxc was executed and died silently. >>> >>> Found the problem. /opt/libvirt/var/log/libvirt/lxc/c1.log contained the >>> info I needed. >>> Search permissions for /root were missing. m( >>> Would be nice if virsh would be able to tell one this... >>> >> >> :) >> have fun with user namespace & libvirt. >> And thanks for your test. > > Yeah. So far it looks very good. > I was able to convert my containers from my custom lxc/userns setup to > libvirt+userns. > > One more question, is it by design that virsh lxc-enter-namespace does not > setup > uid/gid mappings? > lxc-enter-namespace doesn't have the need to setup uid/gid mappings, Since lxc-enter-namespace is running on the host side, the uid/gid mappings already exist, But we should call s
Re: [libvirt] [PATCH v3 00/12] Add user namespace support for libvirt lxc
Am 11.06.2013 08:17, schrieb Gao feng: On 06/11/2013 02:02 PM, Richard Weinberger wrote: Am 11.06.2013 05:12, schrieb Gao feng: On 06/11/2013 04:51 AM, Richard Weinberger wrote: Am 10.06.2013 21:53, schrieb Richard Weinberger: Am 10.06.2013 21:17, schrieb Richard Weinberger: Hi! Am 04.06.2013 13:03, schrieb Daniel P. Berrange: It's still under review. needs some ACK. If you can help to test or ACK this patchset, it will be very helpful. :) Actually, I just want to ping... I've been away on holiday for 2 weeks, so not had a chance to review it yet. I'll get to it this week. I hope we'll get this in the 1.0.6 release this month. Finally I've found some time to test version 4 of the userns patch set. But I'm unable to create a container. ---cut--- linux:~ # LANG=C /opt/libvirt/bin/virsh -c lxc:/// create c1.conf error: Failed to create domain from c1.conf error: Interner Fehler guest failed to start: PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=3f86c48b-b027-4838-ba17-6202a1d7398b LIBVIRT_LXC_UUID=3f86c48b-b027-4838-ba17-6202a1d7398b LIBVIRT_LXC_NAME=c1 /bin/bash error receiving signal from container: Input/output error ---cut--- lxcContainerWaitForContinue() in src/lxc/lxc_controller.c fails with EIO. Maybe because the clone()'ed child dies and the file descriptor used for synchronization becomes invalid. Here my container config: ---cut--- c1 102400 exe /bin/bash ---cut--- Any ideas how to debug this further? This is Linux 3.9.0 with all namespaces enabled. Whoops, forgot to add the libvirtd debug output: ---cut--- 2013-06-10 19:41:24.661+: 29211: debug : virCommandRunAsync:2241 : About to run PATH=/usr/lib64/mpi/gcc/openmpi/bin:/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr /opt/libvirt/lib/libvirt_lxc --name c1 --console 20 --security=none --handshake 23 --background 2013-06-10 19:41:24.663+: 29211: debug : virFileClose:90 : Closed fd 24 2013-06-10 19:41:24.663+: 29211: debug : virCommandRunAsync:2246 : Command result 0, with PID 29303 2013-06-10 19:41:24.664+: 29303: debug : virFileClose:90 : Closed fd 3 2013-06-10 19:41:24.665+: 29303: debug : virFileClose:90 : Closed fd 4 2013-06-10 19:41:24.666+: 29303: debug : virFileClose:90 : Closed fd 5 2013-06-10 19:41:24.666+: 29303: debug : virFileClose:90 : Closed fd 6 2013-06-10 19:41:24.667+: 29303: debug : virFileClose:90 : Closed fd 7 2013-06-10 19:41:24.667+: 29303: debug : virFileClose:90 : Closed fd 8 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 9 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 10 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 11 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 12 2013-06-10 19:41:24.668+: 29303: debug : virFileClose:90 : Closed fd 13 2013-06-10 19:41:24.669+: 29303: debug : virFileClose:90 : Closed fd 14 2013-06-10 19:41:24.669+: 29303: debug : virFileClose:90 : Closed fd 15 2013-06-10 19:41:24.670+: 29303: debug : virFileClose:90 : Closed fd 16 2013-06-10 19:41:24.670+: 29303: debug : virFileClose:90 : Closed fd 17 2013-06-10 19:41:24.670+: 29303: debug : virFileClose:90 : Closed fd 18 2013-06-10 19:41:24.671+: 29303: debug : virFileClose:90 : Closed fd 19 2013-06-10 19:41:24.671+: 29303: debug : virFileClose:90 : Closed fd 22 2013-06-10 19:41:24.790+: 29211: debug : virCommandRun:2115 : Result status 0, stdout: '(null)' stderr: '(null)' ---cut--- Looks like libvirt_lxc was executed and died silently. Found the problem. /opt/libvirt/var/log/libvirt/lxc/c1.log contained the info I needed. Search permissions for /root were missing. m( Would be nice if virsh would be able to tell one this... :) have fun with user namespace & libvirt. And thanks for your test. Yeah. So far it looks very good. I was able to convert my containers from my custom lxc/userns setup to libvirt+userns. One more question, is it by design that virsh lxc-enter-namespace does not setup uid/gid mappings? lxc-enter-namespace doesn't have the need to setup uid/gid mappings, Since lxc-enter-namespace is running on the host side, the uid/gid mappings already exist, But we should call setid for the child task of lxc-enter-namespace, this child task running in the container. I will improve lxc-enter-namespace after this patchset being accepted. This makes sense. As of now I'm using su to become uid 0. Thanks, //richard -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] LXC: Allow to input relative path of program for lxc-enter-namespace
User execvp to replace execv, so user can use
relative path to exec programs in container.
Such as "lxc-enter-namespace domain ls"
And the user can still use absolute path to
exec programs.
Signed-off-by: Gao feng
---
tools/virsh-domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 955e882..8161b23 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -7902,7 +7902,7 @@ cmdLxcEnterNamespace(vshControl *ctl, const vshCmd *cmd)
if (virFork(&pid) < 0)
_exit(255);
if (pid == 0) {
-execv(cmdargv[0], cmdargv);
+execvp(cmdargv[0], cmdargv);
_exit(255);
} else {
if (virProcessWait(pid, NULL) < 0)
--
1.8.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for v1.0.5-maint] Fix use of VIR_STRDUP vs strdup
On 06/10/2013 03:54 PM, Cole Robinson wrote: > > Whoops, I just pushed your patch to the maint branch before I saw your and > Jan's responses. Thanks, now I don't feel so bad for failing to mention that the patch is missing virReportOOMError :) Jan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/2] Resolve issues seen with schedinfo
On 10.06.2013 18:06, John Ferlan wrote: > These patches resolve an issue seen using 'virsh schedinfo ' on a > non running domain that have been present since 1.0.4 as a result of the > cgroup infrastructure changes: > > https://www.redhat.com/archives/libvir-list/2013-April/msg00783.html > > The exact commit id that caused the issue is listed in each of the commit > messages. I used git bisect to determine, although it was tricky because > the TPM changes were made around the same time and required commit '8b934a5c' > to be applied in order to actually see domains on my host. > > Prior to the changes the "CFS Bandwidth" data was obtained since the driver > cgroup was mounted as opposed to the changes from the above set which mount > cgroups when the domain is running. > > The result for 'virsh schedinfo ' for a non running guest is to > return the configuration data for default, --config, and --current options. > The --live option reports a failure. For a running guest, default, --live, > and --current report values from cgroup, while --config reports only the > configuration values. > > This issue also affects the libvirt-cim code in how it defines QEMU domains. > Fortunately it only looks for the "cpu_shares" value. > > Difference to v1: > - In the [qemu|lxc]DomainGetSchedulerType() API's, rather than check for >priv->cgroup, check if the domain is running and return defaults if not > - In the [qemu|lxc]DomainGetSchedulerParametersFlags() API's, if we're >only returning configuration data, then don't gate the result returned >on the CFS bandwidth data cgroup availability. > > qemu: Resolve issue with GetScheduler APIs for non running domain > lxc: Resolve issue with GetScheduler APIs for non running domain > > src/lxc/lxc_driver.c | 11 ++- > src/qemu/qemu_driver.c | 11 ++- > 2 files changed, 20 insertions(+), 2 deletions(-) > ACK series. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] libxl: set bootloader for PV domains if not specified
On 10.06.2013 22:21, Jim Fehlig wrote:
> The legacy xen toolstack will set pygrub as the bootloader if not
> specified. For compatibility, do the same in the libxl driver
> iff not using direct kernel boot.
> ---
> src/libxl/libxl_conf.c | 13 +++--
> src/libxl/libxl_conf.h |1 +
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> index 90d563b..8b76536 100644
> --- a/src/libxl/libxl_conf.c
> +++ b/src/libxl/libxl_conf.c
> @@ -414,8 +414,17 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
> libxl_domain_config *d_config)
> b_info->shadow_memkb = 4 * (256 *
> libxl_bitmap_count_set(&b_info->avail_vcpus) +
> 2 * (b_info->max_memkb / 1024));
> } else {
> -if (VIR_STRDUP(b_info->u.pv.bootloader, def->os.bootloader) < 0)
> -goto error;
> +/*
> + * For compatibility with the legacy xen toolstack, default to pygrub
> + * if bootloader is not specified AND direct kernel boot is not
> specified.
> + */
> +if (def->os.bootloader) {
> +if (VIR_STRDUP(b_info->u.pv.bootloader, def->os.bootloader) < 0)
> +goto error;
> +} else if (def->os.kernel == NULL) {
> +if (VIR_STRDUP(b_info->u.pv.bootloader, LIBXL_BOOTLOADER_PATH) <
> 0)
> +goto error;
> +}
> if (def->os.bootloaderArgs) {
> if (!(b_info->u.pv.bootloader_args =
>virStringSplit(def->os.bootloaderArgs, " \t\n", 0)))
> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
> index 44ecd41..754fc40 100644
> --- a/src/libxl/libxl_conf.h
> +++ b/src/libxl/libxl_conf.h
> @@ -45,6 +45,7 @@
> # define LIBXL_LOG_DIR LOCALSTATEDIR "/log/libvirt/libxl"
> # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl"
> # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save"
> +# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub"
>
>
> typedef struct _libxlDriverPrivate libxlDriverPrivate;
>
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] libxl: Report connect type as Xen
On 10.06.2013 22:21, Jim Fehlig wrote:
> Currently, the libxl driver reports a connection type of "xenlight".
> To be compatible with the legacy Xen driver, it should return "Xen".
>
> Note: I noticed this while testing the libxl driver on OpenStack.
> After switching my Xen compute nodes to use the libxl stack, I
> could no longer launch instances on those nodes since
> hypervisor_type was reported as "xenlight" instead of "xen".
> ---
> src/libxl/libxl_driver.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index 3990354..935919b 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -1405,7 +1405,7 @@ libxlConnectClose(virConnectPtr conn ATTRIBUTE_UNUSED)
> static const char *
> libxlConnectGetType(virConnectPtr conn ATTRIBUTE_UNUSED)
> {
> -return "xenlight";
> +return "Xen";
> }
>
> static int
>
I am not so convinced about this one. I think there exist some
applications which want to distinguish between "Xen" and "xenlight". If
a application (like Openstack) doesn't want, nothing is easier than:
type = virConnectGetType(conn);
if (!strcmp(type, "Xen") || !strcmp(type, "xenlight")) {
DoTheMagic();
} else {
ReportError("XEN not supported);
}
IOW I think this is an OpenStack bug, not a libvirt one.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] qemu: Forbid migration of machines with I/O errors
Such machine can't be successuflly migrated unles the I/O error has
recovered and might lead to data corruption. Forbid this kind of
migration.
---
src/qemu/qemu_migration.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 8e57521..97daaa0 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1423,6 +1423,7 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
virDomainObjPtr vm,
virDomainDefPtr def, bool remote)
{
int nsnapshots;
+int pauseReason;
bool forbid;
int i;
@@ -1445,6 +1446,15 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
virDomainObjPtr vm,
nsnapshots);
return false;
}
+
+/* cancel migration if disk I/O error is emitted while migrating */
+if (virDomainObjGetState(vm, &pauseReason) == VIR_DOMAIN_PAUSED &&
+pauseReason == VIR_DOMAIN_PAUSED_IOERROR) {
+virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+ _("cannot migrate domain with I/O error"));
+return false;
+}
+
}
if (virDomainHasDiskMirror(vm)) {
--
1.8.2.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] qemu: Cancel/forbid migration on I/O error
When qemu has paused itself due to a I/O error it's not safe to migrate it as it still might contain state in kernel buffers. These patches forbid and cancel ongoing migration if a I/O error happens. Peter Krempa (2): qemu: Cancel migration if guest encoutners I/O error while migrating qemu: Forbid migration of machines with I/O errors src/qemu/qemu_migration.c | 31 +++ 1 file changed, 31 insertions(+) -- 1.8.2.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] qemu: Cancel migration if guest encoutners I/O error while migrating
During a live migration the guest may receive a disk access I/O error.
In this state the guest is unable to continue running on a remote host
after migration as some state may be present in the kernel and not
migrated.
With this patch, the migration is canceled in such case so it can either
continue on the source if the I/O issues are recovered or has to be
destroyed anyways.
---
src/qemu/qemu_migration.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index ca79bc2..8e57521 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1686,6 +1686,7 @@ qemuMigrationWaitForCompletion(virQEMUDriverPtr driver,
virDomainObjPtr vm,
{
qemuDomainObjPrivatePtr priv = vm->privateData;
const char *job;
+int pauseReason;
switch (priv->job.asyncJob) {
case QEMU_ASYNC_JOB_MIGRATION_OUT:
@@ -1707,6 +1708,12 @@ qemuMigrationWaitForCompletion(virQEMUDriverPtr driver,
virDomainObjPtr vm,
/* Poll every 50ms for progress & to allow cancellation */
struct timespec ts = { .tv_sec = 0, .tv_nsec = 50 * 1000 * 1000ull };
+/* cancel migration if disk I/O error is emitted while migrating */
+if (priv->job.asyncJob == QEMU_ASYNC_JOB_MIGRATION_OUT &&
+virDomainObjGetState(vm, &pauseReason) == VIR_DOMAIN_PAUSED &&
+pauseReason == VIR_DOMAIN_PAUSED_IOERROR)
+goto cancel;
+
if (qemuMigrationUpdateJobStatus(driver, vm, job, asyncJob) < 0)
goto cleanup;
@@ -1728,6 +1735,20 @@ cleanup:
return 0;
else
return -1;
+
+cancel:
+if (virDomainObjIsActive(vm)) {
+if (qemuDomainObjEnterMonitorAsync(driver, vm,
+ priv->job.asyncJob) == 0) {
+qemuMonitorMigrateCancel(priv->mon);
+qemuDomainObjExitMonitor(driver, vm);
+}
+}
+
+priv->job.info.type = VIR_DOMAIN_JOB_FAILED;
+virReportError(VIR_ERR_OPERATION_FAILED,
+ _("%s: %s"), job, _("failed due to I/O error"));
+return -1;
}
--
1.8.2.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu_migrate: Dispose listen address if set from config
On 06/10/13 19:38, Michal Privoznik wrote: https://bugzilla.redhat.com/show_bug.cgi?id=971485 As of d7f9d827531bc843b7c5aa9d3e8c08738a1de248 we copy the listen address from the qemu.conf config file in case none has been provided via XML. But later, when migrating, we should not include such listen address in the migratable XML as it is something autogenerated, not requested by user. Moreover, the binding to the listen address will likely fail, unless the address is '0.0.0.0' or its IPv6 equivalent. This patch introduces a new boolean attribute to virDomainGraphicsListenDef to distinguish autofilled listen addresses. However, we must keep the attribute over libvirtd restarts, so it must be kept within status XML. --- src/conf/domain_conf.c | 28 src/conf/domain_conf.h | 1 + src/qemu/qemu_process.c | 1 + 3 files changed, 30 insertions(+) ACK. I think it would be possible to add a test that would check the XML generator for this case so that it doesn't happen again. Have a look please if it's easy to do. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] selinux: assume 's0' if the range is empty
On 06/10/13 14:43, Ján Tomko wrote: This fixes a crash: https://bugzilla.redhat.com/show_bug.cgi?id=969878 --- v3: rewrote the patch to assume 's0' if the range is empty, instead of reporting an error v2: https://www.redhat.com/archives/libvir-list/2013-June/msg00082.html src/security/security_selinux.c | 9 +++-- tests/securityselinuxtest.c | 6 ++ 2 files changed, 13 insertions(+), 2 deletions(-) ACK. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] selinux: assume 's0' if the range is empty
On 06/11/2013 12:23 PM, Peter Krempa wrote: > On 06/10/13 14:43, Ján Tomko wrote: >> This fixes a crash: >> https://bugzilla.redhat.com/show_bug.cgi?id=969878 >> --- >> v3: >> rewrote the patch to assume 's0' if the range is empty, instead >> of reporting an error >> >> v2: >> https://www.redhat.com/archives/libvir-list/2013-June/msg00082.html >> >> src/security/security_selinux.c | 9 +++-- >> tests/securityselinuxtest.c | 6 ++ >> 2 files changed, 13 insertions(+), 2 deletions(-) >> > > ACK. > > Peter > Thanks, pushed now. Jan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Fix memory leak in Prepare phase
On Mon, Jun 10, 2013 at 15:29:03 +0200, Jano Tomko wrote: > On 06/07/2013 02:14 PM, Jiri Denemark wrote: > > Avoid leaking virDomainDef if Prepare phase fails before it gets to > > qemuMigrationPrepareAny. > > --- > > src/qemu/qemu_driver.c| 12 > > src/qemu/qemu_migration.c | 29 ++--- > > src/qemu/qemu_migration.h | 4 ++-- > > 3 files changed, 20 insertions(+), 25 deletions(-) > > > > ACK Pushed, thanks. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] AttributeError in virConnect.__del__ at program exit
Hi,
using vdsm python code, I've the following error at program exit that
seems to be related to libvirt python code, something wrong in a destructor:
Exception AttributeError: AttributeError("virConnect instance has no
attribute 'domainEventCallbacks'",) in > ignored
I'm using libvirt 1.0.6
Is it a known issue? Is there any workaround / fix ?
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] qemu: Cancel migration if guest encoutners I/O error while migrating
On 11.06.2013 11:49, Peter Krempa wrote:
> During a live migration the guest may receive a disk access I/O error.
I'd reword this: ... may receive an I/O error while accessing a disk.
> In this state the guest is unable to continue running on a remote host
> after migration as some state may be present in the kernel and not
> migrated.
>
> With this patch, the migration is canceled in such case so it can either
> continue on the source if the I/O issues are recovered or has to be
> destroyed anyways.
> ---
> src/qemu/qemu_migration.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index ca79bc2..8e57521 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -1686,6 +1686,7 @@ qemuMigrationWaitForCompletion(virQEMUDriverPtr driver,
> virDomainObjPtr vm,
> {
> qemuDomainObjPrivatePtr priv = vm->privateData;
> const char *job;
> +int pauseReason;
>
> switch (priv->job.asyncJob) {
> case QEMU_ASYNC_JOB_MIGRATION_OUT:
> @@ -1707,6 +1708,12 @@ qemuMigrationWaitForCompletion(virQEMUDriverPtr
> driver, virDomainObjPtr vm,
> /* Poll every 50ms for progress & to allow cancellation */
> struct timespec ts = { .tv_sec = 0, .tv_nsec = 50 * 1000 * 1000ull };
>
> +/* cancel migration if disk I/O error is emitted while migrating */
> +if (priv->job.asyncJob == QEMU_ASYNC_JOB_MIGRATION_OUT &&
> +virDomainObjGetState(vm, &pauseReason) == VIR_DOMAIN_PAUSED &&
> +pauseReason == VIR_DOMAIN_PAUSED_IOERROR)
> +goto cancel;
> +
> if (qemuMigrationUpdateJobStatus(driver, vm, job, asyncJob) < 0)
> goto cleanup;
>
> @@ -1728,6 +1735,20 @@ cleanup:
> return 0;
> else
> return -1;
> +
> +cancel:
> +if (virDomainObjIsActive(vm)) {
> +if (qemuDomainObjEnterMonitorAsync(driver, vm,
> + priv->job.asyncJob) == 0) {
> +qemuMonitorMigrateCancel(priv->mon);
> +qemuDomainObjExitMonitor(driver, vm);
> +}
> +}
> +
> +priv->job.info.type = VIR_DOMAIN_JOB_FAILED;
> +virReportError(VIR_ERR_OPERATION_FAILED,
> + _("%s: %s"), job, _("failed due to I/O error"));
> +return -1;
> }
>
>
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] qemu: Forbid migration of machines with I/O errors
On 11.06.2013 11:49, Peter Krempa wrote:
> Such machine can't be successuflly migrated unles the I/O error has
> recovered and might lead to data corruption. Forbid this kind of
> migration.
> ---
> src/qemu/qemu_migration.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 8e57521..97daaa0 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -1423,6 +1423,7 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
> virDomainObjPtr vm,
> virDomainDefPtr def, bool remote)
> {
> int nsnapshots;
> +int pauseReason;
> bool forbid;
> int i;
>
> @@ -1445,6 +1446,15 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
> virDomainObjPtr vm,
> nsnapshots);
> return false;
> }
> +
> +/* cancel migration if disk I/O error is emitted while migrating
> */
> +if (virDomainObjGetState(vm, &pauseReason) == VIR_DOMAIN_PAUSED
> &&
> +pauseReason == VIR_DOMAIN_PAUSED_IOERROR) {
> +virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> + _("cannot migrate domain with I/O error"));
> +return false;
> +}
> +
> }
>
> if (virDomainHasDiskMirror(vm)) {
>
Do we want to document this behaviour change?
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] qemu: Forbid migration of machines with I/O errors
On 06/11/13 14:05, Michal Privoznik wrote:
On 11.06.2013 11:49, Peter Krempa wrote:
Such machine can't be successuflly migrated unles the I/O error has
recovered and might lead to data corruption. Forbid this kind of
migration.
---
src/qemu/qemu_migration.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 8e57521..97daaa0 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1423,6 +1423,7 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
virDomainObjPtr vm,
virDomainDefPtr def, bool remote)
{
int nsnapshots;
+int pauseReason;
bool forbid;
int i;
@@ -1445,6 +1446,15 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
virDomainObjPtr vm,
nsnapshots);
return false;
}
+
+/* cancel migration if disk I/O error is emitted while migrating */
+if (virDomainObjGetState(vm, &pauseReason) == VIR_DOMAIN_PAUSED &&
+pauseReason == VIR_DOMAIN_PAUSED_IOERROR) {
+virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+ _("cannot migrate domain with I/O error"));
+return false;
+}
+
}
if (virDomainHasDiskMirror(vm)) {
Do we want to document this behaviour change?
How about:
diff --git a/src/libvirt.c b/src/libvirt.c
index 620dbdd..6413a1e 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -5809,41 +5809,42 @@ error:
* guest ABI,
*
* If a hypervisor supports renaming domains during migration,
* the dname parameter specifies the new name for the domain.
* Setting dname to NULL keeps the domain name the same. If domain
* renaming is not supported by the hypervisor, dname must be NULL or
* else an error will be returned.
*
* The maximum bandwidth (in MiB/s) that will be used to do migration
* can be specified with the bandwidth parameter. If set to 0,
* libvirt will choose a suitable default. Some hypervisors do
* not support this feature and will return an error if bandwidth
* is not 0.
*
* To see which features are supported by the current hypervisor,
* see virConnectGetCapabilities, /capabilities/host/migration_features.
*
* There are many limitations on migration imposed by the underlying
* technology - for example it may not be possible to migrate between
* different processors even with the same architecture, or between
- * different types of hypervisor.
+ * different types of hypervisor. Migration of domains that encountered
+ * errors may not be possible.
*
* Returns 0 if the migration succeeded, -1 upon error.
*/
int
virDomainMigrateToURI2(virDomainPtr domain,
const char *dconnuri,
const char *miguri,
const char *dxml,
unsigned long flags,
const char *dname,
unsigned long bandwidth)
{
VIR_DOMAIN_DEBUG(domain, "dconnuri=%s, miguri=%s, dxml=%s, "
"flags=%lx, dname=%s, bandwidth=%lu",
NULLSTR(dconnuri), NULLSTR(miguri), NULLSTR(dxml),
flags, NULLSTR(dname), bandwidth);
virResetLastError();
/* First checkout the source */
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] qemu: Forbid migration of machines with I/O errors
On 11.06.2013 14:39, Peter Krempa wrote:
> On 06/11/13 14:05, Michal Privoznik wrote:
>> On 11.06.2013 11:49, Peter Krempa wrote:
>>> Such machine can't be successuflly migrated unles the I/O error has
>>> recovered and might lead to data corruption. Forbid this kind of
>>> migration.
>>> ---
>>> src/qemu/qemu_migration.c | 10 ++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
>>> index 8e57521..97daaa0 100644
>>> --- a/src/qemu/qemu_migration.c
>>> +++ b/src/qemu/qemu_migration.c
>>> @@ -1423,6 +1423,7 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
>>> virDomainObjPtr vm,
>>> virDomainDefPtr def, bool remote)
>>> {
>>> int nsnapshots;
>>> +int pauseReason;
>>> bool forbid;
>>> int i;
>>>
>>> @@ -1445,6 +1446,15 @@ qemuMigrationIsAllowed(virQEMUDriverPtr
>>> driver, virDomainObjPtr vm,
>>> nsnapshots);
>>> return false;
>>> }
>>> +
>>> +/* cancel migration if disk I/O error is emitted while
>>> migrating */
>>> +if (virDomainObjGetState(vm, &pauseReason) ==
>>> VIR_DOMAIN_PAUSED &&
>>> +pauseReason == VIR_DOMAIN_PAUSED_IOERROR) {
>>> +virReportError(VIR_ERR_OPERATION_INVALID, "%s",
>>> + _("cannot migrate domain with I/O
>>> error"));
>>> +return false;
>>> +}
>>> +
>>> }
>>>
>>> if (virDomainHasDiskMirror(vm)) {
>>>
>>
>> Do we want to document this behaviour change?
>
> How about:
>
> diff --git a/src/libvirt.c b/src/libvirt.c
> index 620dbdd..6413a1e 100644
> --- a/src/libvirt.c
> +++ b/src/libvirt.c
> @@ -5809,41 +5809,42 @@ error:
> * guest ABI,
> *
> * If a hypervisor supports renaming domains during migration,
> * the dname parameter specifies the new name for the domain.
> * Setting dname to NULL keeps the domain name the same. If domain
> * renaming is not supported by the hypervisor, dname must be NULL or
> * else an error will be returned.
> *
> * The maximum bandwidth (in MiB/s) that will be used to do migration
> * can be specified with the bandwidth parameter. If set to 0,
> * libvirt will choose a suitable default. Some hypervisors do
> * not support this feature and will return an error if bandwidth
> * is not 0.
> *
> * To see which features are supported by the current hypervisor,
> * see virConnectGetCapabilities, /capabilities/host/migration_features.
> *
> * There are many limitations on migration imposed by the underlying
> * technology - for example it may not be possible to migrate between
> * different processors even with the same architecture, or between
> - * different types of hypervisor.
> + * different types of hypervisor. Migration of domains that encountered
> + * errors may not be possible.
And continue with: "Moreover, in case of I/O error, depending on
hypervisor the migration may be canceled."
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] doc: Explicitly document migration limitations on errors
Migration of guests that are in error state for example because of I/O errors may not be possible and encountering of such errors may lead to cancellation of such migration. Document this behavior explicitly. --- src/libvirt.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 620dbdd..1bdd193 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -5196,7 +5196,10 @@ virDomainMigrateDirect(virDomainPtr domain, * There are many limitations on migration imposed by the underlying * technology - for example it may not be possible to migrate between * different processors even with the same architecture, or between - * different types of hypervisor. + * different types of hypervisor. A domain may not be migratable + * because of configuration or error states. A domain may become + * unmigratable during migration. This will cancel the ongoing + * migration. * * Returns the new domain object if the migration was successful, * or NULL in case of error. Note that the new domain object @@ -5423,7 +5426,10 @@ error: * There are many limitations on migration imposed by the underlying * technology - for example it may not be possible to migrate between * different processors even with the same architecture, or between - * different types of hypervisor. + * different types of hypervisor. A domain may not be migratable + * because of configuration or error states. A domain may become + * unmigratable during migration. This will cancel the ongoing + * migration. * * If the hypervisor supports it, @dxml can be used to alter * host-specific portions of the domain XML that will be used on @@ -5664,7 +5670,10 @@ error: * There are many limitations on migration imposed by the underlying * technology - for example it may not be possible to migrate between * different processors even with the same architecture, or between - * different types of hypervisor. + * different types of hypervisor. A domain may not be migratable + * because of configuration or error states. A domain may become + * unmigratable during migration. This will cancel the ongoing + * migration. * * Returns 0 if the migration succeeded, -1 upon error. */ @@ -5826,7 +5835,10 @@ error: * There are many limitations on migration imposed by the underlying * technology - for example it may not be possible to migrate between * different processors even with the same architecture, or between - * different types of hypervisor. + * different types of hypervisor. A domain may not be migratable + * because of configuration or error states. A domain may become + * unmigratable during migration. This will cancel the ongoing + * migration. * * Returns 0 if the migration succeeded, -1 upon error. */ -- 1.8.2.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: allow restore with non-migratable XML input
Convert input XML to migratable before using it in
qemuDomainSaveImageOpen.
XML in the save image is migratable, i.e. doesn't contain implicit
controllers. If these controllers were in a non-default order in the
input XML, the ABI check would fail. Removing and re-adding these
controllers fixes it.
https://bugzilla.redhat.com/show_bug.cgi?id=834196
---
src/qemu/qemu_domain.c | 29 +
src/qemu/qemu_domain.h | 4
src/qemu/qemu_driver.c | 13 ++---
3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index fdcf7bc..8d79066 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1275,6 +1275,35 @@ void qemuDomainObjExitRemote(virDomainObjPtr obj)
}
+virDomainDefPtr
+qemuDomainDefCopy(virQEMUDriverPtr driver,
+ virDomainDefPtr src,
+ unsigned int flags)
+{
+virBuffer buf = VIR_BUFFER_INITIALIZER;
+virDomainDefPtr ret = NULL;
+virCapsPtr caps = NULL;
+const char *xml = NULL;
+
+if (qemuDomainDefFormatBuf(driver, src, flags, &buf) < 0)
+goto cleanup;
+
+xml = virBufferContentAndReset(&buf);
+
+if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
+goto cleanup;
+
+if (!(ret = virDomainDefParseString(xml, caps, driver->xmlopt,
+QEMU_EXPECTED_VIRT_TYPES,
+VIR_DOMAIN_XML_INACTIVE)))
+goto cleanup;
+
+cleanup:
+VIR_FREE(xml);
+virObjectUnref(caps);
+return ret;
+}
+
int
qemuDomainDefFormatBuf(virQEMUDriverPtr driver,
virDomainDefPtr def,
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index f241296..068a4c3 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -241,6 +241,10 @@ void qemuDomainObjEnterRemote(virDomainObjPtr obj)
void qemuDomainObjExitRemote(virDomainObjPtr obj)
ATTRIBUTE_NONNULL(1);
+virDomainDefPtr qemuDomainDefCopy(virQEMUDriverPtr driver,
+ virDomainDefPtr src,
+ unsigned int flags);
+
int qemuDomainDefFormatBuf(virQEMUDriverPtr driver,
virDomainDefPtr vm,
unsigned int flags,
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index c886378..93c7d14 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -4877,17 +4877,24 @@ qemuDomainSaveImageOpen(virQEMUDriverPtr driver,
goto error;
if (xmlin) {
virDomainDefPtr def2 = NULL;
+virDomainDefPtr newdef = NULL;
if (!(def2 = virDomainDefParseString(xmlin, caps, driver->xmlopt,
QEMU_EXPECTED_VIRT_TYPES,
VIR_DOMAIN_XML_INACTIVE)))
goto error;
-if (!virDomainDefCheckABIStability(def, def2)) {
-virDomainDefFree(def2);
+
+newdef = qemuDomainDefCopy(driver, def2, VIR_DOMAIN_XML_MIGRATABLE);
+virDomainDefFree(def2);
+if (!newdef)
+goto error;
+
+if (!virDomainDefCheckABIStability(def, newdef)) {
+virDomainDefFree(newdef);
goto error;
}
virDomainDefFree(def);
-def = def2;
+def = newdef;
}
VIR_FREE(xml);
--
1.8.1.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] libxl: Report connect type as Xen
Michal Privoznik wrote:
> On 10.06.2013 22:21, Jim Fehlig wrote:
>
>> Currently, the libxl driver reports a connection type of "xenlight".
>> To be compatible with the legacy Xen driver, it should return "Xen".
>>
>> Note: I noticed this while testing the libxl driver on OpenStack.
>> After switching my Xen compute nodes to use the libxl stack, I
>> could no longer launch instances on those nodes since
>> hypervisor_type was reported as "xenlight" instead of "xen".
>> ---
>> src/libxl/libxl_driver.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>> index 3990354..935919b 100644
>> --- a/src/libxl/libxl_driver.c
>> +++ b/src/libxl/libxl_driver.c
>> @@ -1405,7 +1405,7 @@ libxlConnectClose(virConnectPtr conn ATTRIBUTE_UNUSED)
>> static const char *
>> libxlConnectGetType(virConnectPtr conn ATTRIBUTE_UNUSED)
>> {
>> -return "xenlight";
>> +return "Xen";
>> }
>>
>> static int
>>
>>
>
> I am not so convinced about this one. I think there exist some
> applications which want to distinguish between "Xen" and "xenlight".
If that was the case, we would have went with a libxl:// URI. In fact,
the original libxl driver patch introduced a libxl:// URI, but Daniel V.
pointed out that approach conflicted with libvirt's goal of minimizing
the impact on application stacks as the lower layers churn
https://www.redhat.com/archives/libvir-list/2011-March/msg00449.html
> If
> a application (like Openstack) doesn't want, nothing is easier than:
>
> type = virConnectGetType(conn);
> if (!strcmp(type, "Xen") || !strcmp(type, "xenlight")) {
>DoTheMagic();
> } else {
>ReportError("XEN not supported);
> }
>
Yes, but every app would have to do that, all because some lower layer
tool was reworked.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix F_DUPFD_CLOEXEC operation args
Il 03/05/2013 06:12, Daniel P. Berrange ha scritto:
> From: "Daniel P. Berrange"
>
> The F_DUPFD_CLOEXEC operation with fcntl() expects a single
> int argument, specifying the minimum FD number for the newly
> dup'd file descriptor. We were not specifying that causing
> random stack data to be accessed as the FD number. Sometimes
> that worked, sometimes it didn't.
>
> Signed-off-by: Daniel P. Berrange
> ---
> src/rpc/virnetsocket.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
> index e950d7f..dcf98b1 100644
> --- a/src/rpc/virnetsocket.c
> +++ b/src/rpc/virnetsocket.c
> @@ -1055,7 +1055,7 @@ int virNetSocketDupFD(virNetSocketPtr sock, bool
> cloexec)
> int fd;
>
> if (cloexec)
> -fd = fcntl(sock->fd, F_DUPFD_CLOEXEC);
> +fd = fcntl(sock->fd, F_DUPFD_CLOEXEC, 0);
> else
> fd = dup(sock->fd);
> if (fd < 0) {
>
Hi Cole,
can you add this to 1.0.5-maint please?
Thanks!
Paolo
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] qemu: Cancel/forbid migration on I/O error
Il 11/06/2013 05:49, Peter Krempa ha scritto: > When qemu has paused itself due to a I/O error it's not safe to migrate it > as it still might contain state in kernel buffers. These patches forbid and > cancel ongoing migration if a I/O error happens. > > Peter Krempa (2): > qemu: Cancel migration if guest encoutners I/O error while migrating > qemu: Forbid migration of machines with I/O errors > > src/qemu/qemu_migration.c | 31 +++ > 1 file changed, 31 insertions(+) > This actually should be supported, it certainly is in QEMU. What kind of state is in the kernel and what is the BZ for this patch? When a system call returns, it should be all done. Paolo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirtd 1.0.6 refuses to start
I just downloaded and compiled libvirtd on the same server as I did 1.0.4. Upon updating, libvirtd refuses to start, with this in the logfile (obfuscated the hostname by xxx's): 2013-06-11 13:43:49.154+: 3336: info : libvirt version: 1.0.6, package: 1.el6 (Unknown, 2013-06-06-14:57:07, ) 2013-06-11 13:43:49.154+: 3336: error : virFileReadAll:1195 : Failed to open file '/sys/class/fc_host//host0/max_npiv_vports': No such file or directory 2013-06-11 13:43:49.159+: 3336: error : detect_scsi_host_caps:87 : Failed to read max_npiv_vports for host1 2013-06-11 13:43:49.163+: 3336: error : virFileReadAll:1195 : Failed to open file '/sys/class/fc_host//host0/max_npiv_vports': No such file or directory 2013-06-11 13:43:49.163+: 3336: error : detect_scsi_host_caps:87 : Failed to read max_npiv_vports for host2 2013-06-11 13:43:49.386+: 3336: error : virLockManagerPluginNew:175 : Failed to load plugin /usr/lib64/libvirt/lock-driver/lockd.so: /usr/lib64/libvirt/lock-driver/lockd.so: undefined symbol: virProcessGetStartTime 2013-06-11 13:43:49.386+: 3336: error : virStateInitialize:831 : Initialization of QEMU state driver failed 2013-06-11 13:43:49.386+: 3336: error : daemonRunStateInit:887 : Driver state initialization failed So it seems two issues are present here: 1) it searches for /sys/class/fc_host//host0/max_npiv_vports for both host1 and host2. Imho this path needs to be /sys/class/fc_host//host1/max_npiv_vports and /sys/class/fc_host//host2/max_npiv_vports respectively. 2) the undefined symbol problem: seems a linking issue, no? The build worked just fine on rhel6 with all patches applied. For now I reverted back to 1.0.4. Hope this helps to debug :-) Also: I created a bug report for 1.0.4/1.0.6 concerning the init scripts: https://bugzilla.redhat.com/show_bug.cgi?id=971408 Part of it (the virtlock socket) seems to be in the latest code already, but I believe the other issues mentioned are valid as well. With friendly regards, Franky -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix F_DUPFD_CLOEXEC operation args
On 06/11/2013 10:51 AM, Paolo Bonzini wrote:
> Il 03/05/2013 06:12, Daniel P. Berrange ha scritto:
>> From: "Daniel P. Berrange"
>>
>> The F_DUPFD_CLOEXEC operation with fcntl() expects a single
>> int argument, specifying the minimum FD number for the newly
>> dup'd file descriptor. We were not specifying that causing
>> random stack data to be accessed as the FD number. Sometimes
>> that worked, sometimes it didn't.
>>
>> Signed-off-by: Daniel P. Berrange
>> ---
>> src/rpc/virnetsocket.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
>> index e950d7f..dcf98b1 100644
>> --- a/src/rpc/virnetsocket.c
>> +++ b/src/rpc/virnetsocket.c
>> @@ -1055,7 +1055,7 @@ int virNetSocketDupFD(virNetSocketPtr sock, bool
>> cloexec)
>> int fd;
>>
>> if (cloexec)
>> -fd = fcntl(sock->fd, F_DUPFD_CLOEXEC);
>> +fd = fcntl(sock->fd, F_DUPFD_CLOEXEC, 0);
>> else
>> fd = dup(sock->fd);
>> if (fd < 0) {
>>
>
> Hi Cole,
>
> can you add this to 1.0.5-maint please?
>
As mentioned on IRC, looks like this is already in 1.0.5-maint and was
released in 1.0.5.1
- Cole
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] doc: Explicitly document migration limitations on errors
On 11.06.2013 15:10, Peter Krempa wrote: > Migration of guests that are in error state for example because of I/O > errors may not be possible and encountering of such errors may lead to > cancellation of such migration. Document this behavior explicitly. > --- > src/libvirt.c | 20 > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/src/libvirt.c b/src/libvirt.c > index 620dbdd..1bdd193 100644 > --- a/src/libvirt.c > +++ b/src/libvirt.c > @@ -5196,7 +5196,10 @@ virDomainMigrateDirect(virDomainPtr domain, > * There are many limitations on migration imposed by the underlying > * technology - for example it may not be possible to migrate between > * different processors even with the same architecture, or between > - * different types of hypervisor. > + * different types of hypervisor. A domain may not be migratable > + * because of configuration or error states. A domain may become > + * unmigratable during migration. This will cancel the ongoing > + * migration. > * > * Returns the new domain object if the migration was successful, > * or NULL in case of error. Note that the new domain object > @@ -5423,7 +5426,10 @@ error: > * There are many limitations on migration imposed by the underlying > * technology - for example it may not be possible to migrate between > * different processors even with the same architecture, or between > - * different types of hypervisor. > + * different types of hypervisor. A domain may not be migratable > + * because of configuration or error states. A domain may become > + * unmigratable during migration. This will cancel the ongoing > + * migration. > * > * If the hypervisor supports it, @dxml can be used to alter > * host-specific portions of the domain XML that will be used on > @@ -5664,7 +5670,10 @@ error: > * There are many limitations on migration imposed by the underlying > * technology - for example it may not be possible to migrate between > * different processors even with the same architecture, or between > - * different types of hypervisor. > + * different types of hypervisor. A domain may not be migratable > + * because of configuration or error states. A domain may become > + * unmigratable during migration. This will cancel the ongoing > + * migration. > * > * Returns 0 if the migration succeeded, -1 upon error. > */ > @@ -5826,7 +5835,10 @@ error: > * There are many limitations on migration imposed by the underlying > * technology - for example it may not be possible to migrate between > * different processors even with the same architecture, or between > - * different types of hypervisor. > + * different types of hypervisor. A domain may not be migratable > + * because of configuration or error states. A domain may become > + * unmigratable during migration. This will cancel the ongoing > + * migration. > * > * Returns 0 if the migration succeeded, -1 upon error. > */ > ACK Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] libxl: Report connect type as Xen
On 11.06.2013 16:12, Jim Fehlig wrote:
> Michal Privoznik wrote:
>> On 10.06.2013 22:21, Jim Fehlig wrote:
>>
>>> Currently, the libxl driver reports a connection type of "xenlight".
>>> To be compatible with the legacy Xen driver, it should return "Xen".
>>>
>>> Note: I noticed this while testing the libxl driver on OpenStack.
>>> After switching my Xen compute nodes to use the libxl stack, I
>>> could no longer launch instances on those nodes since
>>> hypervisor_type was reported as "xenlight" instead of "xen".
>>> ---
>>> src/libxl/libxl_driver.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>>> index 3990354..935919b 100644
>>> --- a/src/libxl/libxl_driver.c
>>> +++ b/src/libxl/libxl_driver.c
>>> @@ -1405,7 +1405,7 @@ libxlConnectClose(virConnectPtr conn ATTRIBUTE_UNUSED)
>>> static const char *
>>> libxlConnectGetType(virConnectPtr conn ATTRIBUTE_UNUSED)
>>> {
>>> -return "xenlight";
>>> +return "Xen";
>>> }
>>>
>>> static int
>>>
>>>
>>
>> I am not so convinced about this one. I think there exist some
>> applications which want to distinguish between "Xen" and "xenlight".
>
> If that was the case, we would have went with a libxl:// URI. In fact,
> the original libxl driver patch introduced a libxl:// URI, but Daniel V.
> pointed out that approach conflicted with libvirt's goal of minimizing
> the impact on application stacks as the lower layers churn
>
> https://www.redhat.com/archives/libvir-list/2011-March/msg00449.html
Right, you certainly got a point there. But I'd like to see DV's input
in here then.
>
>> If
>> a application (like Openstack) doesn't want, nothing is easier than:
>>
>> type = virConnectGetType(conn);
>> if (!strcmp(type, "Xen") || !strcmp(type, "xenlight")) {
>>DoTheMagic();
>> } else {
>>ReportError("XEN not supported);
>> }
>>
>
> Yes, but every app would have to do that, all because some lower layer
> tool was reworked.
It wasn't reworked. It's here from initial introduction of libxl :)
>
> Regards,
> Jim
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] AttributeError in virConnect.__del__ at program exit
On 06/11/2013 07:58 AM, Sandro Bonazzola wrote:
> Hi,
> using vdsm python code, I've the following error at program exit that
> seems to be related to libvirt python code, something wrong in a destructor:
>
> Exception AttributeError: AttributeError("virConnect instance has no
> attribute 'domainEventCallbacks'",) in of > ignored
>
> I'm using libvirt 1.0.6
>
> Is it a known issue? Is there any workaround / fix ?
>
I've seen this too, sometimes via the virtinst test suite. Once upon a time I
tracked it down to whether the virtinst code did 'import selinux' or not, so
maybe it's a just some weird race, or a side effect of something other
libraries do in their cleanup path. By inspection alone the __del__ handler
doesn't seem to be doing anything wrong.
- Cole
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] libxl: Report connect type as Xen
Michal Privoznik wrote:
> On 11.06.2013 16:12, Jim Fehlig wrote:
>
>> Michal Privoznik wrote:
>>
>>> On 10.06.2013 22:21, Jim Fehlig wrote:
>>>
>>>
Currently, the libxl driver reports a connection type of "xenlight".
To be compatible with the legacy Xen driver, it should return "Xen".
Note: I noticed this while testing the libxl driver on OpenStack.
After switching my Xen compute nodes to use the libxl stack, I
could no longer launch instances on those nodes since
hypervisor_type was reported as "xenlight" instead of "xen".
---
src/libxl/libxl_driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 3990354..935919b 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -1405,7 +1405,7 @@ libxlConnectClose(virConnectPtr conn
ATTRIBUTE_UNUSED)
static const char *
libxlConnectGetType(virConnectPtr conn ATTRIBUTE_UNUSED)
{
-return "xenlight";
+return "Xen";
}
static int
>>> I am not so convinced about this one. I think there exist some
>>> applications which want to distinguish between "Xen" and "xenlight".
>>>
>> If that was the case, we would have went with a libxl:// URI. In fact,
>> the original libxl driver patch introduced a libxl:// URI, but Daniel V.
>> pointed out that approach conflicted with libvirt's goal of minimizing
>> the impact on application stacks as the lower layers churn
>>
>> https://www.redhat.com/archives/libvir-list/2011-March/msg00449.html
>>
>
> Right, you certainly got a point there. But I'd like to see DV's input
> in here then.
>
>
>>> If
>>> a application (like Openstack) doesn't want, nothing is easier than:
>>>
>>> type = virConnectGetType(conn);
>>> if (!strcmp(type, "Xen") || !strcmp(type, "xenlight")) {
>>>DoTheMagic();
>>> } else {
>>>ReportError("XEN not supported);
>>> }
>>>
>>>
>> Yes, but every app would have to do that, all because some lower layer
>> tool was reworked.
>>
>
> It wasn't reworked. It's here from initial introduction of libxl :)
>
I meant the reworking of xen tools, e.g. the replacement of xm/xend with
xl/libxl. libvirt apps should be insulated from these types of
infrastructure changes at the lower levels. I'd expect my libvirt apps
to continue working after a Xen upgrade, similar to how they continue to
work after installing a new qemu.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] VirtualBox 4.2 Support
Is there any active development to support VirtualBox 4.2 under libvirt? - DHC -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libxl: calculating free pages in libvirt
On gio, 2013-06-06 at 15:50 -0600, Jim Fehlig wrote: > Dario Faggioli wrote: > > On gio, 2013-06-06 at 14:59 +0100, Ian Campbell wrote: > >> This only really matters if libvirt wants to coexist on a host with > >> toolstacks which use claim, otherwise outstanding pages will never be > >> non-zero. I don't know if coexistence is a goal or not. > >> > >> > > Sure, all this is important only if having it is > > important/interesting... Jim? > > > > It would be preferable if libvirt and xl coexisted nicely. No need for > them to inter-operate (e.g. start a vm with libvirt then manage it with > xl), but managing some with xl and others with libvirt should be a goal, > I think :-/. If nothing else, it seems useful for troubleshooting. I > wouldn't want to advise a user to try xl when things are failing for > them with libvirt, only to find that afterwards their libvirt no longer > worked at all. > Mmm... I'm not entirely sure I understand what you mean by this, but anyway, I just submitted a patch to libxl adding the symbol necessary to determine whether that field is present or not. If it gets accepted, I can then patch libvirt to use it, within the proper #ifdef...#endif block, of course. Thanks everyone and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libxl: calculating free pages in libvirt
On Thu, Jun 06, 2013 at 03:53:13PM +0200, Dario Faggioli wrote: > Hi Jim, > > As I told you in Dublin, I'm looking into libvirt a bit, with the main > purpose of implementing the NUMA interface for the libxl driver. > > While at it I noticed that libxlNodeGetFreeMemory() uses the value > contained in phy_info.free_pages to check how many pages of free memory > we have. > > However, starting from (Xen's git) commit bec8f17e, the number of free > pages should be computed like this: > > (phy_info.free_pages - phy_info.outstanding_pages) > > to take the memory claiming mechanism introduced by Oracle properly into > account. You can see an example of that, for instance, looking at the > output_physinfo() function in tools/libxl/xl_cmdimpl.c (in the Xen > codebase, of course :-) ). > > Said commit is from last May, and the claim mechanism altogether --which > includes adding the outstanding_pages field to the libxl_physinfo struct > in libxl-- was introduced during the 4.3 development cycle. > > So, forgive the possibly dumb question, but what's the preferred way to > fix this in libvirt, without breaking build with old libxl versions? > (Provided this is something libvirt cares about, does it?) > > For other features added within this last dev cycle, libxl has a > `#define LIBXL_HAVE_' (e.g., LIBXL_HAVE_DOMAIN_NODEAFFINITY), but I > don't see one for this particular field... Konrad, Ian, am I missing it? > If no, should we add it? I think we missed it. I remember thinking about it, but I can't recall what I didn't submit. It certainly should be added. And I think that would fix the build of old libxl against new libvirt. Or vice-versa (if libxl supported the claim operation). > > Thanks and Regards, > Dario > > -- > <> (Raistlin Majere) > - > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Disabling bootmenu causes boot to skip over cdrom
Hello, I have domain with the following setup: - 1 VirtIO Disk - 1 VirtIO CDROM - 2 IDE CDROMs Now, depending on whether or not I have the bootmenu flag enabled, the boot sequence skips over booting from CDROM entirely (it does work if the bootmenu is enabled). This started happening after I added the VirtIO CDROM. Is this a bug or am I doing something wrong? Thanks, Keno Fischer -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Disabling bootmenu causes boot to skip over cdrom
On Sun, Jun 09, 2013 at 16:20:17 -0400, Keno Fischer wrote: > Hello, > > I have domain with the following setup: > - 1 VirtIO Disk > - 1 VirtIO CDROM > - 2 IDE CDROMs > > Now, depending on whether or not I have the bootmenu flag enabled, the boot > sequence skips over booting from CDROM entirely (it does work if the > bootmenu is enabled). > This started happening after I added the VirtIO CDROM. Is this a bug or am > I doing something wrong? Can you share the domain XMLs used in both cases with us? After starting the domain from each of the two XMLs, check /var/log/libvirt/qemu/$NAME.log for qemu command line that libvirt created and share them with us too. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Can we allow users in 'qemu' group to skip polkit auth?
There's a bug report filed against Fedora libvirt requesting a polkit rule be installed that grants read/write libvirt access to all users in the 'qemu' group: https://bugzilla.redhat.com/show_bug.cgi?id=957300 I'm inclined to agree with the reporter, and time has shown that many users install custom polkit rules to grant their user passwordless access to libvirt so this would definitely fill a need. I'm sure there's plenty to consider here since we are talking about security. Thoughts? Thanks, Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Can we allow users in 'qemu' group to skip polkit auth?
On Tue, Jun 11, 2013 at 17:11:12 -0400, Cole Robinson wrote: > There's a bug report filed against Fedora libvirt requesting a polkit rule be > installed that grants read/write libvirt access to all users in the 'qemu' > group: > > https://bugzilla.redhat.com/show_bug.cgi?id=957300 > > I'm inclined to agree with the reporter, and time has shown that many users > install custom polkit rules to grant their user passwordless access to libvirt > so this would definitely fill a need. > > I'm sure there's plenty to consider here since we are talking about security. > Thoughts? I don't know if it's a generally good idea or not being a polkit illiterate, however, I know for sure it should not be allowed for 'qemu' group. We certainly don't want QEMU (run as qemu:qemu) to be able to mess with libvirt. That said, if we should create a dedicated 'libvirt' group in case we implement the requested polkit rule. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] configure: Remove unused brctl check
brctl isn't used anywhere AFAICT --- configure.ac | 2 -- 1 file changed, 2 deletions(-) diff --git a/configure.ac b/configure.ac index 5d1bc6b..59a3d6d 100644 --- a/configure.ac +++ b/configure.ac @@ -318,8 +318,6 @@ AC_PATH_PROG([DNSMASQ], [dnsmasq], [dnsmasq], [/sbin:/usr/sbin:/usr/local/sbin:$PATH]) AC_PATH_PROG([RADVD], [radvd], [radvd], [/sbin:/usr/sbin:/usr/local/sbin:$PATH]) -AC_PATH_PROG([BRCTL], [brctl], [brctl], - [/sbin:/usr/sbin:/usr/local/sbin:$PATH]) AC_PATH_PROG([TC], [tc], [tc], [/sbin:/usr/sbin:/usr/local/sbin:$PATH]) AC_PATH_PROG([UDEVADM], [udevadm], [], -- 1.8.2.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt-php: 0.4.8 tag is missing
The libvirt-php 0.4.8 tar is missing from the git repo [1]. Hopefully someone who created the tarball can create the tag as well and push it. [1] http://libvirt.org/git/?p=libvirt-php.git Thanks. -- Doug Goldstein -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] configure: Remove unused brctl check
On 06/11/2013 06:07 PM, Cole Robinson wrote: > brctl isn't used anywhere AFAICT Too true. We switched to ioctls a long time ago. ACK. > --- > configure.ac | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 5d1bc6b..59a3d6d 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -318,8 +318,6 @@ AC_PATH_PROG([DNSMASQ], [dnsmasq], [dnsmasq], > [/sbin:/usr/sbin:/usr/local/sbin:$PATH]) > AC_PATH_PROG([RADVD], [radvd], [radvd], > [/sbin:/usr/sbin:/usr/local/sbin:$PATH]) > -AC_PATH_PROG([BRCTL], [brctl], [brctl], > - [/sbin:/usr/sbin:/usr/local/sbin:$PATH]) > AC_PATH_PROG([TC], [tc], [tc], > [/sbin:/usr/sbin:/usr/local/sbin:$PATH]) > AC_PATH_PROG([UDEVADM], [udevadm], [], -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VirtualBox 4.2 Support
Last activity I could find on this subject was here: https://www.redhat.com/archives/libvir-list/2013-May/msg01610.html Further activity here as well: https://www.redhat.com/archives/libvir-list/2013-June/msg00379.html I am willing to volunteer systems here to test libvirt+virtualbox 4.2 functionality. - DHC On Tue, Jun 11, 2013 at 1:12 PM, Dead Horse wrote: > Is there any active development to support VirtualBox 4.2 under libvirt? > > - DHC > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VirtualBox 4.2 Support
On Wednesday 12 June 2013 04:15:53 Dead Horse wrote: > Last activity I could find on this subject was > here: https://www.redhat.com/archives/libvir-list/2013-May/msg01610.html > Further activity here as well: > https://www.redhat.com/archives/libvir-list/2013-June/msg00379.html > > > I am willing to volunteer systems here to test libvirt+virtualbox 4.2 > functionality. > > - DHC > > > On Tue, Jun 11, 2013 at 1:12 PM, Dead Horse > > wrote: > > Is there any active development to support VirtualBox 4.2 under libvirt? > > > > - DHC Hello, Patches adding support for VirtualBox 4.2 were pushed to the libvirt git repository a few days ago. Instructions for cloning the repository and building libvirt are available on the libvirt website. Regards -- 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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
