Re: [libvirt] virsh -no-kvm problem on debian install

2009-06-23 Thread ChaosMedia WebDev



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

2009-06-23 Thread Daniel P. Berrange
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

2009-06-23 Thread Federico Simoncelli
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

2009-06-23 Thread Daniel P. Berrange
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

2009-06-23 Thread Henrik Persson

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

2009-06-23 Thread David Lutterkort
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

2009-06-23 Thread Daniel Veillard
  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

2009-06-23 Thread Daniel P. Berrange
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

2009-06-23 Thread Daniel P. Berrange
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

2009-06-23 Thread Garry Dolley
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

2009-06-23 Thread Daniel P. Berrange
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

2009-06-23 Thread Daniel Veillard
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

2009-06-23 Thread Daniel Veillard
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

2009-06-23 Thread Daniel Veillard
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

2009-06-23 Thread Daniel Veillard
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

2009-06-23 Thread Serge E. Hallyn
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

2009-06-23 Thread Eduardo Otubo
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*.

2009-06-23 Thread Laine Stump
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

2009-06-23 Thread Garry Dolley
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

2009-06-23 Thread Garry Dolley
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

2009-06-23 Thread Dave Allan
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

2009-06-23 Thread Daniel P. Berrange
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

2009-06-23 Thread Garry Dolley
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

2009-06-23 Thread Garry Dolley
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