Re: [libvirt] virsh -no-kvm problem on debian install
Daniel P. Berrange wrote: On Mon, Jun 22, 2009 at 12:18:44PM +0200, ChaosMedia WebDev wrote: Hi, i've installed lastest kvm-86 and libvirt-0.6.4 tarballs on my debian stable and have a problem using virsh No matter what i do in the guest domain config or with /usr/bin/ symlinks, libvirt keeps using the -no-kvm option when starting guests when my cpu has kvm-amd support, modules are loaded and /dev/kvm exists, and starting the guests thru command line works fine, and faster. These two shows libvirt knows about KVM, so the bug must be in the guest XML config. ... I suspect you've not got type='kvm' on the domain tag. Thx for the info, indeed i changed the domain type from qemu to kvm and the guess started without -no-kvm, so with kvm support. was domain type='qemu' id='5' is now domain type='kvm' id='5' I don't quite understand why it wasn't set to kvm in the first place, i did remember using some kvm option on virt-install command line when creating the guest. thx again i believe it fixed my problem i'll try to see if if can also apply to virt-manager which was doing the same thing Marc -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Do a correct format mapping of partitions
On Mon, Jun 22, 2009 at 06:31:38PM +0200, Henrik Persson E wrote: This patch reads the partition type and sets the correct target format of the storage volume when based on physical disk. I think the general idea you're trying to implement looks reasonable, but this patch you posted has been white-space damaged by your email client. Can you re-post it. Also, its useful when generating diff's to use the '-p' flag so that the patch includs the function name, eg diff -rupN libvirt-0.6.4.orig libvirt-0.6.4.new Regards, Daniel --- libvirt-0.6.4.org/src/parthelper.c2008-09-02 11:24:21.0 +0200 +++ libvirt-0.6.4/src/parthelper.c2009-06-22 16:29:49.108681000 +0200 @@ -67,6 +67,7 @@ while (part) { const char *type; const char *content; +int partType = 0; if (part-type PED_PARTITION_LOGICAL) { type = logical; if (part-type PED_PARTITION_FREESPACE) @@ -92,26 +93,35 @@ content = data; } +/* Get partition type */ +if(ped_partition_is_active(part)) { +if(ped_partition_is_flag_available(part, PED_PARTITION_TYPE)) { +partType = ped_partition_get_flag(part,PED_PARTITION_TYPE); +} +} + /* We do +1 on geom.end, because we want end of the last sector * in bytes, not the last sector number */ if (part-num != -1) { -printf(%s%d%c%s%c%s%c%llu%c%llu%c%llu%c, +printf(%s%d%c%s%c%s%c%llu%c%llu%c%llu%c%d%c, part-geom.dev-path, part-num, '\0', type, '\0', content, '\0', part-geom.start * 512llu, '\0', (part-geom.end + 1 ) * 512llu, '\0', - part-geom.length * 512llu, '\0'); + part-geom.length * 512llu, '\0', + partType, '\0'); } else { -printf(%s%c%s%c%s%c%llu%c%llu%c%llu%c, +printf(%s%c%s%c%s%c%llu%c%llu%c%llu%c%d%c, -, '\0', type, '\0', content, '\0', part-geom.start * 512llu, '\0', (part-geom.end + 1 ) * 512llu, '\0', - part-geom.length * 512llu, '\0'); + part-geom.length * 512llu, '\0', + partType, '\0'); } part = ped_disk_next_partition(disk, part); } --- libvirt-0.6.4.org/src/storage_backend_disk.c 2009-04-02 11:50:10.0 +0200 +++ libvirt-0.6.4/src/storage_backend_disk.c 2009-06-22 18:25:14.095095000 +0200 @@ -36,6 +36,35 @@ #define PARTHELPER BINDIR /libvirt_parthelper +/* Map partition types to internal enum */ +static int +virStorageBackendDiskMapPartitionType(const char* partType) +{ +switch(atoi(partType)) { + case 0x05: + case 0x0f: +return VIR_STORAGE_VOL_DISK_EXTENDED; + case 0x06: + case 0x0e: +return VIR_STORAGE_VOL_DISK_FAT16; + case 0x0b: + case 0x0c: +return VIR_STORAGE_VOL_DISK_FAT32; + case 0x82: +return VIR_STORAGE_VOL_DISK_LINUX_SWAP; + case 0x83: +return VIR_STORAGE_VOL_DISK_LINUX; + case 0x8e: +return VIR_STORAGE_VOL_DISK_LINUX_LVM; + case 0xfd: +return VIR_STORAGE_VOL_DISK_LINUX_RAID; + default: +return VIR_STORAGE_VOL_DISK_NONE; + + } +} + + static int virStorageBackendDiskMakeDataVol(virConnectPtr conn, virStoragePoolObjPtr pool, @@ -128,6 +157,9 @@ if (virStorageBackendUpdateVolInfo(conn, vol, 1) 0) return -1; +/* virStorageBackendUpdateVolInfo sets format incorrect for partitions */ +vol-target.format = virStorageBackendDiskMapPartitionType(groups[6]); + vol-type = VIR_STORAGE_VOL_BLOCK; /* The above gets allocation wrong for @@ -250,7 +282,7 @@ return virStorageBackendRunProgNul(conn, pool, prog, - 6, + 7, virStorageBackendDiskMakeVol, vol); } -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fixing issues in re-detection of transient VMs
Re-detection of transient VMs had two issues described in bugs 507304 and 507537: https://bugzilla.redhat.com/show_bug.cgi?id=507304 Summary: After a migration the domain status is saved as paused and it is not updated to running. A following libvirtd restart will detect the vm as paused (instead of running). https://bugzilla.redhat.com/show_bug.cgi?id=507537 Summary: Destroying a transient re-detected domain leaves the domain defined (instead of completely remove it). Patches in attachment (and available in the bug report). -- Federico Simoncelli. libvirt-0.6.5-save-status-on-migration.patch Description: Binary data libvirt-0.6.5-fix-destroy-after-restart.patch Description: Binary data -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/3] Control LXC capabilities
This patch updates the LXC driver to make use of libcap-ng for managing process capabilities. Previously Ryota Ozaki had provided code to remove the CAP_BOOT capabilities inside the container, preventing host reboots. In addition to that one, I believe we should be removing ability to load kernel modules, change the system clock and changing audit/MAC. So this patch also clears the following: CAP_SYS_MODULE, /* No kernel module loading */ CAP_SYS_TIME, /* No changing the clock */ CAP_AUDIT_CONTROL, /* No messing with auditing */ CAP_AUDIT_WRITE, /* No messing with auditing */ CAP_MAC_ADMIN, /* No messing with LSM */ CAP_MAC_OVERRIDE, /* No messing with LSM */ We use libcap-ng's capng_updatev/apply functions to remove these from the permitted, inheritable, effective and bounding sets. Then we use capng_lock to set NOROOT and NOROOT_LOCKED in the process securebits to prevent them ever being re-acquired. The other thing I realized is that the 'libvirt_lxc' controller process does not need to keep any capabilities at all once it has spawned the container process, since all its doing is forwarding I/O between 2 open file descripts. So I also clear all capabilities from that. We should probably make it chuid/gid to a non-root user in future too. lxc_container.c | 66 +-- lxc_controller.c | 28 +++ 2 files changed, 73 insertions(+), 21 deletions(-) Regards, Daniel diff -r 7e766489c4a2 src/lxc_container.c --- a/src/lxc_container.c Tue Jun 23 11:13:45 2009 +0100 +++ b/src/lxc_container.c Tue Jun 23 11:54:10 2009 +0100 @@ -41,8 +41,9 @@ /* For MS_MOVE */ #include linux/fs.h -#include sys/prctl.h -#include linux/capability.h +#if HAVE_CAPNG +#include cap-ng.h +#endif #include virterror_internal.h #include logging.h @@ -642,27 +643,50 @@ static int lxcContainerSetupMounts(virDo return lxcContainerSetupExtraMounts(vmDef); } -static int lxcContainerDropCapabilities(virDomainDefPtr vmDef ATTRIBUTE_UNUSED) + +/* + * This is running as the 'init' process insid the container. + * It removes some capabilities that could be dangerous to + * host system, since they are not currently containerized + */ +static int lxcContainerDropCapabilities(void) { -#ifdef PR_CAPBSET_DROP -int i; -const struct { -int id; -const char *name; -} caps[] = { -#define ID_STRING(name) name, #name -{ ID_STRING(CAP_SYS_BOOT) }, -}; +#if HAVE_CAPNG +int ret; -for (i = 0 ; i ARRAY_CARDINALITY(caps) ; i++) { -if (prctl(PR_CAPBSET_DROP, caps[i].id, 0, 0, 0)) { -lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _(failed to drop %s), caps[i].name); -return -1; -} +capng_get_caps_process(); + +if ((ret = capng_updatev(CAPNG_DROP, + CAPNG_EFFECTIVE | CAPNG_PERMITTED | + CAPNG_INHERITABLE | CAPNG_BOUNDING_SET, + CAP_SYS_BOOT, /* No use of reboot */ + CAP_SYS_MODULE, /* No kernel module loading */ + CAP_SYS_TIME, /* No changing the clock */ + CAP_AUDIT_CONTROL, /* No messing with auditing */ + CAP_AUDIT_WRITE, /* No messing with auditing */ + CAP_MAC_ADMIN, /* No messing with LSM */ + CAP_MAC_OVERRIDE, /* No messing with LSM */ + -1 /* sentinal */)) 0) { +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _(failed to remove capabilities %d), ret); +return -1; } -#else /* ! PR_CAPBSET_DROP */ -VIR_WARN0(_(failed to drop capabilities PR_CAPBSET_DROP undefined)); + +if ((ret = capng_apply(CAPNG_SELECT_BOTH)) 0) { +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _(failed to apply capabilities: %d), ret); +return -1; +} + +/* Need to prevent them regaining any caps on exec */ +if ((ret = capng_lock()) 0) { +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _(failed to lock capabilities: %d), ret); +return -1; +} + +#else +VIR_WARN0(_(libcap-ng support not compiled in, unable to clear capabilities)); #endif return 0; } @@ -735,7 +759,7 @@ static int lxcContainerChild( void *data return -1; /* drop a set of root capabilities */ -if (lxcContainerDropCapabilities(vmDef) 0) +if (lxcContainerDropCapabilities() 0) return -1; /* this function will only return if an error occured */ diff -r 7e766489c4a2 src/lxc_controller.c --- a/src/lxc_controller.c Tue Jun 23 11:13:45 2009 +0100 +++ b/src/lxc_controller.c Tue Jun 23 11:54:10 2009 +0100 @@ -35,6 +35,10 @@ #include getopt.h #include sys/mount.h +#if HAVE_CAPNG +#include cap-ng.h +#endif + #include
[libvirt] [PATCH] Do a correct format mapping of partitions 2
I make a new try from a different mail client now. /Henrik --- libvirt-0.6.4.org/src/parthelper.c 2008-09-02 11:24:21.0 +0200 +++ libvirt-0.6.4/src/parthelper.c 2009-06-22 16:29:49.108681000 +0200 @@ -67,6 +67,7 @@ int main(int argc, char **argv) while (part) { const char *type; const char *content; +int partType = 0; if (part-type PED_PARTITION_LOGICAL) { type = logical; if (part-type PED_PARTITION_FREESPACE) @@ -92,26 +93,35 @@ int main(int argc, char **argv) content = data; } +/* Get partition type */ +if(ped_partition_is_active(part)) { +if(ped_partition_is_flag_available(part, PED_PARTITION_TYPE)) { +partType = ped_partition_get_flag(part,PED_PARTITION_TYPE); +} +} + /* We do +1 on geom.end, because we want end of the last sector * in bytes, not the last sector number */ if (part-num != -1) { -printf(%s%d%c%s%c%s%c%llu%c%llu%c%llu%c, +printf(%s%d%c%s%c%s%c%llu%c%llu%c%llu%c%d%c, part-geom.dev-path, part-num, '\0', type, '\0', content, '\0', part-geom.start * 512llu, '\0', (part-geom.end + 1 ) * 512llu, '\0', - part-geom.length * 512llu, '\0'); + part-geom.length * 512llu, '\0', + partType, '\0'); } else { -printf(%s%c%s%c%s%c%llu%c%llu%c%llu%c, +printf(%s%c%s%c%s%c%llu%c%llu%c%llu%c%d%c, -, '\0', type, '\0', content, '\0', part-geom.start * 512llu, '\0', (part-geom.end + 1 ) * 512llu, '\0', - part-geom.length * 512llu, '\0'); + part-geom.length * 512llu, '\0', + partType, '\0'); } part = ped_disk_next_partition(disk, part); } --- libvirt-0.6.4.org/src/storage_backend_disk.c 2009-04-02 11:50:10.0 +0200 +++ libvirt-0.6.4/src/storage_backend_disk.c 2009-06-23 11:27:25.966487000 +0200 @@ -36,6 +36,33 @@ #define PARTHELPER BINDIR /libvirt_parthelper +/* Map partition types to internal enum */ +static int +virStorageBackendDiskMapPartitionType(const char* partType) +{ +switch(atoi(partType)) { + case 0x05: + case 0x0f: +return VIR_STORAGE_VOL_DISK_EXTENDED; + case 0x06: + case 0x0e: +return VIR_STORAGE_VOL_DISK_FAT16; + case 0x0b: + case 0x0c: +return VIR_STORAGE_VOL_DISK_FAT32; + case 0x82: +return VIR_STORAGE_VOL_DISK_LINUX_SWAP; + case 0x83: +return VIR_STORAGE_VOL_DISK_LINUX; + case 0x8e: +return VIR_STORAGE_VOL_DISK_LINUX_LVM; + case 0xfd: +return VIR_STORAGE_VOL_DISK_LINUX_RAID; + default: +return VIR_STORAGE_VOL_DISK_NONE; + } +} + static int virStorageBackendDiskMakeDataVol(virConnectPtr conn, virStoragePoolObjPtr pool, @@ -128,6 +155,9 @@ virStorageBackendDiskMakeDataVol(virConn if (virStorageBackendUpdateVolInfo(conn, vol, 1) 0) return -1; +/* virStorageBackendUpdateVolInfo sets format incorrect for partitions */ +vol-target.format = virStorageBackendDiskMapPartitionType(groups[6]); + vol-type = VIR_STORAGE_VOL_BLOCK; /* The above gets allocation wrong for @@ -250,7 +280,7 @@ virStorageBackendDiskReadPartitions(virC return virStorageBackendRunProgNul(conn, pool, prog, - 6, + 7, virStorageBackendDiskMakeVol, vol); } -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Mon, 2009-06-22 at 10:50 +0100, Daniel P. Berrange wrote: libvirt does not require that all functionality is present on all platforms. So as long as an error is raised if the user requests an unsupported configuration, we're fine. As for the XML question, libvirt requires 100% backwards compatability so its XML format is essentially append only, existing features cannot be dropped/changed. This is also the intent for netcf's XML (warning: neither the XML format nor the API can be considered stable yet, but I hope that we get to that point very soon) As for backend differences, we definitely need to address them on a case-by-case basis, weighing the headache of dealing with different backends with different feature sets against the importance of that feature. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Avoid unecessary SELinux setfilecon
As pointed by Tim Waugh in https://bugzilla.redhat.com/show_bug.cgi?id=507555 there are times where setting an SELinux file context is not possible, so if the context is already set appropriately the operation should be skipped Patch from Tim looks fine by me though I'm not versed in SELinux Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ diff -up libvirt-0.6.2/src/security_selinux.c.unnecessary-setfilecon libvirt-0.6.2/src/security_selinux.c --- libvirt-0.6.2/src/security_selinux.c.unnecessary-setfilecon 2009-06-23 10:23:59.969448493 +0100 +++ libvirt-0.6.2/src/security_selinux.c2009-06-23 10:59:27.895447757 +0100 @@ -280,10 +280,19 @@ static int SELinuxSetFilecon(virConnectPtr conn, const char *path, char *tcon) { char ebuf[1024]; +security_context_t econ; VIR_INFO(Setting SELinux context on '%s' to '%s', path, tcon); if(setfilecon(path, tcon) 0) { + if (getfilecon(path, econ) = 0) { + if (!strcmp(tcon, econ)) { + freecon(econ); + /* It's alright, there's nothing to change anyway. */ + return 0; + } + freecon(econ); + } virSecurityReportError(conn, VIR_ERR_ERROR, _(%s: unable to set security context '\%s\' on %s: %s.), __func__, -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Avoid unecessary SELinux setfilecon
On Tue, Jun 23, 2009 at 03:02:52PM +0200, Daniel Veillard wrote: As pointed by Tim Waugh in https://bugzilla.redhat.com/show_bug.cgi?id=507555 there are times where setting an SELinux file context is not possible, so if the context is already set appropriately the operation should be skipped Patch from Tim looks fine by me though I'm not versed in SELinux Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ diff -up libvirt-0.6.2/src/security_selinux.c.unnecessary-setfilecon libvirt-0.6.2/src/security_selinux.c --- libvirt-0.6.2/src/security_selinux.c.unnecessary-setfilecon 2009-06-23 10:23:59.969448493 +0100 +++ libvirt-0.6.2/src/security_selinux.c 2009-06-23 10:59:27.895447757 +0100 @@ -280,10 +280,19 @@ static int SELinuxSetFilecon(virConnectPtr conn, const char *path, char *tcon) { char ebuf[1024]; +security_context_t econ; VIR_INFO(Setting SELinux context on '%s' to '%s', path, tcon); if(setfilecon(path, tcon) 0) { + if (getfilecon(path, econ) = 0) { + if (!strcmp(tcon, econ)) { + freecon(econ); + /* It's alright, there's nothing to change anyway. */ + return 0; + } + freecon(econ); + } virSecurityReportError(conn, VIR_ERR_ERROR, _(%s: unable to set security context '\%s\' on %s: %s.), __func__, The patch has a bit of whitespace damage, and should use STREQ, but functionally it looks correct. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC][PATCH] lxc: drop CAP_SYS_BOOT capability to preventrebooting from inside containers
On Fri, May 08, 2009 at 12:43:19PM +0900, Ryota Ozaki wrote: Hi Serge, On Fri, May 8, 2009 at 11:04 AM, Serge E. Hallyn se...@us.ibm.com wrote: Quoting Ryota Ozaki (ozaki.ry...@gmail.com): Hi Serge, On Fri, May 8, 2009 at 9:12 AM, Serge E. Hallyn se...@us.ibm.com wrote: Quoting Ryota Ozaki (ozaki.ry...@gmail.com): Hi, ... + for (i = 0 ; i ARRAY_CARDINALITY(caps) ; i++) { + if (prctl(PR_CAPBSET_DROP, caps[i].id, 0, 0, 0)) { + lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, + %s, _(failed to drop %s), caps[i].name); + return -1; Ideally you should also drop it from pI. If not drop it, a user in a container could set CAP_SYS_BOOT fI bit of /bin/reboot on and then the user could gain CAP_SYS_BOOT back through the fI. Is this understanding right? Yup. Of course most tasks run with pI empty, so it seems unlikely that it would be a problem, but unless the libcap dependecy becomes a problem, it seems worth making sure that doesn't happen. Oh, I slightly misread your suggestions, sorry. You are suggesting making sure requires dropping a capability in both bounding set AND pI of a process and to do so we need an additional package (libcap2 or somewhat) because prctl(2) doesn't have the function to drop pI, aren't you? um, I hope my patch is sufficient as a first step, but ok, I'll try to implement the function to drop pI as well and confirm whether it is feasible for libvirt. The patch I have just posted should take care of this issue with pI http://www.redhat.com/archives/libvir-list/2009-June/msg00413.html Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virsh hangs
My system: Ubuntu Jaunty 9.04 libvirt 0.6.4 kvm 0.8.4 qemu 0.10.0 I'm not sure what triggered this, I was working with several VMs, and then found that virsh decided to hang: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system hang I have to ^C out of it. If I 'force-stop' and then 'start' libvirt-bin: ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin force-stop * Forcefully stopping libvirt management daemon libvirtd ...done. ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin start * Starting libvirt management daemon libvirtd ...done. I can then get something: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system Id Name State -- 1 vm1 running 4 s3-lax running 14 freebsd-test running 19 freebsd-2running hang But it hangs after that 4th one. I must ^C it again. If I do 'virsh list' again, it'll then show nothing (hangs like it does above). Any suggestions? Thanks -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] Probe for libcap-ng
On Tue, Jun 23, 2009 at 03:35:07PM +0200, Daniel Veillard wrote: On Mon, Jun 22, 2009 at 08:51:37PM +0100, Daniel P. Berrange wrote: Probe for capng in configure, and set some RPM spec rules. Trivial boring stuff. As long as the requirement is not mandatory I'm just a bit surprized that libcap-ng is not listed as a dependency just a build one on the spec file. Any library linked to is automatically added as a dependancy by RPM Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] Set basic capabilities needed for libvirtd
On Mon, Jun 22, 2009 at 08:58:27PM +0100, Daniel P. Berrange wrote: This sets up some basic support in libvirtd for dropping privileges by removing capabilities, or changing uid/gid of the process. It needed a little movement of existing code to allow us to drop privileges in between initializing the daemon and initializing the drivers. As I mentioned in the first mail, this patch doesn't really improve security of the daemon, since we keep CAP_DAC_OVERRIDE, CAP_SYS_ADMIN and CAP_NET_ADMIN. I've put comments inline showing why I chose to keep/exclude each capability. the problem is that the amound of capability we can drop is dependant on the actual set of drivers installed. I have the feeling that each driver should have a method exporting the capabilities it needs and once we have initialized the set of drivers then we should drop to the logical OR'ing of them. I think trying to maintain a global knowledge of all drivers requirement in a central place won't scale well and that's better left to the drivers maintainers. I also added a helper to util.c for resolving a name to a gid/uid. Ignore all the printfs() in the code, those will be removed later before I submit this again... That said as a first approach that looks fine to me. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] Probe for libcap-ng
On Mon, Jun 22, 2009 at 08:51:37PM +0100, Daniel P. Berrange wrote: Probe for capng in configure, and set some RPM spec rules. Trivial boring stuff. As long as the requirement is not mandatory I'm just a bit surprized that libcap-ng is not listed as a dependency just a build one on the spec file. ACK Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] Run all VMs without capabilities
On Mon, Jun 22, 2009 at 09:05:24PM +0100, Daniel P. Berrange wrote: This patch adds a new flag to virExec() called VIR_EXEC_CLEAR_CAPS. If you set this flag than all capabilities are removed inbetween the fork() and exec() pair. It also updates QEMU and UML driver to run their VMs without any privileges. A mild security benefit for most distros today, but if distros start to lock down what the unprivileged root user can do, this benefit increases. It also removes all capabilities from the 'ssh' client spawned by the remote client, since that shouldn't need any real privileges to open a tunnel. IMHO that and the first patch could be applied as is, even if the other patches a a bit more subtle, that is simple direct and clear we don't need to wait for this. +#else +static int virClearCapabilities(void) +{ +//VIR_WARN0(libcap-ng support not compiled in, unable to clear capabilities); Hum, to be cleaned up one way or another :-) ACK Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fixing issues in re-detection of transient VMs
On Tue, Jun 23, 2009 at 11:30:10AM +0200, Federico Simoncelli wrote: Re-detection of transient VMs had two issues described in bugs 507304 and 507537: https://bugzilla.redhat.com/show_bug.cgi?id=507304 Summary: After a migration the domain status is saved as paused and it is not updated to running. A following libvirtd restart will detect the vm as paused (instead of running). https://bugzilla.redhat.com/show_bug.cgi?id=507537 Summary: Destroying a transient re-detected domain leaves the domain defined (instead of completely remove it). Patches in attachment (and available in the bug report). The two patches (as seen on the bugzilla) look fine to me, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/3] Control LXC capabilities
Quoting Daniel P. Berrange (berra...@redhat.com): This patch updates the LXC driver to make use of libcap-ng for managing process capabilities. Previously Ryota Ozaki had provided code to remove the CAP_BOOT capabilities inside the container, preventing host reboots. In addition to that one, I believe we should be removing ability to load kernel modules, change the system clock and changing audit/MAC. So this patch also clears the following: CAP_SYS_MODULE, /* No kernel module loading */ CAP_SYS_TIME, /* No changing the clock */ CAP_AUDIT_CONTROL, /* No messing with auditing */ CAP_AUDIT_WRITE, /* No messing with auditing */ CAP_MAC_ADMIN, /* No messing with LSM */ CAP_MAC_OVERRIDE, /* No messing with LSM */ Thanks, Daniel, this does look good. I wonder whether there is a more appropriate list to email caps-related patches (including libcap-ng itself) to. Not only does the code itself warrant discussion (for instance, should capng_lock() also set CAP_NOSUID_FIXUP?), but such discussions, in one place, about converting several programs to dropping capabilities would help others to do the same with this code. I can't think of anything other than the LSM list, so I'm cc:ing it here. We use libcap-ng's capng_updatev/apply functions to remove these from the permitted, inheritable, effective and bounding sets. Then we use capng_lock to set NOROOT and NOROOT_LOCKED in the process securebits to prevent them ever being re-acquired. The other thing I realized is that the 'libvirt_lxc' controller process does not need to keep any capabilities at all once it has spawned the container process, since all its doing is forwarding I/O between 2 open file descripts. So I also clear all capabilities from that. We should probably make it chuid/gid to a non-root user in future too. lxc_container.c | 66 +-- lxc_controller.c | 28 +++ 2 files changed, 73 insertions(+), 21 deletions(-) Regards, Daniel diff -r 7e766489c4a2 src/lxc_container.c --- a/src/lxc_container.c Tue Jun 23 11:13:45 2009 +0100 +++ b/src/lxc_container.c Tue Jun 23 11:54:10 2009 +0100 @@ -41,8 +41,9 @@ /* For MS_MOVE */ #include linux/fs.h -#include sys/prctl.h -#include linux/capability.h +#if HAVE_CAPNG +#include cap-ng.h +#endif #include virterror_internal.h #include logging.h @@ -642,27 +643,50 @@ static int lxcContainerSetupMounts(virDo return lxcContainerSetupExtraMounts(vmDef); } -static int lxcContainerDropCapabilities(virDomainDefPtr vmDef ATTRIBUTE_UNUSED) + +/* + * This is running as the 'init' process insid the container. + * It removes some capabilities that could be dangerous to + * host system, since they are not currently containerized + */ +static int lxcContainerDropCapabilities(void) { -#ifdef PR_CAPBSET_DROP -int i; -const struct { -int id; -const char *name; -} caps[] = { -#define ID_STRING(name) name, #name -{ ID_STRING(CAP_SYS_BOOT) }, -}; +#if HAVE_CAPNG +int ret; -for (i = 0 ; i ARRAY_CARDINALITY(caps) ; i++) { -if (prctl(PR_CAPBSET_DROP, caps[i].id, 0, 0, 0)) { -lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _(failed to drop %s), caps[i].name); -return -1; -} +capng_get_caps_process(); + +if ((ret = capng_updatev(CAPNG_DROP, + CAPNG_EFFECTIVE | CAPNG_PERMITTED | + CAPNG_INHERITABLE | CAPNG_BOUNDING_SET, + CAP_SYS_BOOT, /* No use of reboot */ + CAP_SYS_MODULE, /* No kernel module loading */ + CAP_SYS_TIME, /* No changing the clock */ + CAP_AUDIT_CONTROL, /* No messing with auditing */ + CAP_AUDIT_WRITE, /* No messing with auditing */ + CAP_MAC_ADMIN, /* No messing with LSM */ + CAP_MAC_OVERRIDE, /* No messing with LSM */ + -1 /* sentinal */)) 0) { +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _(failed to remove capabilities %d), ret); +return -1; } -#else /* ! PR_CAPBSET_DROP */ -VIR_WARN0(_(failed to drop capabilities PR_CAPBSET_DROP undefined)); + +if ((ret = capng_apply(CAPNG_SELECT_BOTH)) 0) { +lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _(failed to apply capabilities: %d), ret); +return -1; +} The only problem offhand with this idiom is that you need CAP_SETPCAP to set securebits and drop caps from bounding set, but I think a lot of applications could stand to drop CAP_SETPCAP otherwise. So I don't know if it would help to do the capng_lock() before capng_apply(). (To be clear, not bc you need to
Re: [libvirt] [PATCH] Power Hypervisor Support for libvirt - minimum set of features
Hello again, This is the life cycle operations I've been working on these days. Fortunately this is a smaller and more punctual diff. :) Any comment is always welcome. []'s On Mon, 2009-06-22 at 18:57 -0300, Eduardo Otubo wrote: Hello all, This is the initial patch for the driver for IBM Power Hypervisors. The minimum set of features are now implemented: list, list --all and dumpxml. Here is the Changeset since last PATCH I sent: * The URI has changed to: phyp://u...@[hmc|ivm]/managed_system. If the system is a HMC+VIOS based, only an HMC authentication will be required. Commands will be sent to VIOS trough HMC command line. And if the system is an IVM based, then just provide the username and password for IVM. * Since the Power Hypervisor has no information about UUID's, I built a little database (uuid_db) to store and associate LPAR ID's with UUID randomly generated by the API. * The command dumpxml is implemented, but there are some informations missing. Fetching informations like fstab, os type, uptime, IP addr and so on, will only be available in a future versions of the HMC system. * The TODO list is now set to implement life cycle functions. Thanks in advance, []'s -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems Technology Group Mobile: +55 19 8135 0885 ot...@linux.vnet.ibm.com diff --git a/src/phyp/phyp_driver.c b/src/phyp/phyp_driver.c index b922ab8..0b28cff 100644 --- a/src/phyp/phyp_driver.c +++ b/src/phyp/phyp_driver.c @@ -585,6 +585,64 @@ phypGetBackingDevice(virConnectPtr conn, const char *managed_system, } int +phypGetLparState(virConnectPtr conn, unsigned int lpar_id) +{ +ConnectionData *connection_data = conn-networkPrivateData; +SSH_SESSION *ssh_session = connection_data-session; +char *cmd; +int exit_status = 0; +char *char_ptr = NULL; +char *managed_system = conn-uri-path; + +/* need to shift one byte in order to remove the first / of URI component */ +if (managed_system[0] == '/') +managed_system++; + +/* here we are handling only the first component of the path, + * so skipping the second: + * */ + +char_ptr = strchr(managed_system, '/'); + +if (char_ptr) +*char_ptr = '\0'; + +if (virAsprintf(cmd, +lssyscfg -r lpar -m %s -F state --filter lpar_ids=%d, +managed_system, lpar_id) 0) { +virReportOOMError(conn); +goto err; +} + +char *ret = exec(ssh_session, cmd, (int *) exit_status, conn); + +if (ret == NULL) +goto err; + +char_ptr = strchr(ret, '\n'); + +if (char_ptr) +*char_ptr = '\0'; + +if (exit_status 0 || ret == NULL) +goto err; + +VIR_FREE(cmd); +if (STREQ(ret, Running)) +return VIR_DOMAIN_RUNNING; +else if (STREQ(ret, Not Activated)) +return VIR_DOMAIN_SHUTOFF; +else if (STREQ(ret, Shutting Down)) +return VIR_DOMAIN_SHUTDOWN; +else +goto err; + + err: +VIR_FREE(cmd); +return VIR_DOMAIN_NOSTATE; +} + +int phypDiskType(virConnectPtr conn, char *backing_device) { ConnectionData *connection_data = conn-networkPrivateData; @@ -1000,6 +1058,119 @@ phypDomainDumpXML(virDomainPtr dom, int flags) return ret; } +static int +phypDomainResume(virDomainPtr dom) +{ +ConnectionData *connection_data = dom-conn-networkPrivateData; +SSH_SESSION *ssh_session = connection_data-session; +char *managed_system = dom-conn-uri-path; +int exit_status = 0; +char *char_ptr = NULL; +char *cmd; + +/* need to shift one byte in order to remove the first / of URI component */ +if (managed_system[0] == '/') +managed_system++; + +/* here we are handling only the first component of the path, + * so skipping the second: + * */ +char_ptr = strchr(managed_system, '/'); + +if (char_ptr) +*char_ptr = '\0'; + +if (virAsprintf +(cmd, + chsysstate -m %s -r lpar -o on --id %d -f %s, + managed_system, dom-id, dom-name) 0) { +virReportOOMError(dom-conn); +goto err; +} + +char *ret = exec(ssh_session, cmd, exit_status, dom-conn); + + err: +VIR_FREE(cmd); +VIR_FREE(ret); +return 0; + +} + +static int +phypDomainShutdown(virDomainPtr dom) +{ +ConnectionData *connection_data = dom-conn-networkPrivateData; +SSH_SESSION *ssh_session = connection_data-session; +char *managed_system = dom-conn-uri-path; +int exit_status = 0; +char *char_ptr = NULL; +char *cmd; + +/* need to shift one byte in order to remove the first / of URI component */ +if (managed_system[0] == '/') +managed_system++; + +/* here we are handling only the first component of the path, + * so skipping the second: + * */ +char_ptr = strchr(managed_system,
[libvirt] [PATCH] For comment/critique only - netcf backend for virInterface*.
This is the backend for the interface driver (virInterface*()) that uses netcf. There are a few issues with it: 1) It doesn't yet implement the backend for virConnectListDefinedInterfaces() and virConnectNumOfDefinedInterfaces() (although it does use my patched netcf API to list only active interfaces for virConnectListInterfaces()). (That patch isn't committed to netcf yet, btw; it's functional, but a bit rough and hackish) 2) interfaceLookupByMACString() still uses the old arg convention for ncf_lookup_by_mac_string(), which returned a single interface. That function has been changed to potentially return multiple interfaces. To fully support that, we would need to change the libvirt API. What should we do here? 3) The XML in interfaceDefineXML() isn't validated, although the spot to do it is clearly marked. 4) There's no comment in the place where we could, in the future, transform the XML returned to interfaceGetXMLDesc() by netcf. Currently the two use the same RNG. Since it would be a null transform, and that will only change under our control, that isn't an *immediate* problem, but shouldn't be forgotten. Parts that I'm unsure of: 1) changes to the Makefile, particularly surrounding DRIVER_MODULES. 2) Is it registered in the proper places? 3) Could it (should it?) be added to other hypervisor drivers? (Currently I only put it in qemud.c) --- qemud/Makefile.am |4 + qemud/qemud.c |6 + src/Makefile.am| 16 ++- src/interface_driver.c | 381 src/interface_driver.h | 34 + 5 files changed, 440 insertions(+), 1 deletions(-) create mode 100644 src/interface_driver.c create mode 100644 src/interface_driver.h diff --git a/qemud/Makefile.am b/qemud/Makefile.am index 403846a..9f982ba 100644 --- a/qemud/Makefile.am +++ b/qemud/Makefile.am @@ -134,6 +134,10 @@ if WITH_NETWORK libvirtd_LDADD += ../src/libvirt_driver_network.la endif +if WITH_NETCF +libvirtd_LDADD += ../src/libvirt_driver_interface.la +endif + if WITH_NODE_DEVICES libvirtd_LDADD += ../src/libvirt_driver_nodedev.la endif diff --git a/qemud/qemud.c b/qemud/qemud.c index b5e3665..9326ce9 100644 --- a/qemud/qemud.c +++ b/qemud/qemud.c @@ -81,6 +81,9 @@ #ifdef WITH_NETWORK #include network_driver.h #endif +#ifdef WITH_NETCF +#include interface_driver.h +#endif #ifdef WITH_STORAGE_DIR #include storage_driver.h #endif @@ -822,6 +825,9 @@ static struct qemud_server *qemudInitialize(int sigread) { #ifdef WITH_NETWORK networkRegister(); #endif +#ifdef WITH_NETCF +interfaceRegister(); +#endif #ifdef WITH_STORAGE_DIR storageRegister(); #endif diff --git a/src/Makefile.am b/src/Makefile.am index f65e7ad..f5bf1b8 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -154,6 +154,9 @@ ONE_DRIVER_SOURCES = \ NETWORK_DRIVER_SOURCES = \ network_driver.h network_driver.c +INTERFACE_DRIVER_SOURCES = \ + interface_driver.h interface_driver.c + # Storage backend specific impls STORAGE_DRIVER_SOURCES = \ storage_driver.h storage_driver.c \ @@ -381,8 +384,18 @@ libvirt_driver_network_la_SOURCES = $(NETWORK_DRIVER_SOURCES) endif if WITH_NETCF -libvirt_driver_interface_la_CFLAGS = $(NETCF_CFLAGS) libvirt_driver_interface_la_LDFLAGS = $(NETCF_LIBS) +libvirt_driver_interface_la_CFLAGS = $(NETCF_CFLAGS) +if WITH_DRIVER_MODULES +mod_LTLIBRARIES += libvirt_driver_interface.la +else +noinst_LTLIBRARIES += libvirt_driver_interface.la +libvirt_la_LIBADD += libvirt_driver_interface.la +endif +if WITH_DRIVER_MODULES +libvirt_driver_interface_la_LDFLAGS += -module -avoid-version +endif +libvirt_driver_interface_la_SOURCES = $(INTERFACE_DRIVER_SOURCES) endif # Needed to keep automake quiet about conditionals @@ -467,6 +480,7 @@ EXTRA_DIST += \ $(OPENVZ_DRIVER_SOURCES)\ $(VBOX_DRIVER_SOURCES) \ $(NETWORK_DRIVER_SOURCES) \ + $(INTERFACE_DRIVER_SOURCES) \ $(STORAGE_DRIVER_SOURCES) \ $(STORAGE_DRIVER_FS_SOURCES)\ $(STORAGE_DRIVER_LVM_SOURCES) \ diff --git a/src/interface_driver.c b/src/interface_driver.c new file mode 100644 index 000..b6cf510 --- /dev/null +++ b/src/interface_driver.c @@ -0,0 +1,381 @@ +/* + * interface_driver.c: backend driver methods to handle physical + * interface configuration using the netcf library. + * + * Copyright (C) 2006-2009 Red Hat, Inc. + * Copyright (C) 2006 Daniel P. Berrange + * + * This library is free
Re: [libvirt] virsh hangs
On Tue, Jun 23, 2009 at 06:22:34AM -0700, Garry Dolley wrote: My system: Ubuntu Jaunty 9.04 libvirt 0.6.4 kvm 0.8.4 qemu 0.10.0 I'm not sure what triggered this, I was working with several VMs, and then found that virsh decided to hang: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system hang I have to ^C out of it. If I 'force-stop' and then 'start' libvirt-bin: ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin force-stop * Forcefully stopping libvirt management daemon libvirtd ...done. ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin start * Starting libvirt management daemon libvirtd ...done. I can then get something: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system Id Name State -- 1 vm1 running 4 s3-lax running 14 freebsd-test running 19 freebsd-2running hang But it hangs after that 4th one. I must ^C it again. If I do 'virsh list' again, it'll then show nothing (hangs like it does above). Any suggestions? From playing with this, I'm led to believe libvirt remembers some VM that I may have killed manually w/ 'kill'. Where does libvirt store what VMs it knows about across restarts? I think I may need to manually poke around there and take out the bad VM... -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh hangs
On Tue, Jun 23, 2009 at 04:08:25PM -0300, Itamar Reis Peixoto wrote: why you don't try Fedora 11 it's have newer versions of libvirt and KVM and if you have problem's you can report a bug or talk with developers using IRC Why don't I use Fedora? Let's not go there... ;) -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Memory leak in node_device_conf.c
I found what I assume is a memory leak in the node device code while working on a separate problem; patch attached. Dave diff --git a/src/node_device_conf.c b/src/node_device_conf.c index 1fbf9dc..56a9bb5 100644 --- a/src/node_device_conf.c +++ b/src/node_device_conf.c @@ -1203,6 +1203,8 @@ void virNodeDevCapsDefFree(virNodeDevCapsDefPtr caps) VIR_FREE(data-net.address); break; case VIR_NODE_DEV_CAP_SCSI_HOST: +VIR_FREE(data-scsi_host.wwnn); +VIR_FREE(data-scsi_host.wwpn); break; case VIR_NODE_DEV_CAP_SCSI: VIR_FREE(data-scsi.type); -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh hangs
On Tue, Jun 23, 2009 at 06:22:34AM -0700, Garry Dolley wrote: My system: Ubuntu Jaunty 9.04 libvirt 0.6.4 kvm 0.8.4 qemu 0.10.0 I'm not sure what triggered this, I was working with several VMs, and then found that virsh decided to hang: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system hang I have to ^C out of it. If I 'force-stop' and then 'start' libvirt-bin: ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin force-stop * Forcefully stopping libvirt management daemon libvirtd ...done. ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin start * Starting libvirt management daemon libvirtd ...done. I can then get something: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system Id Name State -- 1 vm1 running 4 s3-lax running 14 freebsd-test running 19 freebsd-2running hang But it hangs after that 4th one. I must ^C it again. If I do 'virsh list' again, it'll then show nothing (hangs like it does above). Any suggestions? Install the -debug packages for libvirt, and get a trace of all its threads under GDB, eg (gdb) thread apply all backtrace Also, capture traces of the client server, by setting LIBVIRT_DEBUG=1 before running each. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh hangs
On Tue, Jun 23, 2009 at 12:05:35PM -0700, Garry Dolley wrote: On Tue, Jun 23, 2009 at 06:22:34AM -0700, Garry Dolley wrote: My system: Ubuntu Jaunty 9.04 libvirt 0.6.4 kvm 0.8.4 qemu 0.10.0 I'm not sure what triggered this, I was working with several VMs, and then found that virsh decided to hang: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system hang I have to ^C out of it. If I 'force-stop' and then 'start' libvirt-bin: ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin force-stop * Forcefully stopping libvirt management daemon libvirtd ...done. ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin start * Starting libvirt management daemon libvirtd ...done. I can then get something: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system Id Name State -- 1 vm1 running 4 s3-lax running 14 freebsd-test running 19 freebsd-2running hang But it hangs after that 4th one. I must ^C it again. If I do 'virsh list' again, it'll then show nothing (hangs like it does above). Any suggestions? From playing with this, I'm led to believe libvirt remembers some VM that I may have killed manually w/ 'kill'. Where does libvirt store what VMs it knows about across restarts? I think I may need to manually poke around there and take out the bad VM... crobinso in #virt (irc.oftc.net) helped me solve this. The info about running VMs is kept across restarts in: /var/run/libvirt/qemu There was a VM that went crazy, it totally hung, and I guess something about it didn't sit well with virsh. When I 'kill -9' this VM (yes, 'kill' by itself didn't even work), then virsh didn't hang anymore. Problem solved. (thankfully, the hanging VM was a throw-away one, so kill -9 was OK in this case) -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh hangs
On Tue, Jun 23, 2009 at 09:39:25PM +0100, Daniel P. Berrange wrote: On Tue, Jun 23, 2009 at 06:22:34AM -0700, Garry Dolley wrote: My system: Ubuntu Jaunty 9.04 libvirt 0.6.4 kvm 0.8.4 qemu 0.10.0 I'm not sure what triggered this, I was working with several VMs, and then found that virsh decided to hang: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system hang I have to ^C out of it. If I 'force-stop' and then 'start' libvirt-bin: ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin force-stop * Forcefully stopping libvirt management daemon libvirtd ...done. ga...@kvr02:~$ sudo /etc/init.d/libvirt-bin start * Starting libvirt management daemon libvirtd ...done. I can then get something: ga...@kvr02:~$ virsh list Connecting to uri: qemu:///system Id Name State -- 1 vm1 running 4 s3-lax running 14 freebsd-test running 19 freebsd-2running hang But it hangs after that 4th one. I must ^C it again. If I do 'virsh list' again, it'll then show nothing (hangs like it does above). Any suggestions? Install the -debug packages for libvirt, and get a trace of all its threads under GDB, eg (gdb) thread apply all backtrace Also, capture traces of the client server, by setting LIBVIRT_DEBUG=1 before running each. I solved the problem, but thanks for this info. I'll use it next time. How do I attach gdb to a running process? (I'm a gdb noob) -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list