Re: [libvirt] PATCH: Generic internal API for domain XML parser/formatter
Daniel P. Berrange wrote: In the graphics element for VNC we have a 'port' attribute. For a running VM this contains the actual port number. For an inactive VM it contains the pre-allocated fixed port number, or -1 to indicate that a automatically allocated port should be used. There is an obvious flaw here - if the VM is running it is impossible to tell if its port was fixed or automatically allocated. Oh, there are some other places where something simliar happens. For example the network interface target device name, which also can be either auto-allocated or hardcoded. IMHO it is a fundamental design flaw that dumpxml gives different results depending on whenever the domain is running or not. Hard to fix by now though :-( If you change the domain config using dumpxml/edit/define while the domain is running you change the current auto-assigned values into hardcoded config items as (unwanted) side effect. You can easily end up with two domains being configured with tap device vnet0 and/or vnc port 5900 without noticing. And then you wounder why trying to start both domains at the same time doesn't fly ... So I introduce an extra attributeautoport='no|yes' to provide this data. For compatability we still use port='-1' when the VM is not running Yep, that should band-aid at least the vnc port case. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Generic internal API for domain XML parser/formatter
On Wed, Jun 25, 2008 at 10:05:30AM +0200, Gerd Hoffmann wrote: Daniel P. Berrange wrote: In the graphics element for VNC we have a 'port' attribute. For a running VM this contains the actual port number. For an inactive VM it contains the pre-allocated fixed port number, or -1 to indicate that a automatically allocated port should be used. There is an obvious flaw here - if the VM is running it is impossible to tell if its port was fixed or automatically allocated. Oh, there are some other places where something simliar happens. For example the network interface target device name, which also can be either auto-allocated or hardcoded. We deal with that slightly differently - if we see a target interface passed in called 'vnet' or 'vifX.Y' then we ignore it treat it as a autogenerated interface. IMHO it is a fundamental design flaw that dumpxml gives different results depending on whenever the domain is running or not. Hard to fix by now though :-( Actually there is another way to access the info - pass the flag VIR_DOMAIN_XML_INACTIVE to the DumpXML method to explicitly request the inactive XML. If you change the domain config using dumpxml/edit/define while the domain is running you change the current auto-assigned values into hardcoded config items as (unwanted) side effect. You can easily end up with two domains being configured with tap device vnet0 and/or vnc port 5900 without noticing. And then you wounder why trying to start both domains at the same time doesn't fly ... With this patch we now correctly handle the the VNC and vnetXX case. I also fixed the PV text console PTY issue too when we added the full serial/parallel port support. I'm not aware of any other problems like this besides these. 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
Re: [libvirt] [PATCH] Eliminate noise from python type wrappers
On Wed, Jun 25, 2008 at 09:10:29AM +0900, Atsushi SAKAI wrote: Hi, Just a simple question. Why you do not turn off the DEBUG flag for libvirt build? We actually build with DEBUG enabled by default now because we've found it incredibly useful when debugging customer problems to be able to ask them to just set LIBVIRT_DEBUG=1 and get debugging data. 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] Eliminate noise from python type wrappers
On Tue, Jun 24, 2008 at 03:57:21PM -0700, Ryan Scott wrote: Hi, We recently had a virt-install build failure when someone tried building on a system with debug libvirt packages installed. It was caused by extra noise from commands that load libvirt. For example: $ python ./setup.py --version libvirt_virConnectPtrWrap: node = 8938fb8 0.300.3 I've seen (internal) complaints about this, and I think the irritation from the noise outweighs the usefulness of these statements, so they should be removed. ACK, gets my vote. We really don't need this debug info from the data type convertors. All the public APIs already print out their args when LIBVIRT_DEBUG=1 is set. 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: Generic internal API for domain XML parser/formatter
Daniel P. Berrange wrote: IMHO it is a fundamental design flaw that dumpxml gives different results depending on whenever the domain is running or not. Hard to fix by now though :-( Actually there is another way to access the info - pass the flag VIR_DOMAIN_XML_INACTIVE to the DumpXML method to explicitly request the inactive XML. Oh, good. Has virsh a switch for that? cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Generic internal API for domain XML parser/formatter
On Wed, Jun 25, 2008 at 11:58:10AM +0200, Gerd Hoffmann wrote: Daniel P. Berrange wrote: IMHO it is a fundamental design flaw that dumpxml gives different results depending on whenever the domain is running or not. Hard to fix by now though :-( Actually there is another way to access the info - pass the flag VIR_DOMAIN_XML_INACTIVE to the DumpXML method to explicitly request the inactive XML. Oh, good. Has virsh a switch for that? Not yet - it also doesn't actually work fully with current libvirt - this is something I'm fixed with the re-factoring of the XML parsing patches so that all drivers honour this flag fully. 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] Release of libvirt-0.4.4
A new release to fix the few bugs which made 0.4.3 really unsuitable for oVirt available as usual at ftp://libvirt.org/libvirt/ * Bug fixes: - QEmu network serialization (Kaitlin Rupert) - internal memory allocation fixes (Chris Lalancette Jim Meyering) - virsh large file config problem (Jim Meyering) - xen list APIs when max is zero - string escape problems in the xm driver * Improvements: - add autogen to tarballs - improve iSCSI support (Chris Lalancette) - localization updates * Cleanups: - const-ness fixed (Daniel P. Berrange) - string helpers for enumeations (Daniel P. Berrange) thanks for the bug reports and patches ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Eliminate noise from python type wrappers
On Tue, Jun 24, 2008 at 03:57:21PM -0700, Ryan Scott wrote: Hi, We recently had a virt-install build failure when someone tried building on a system with debug libvirt packages installed. It was caused by extra noise from commands that load libvirt. For example: $ python ./setup.py --version libvirt_virConnectPtrWrap: node = 8938fb8 0.300.3 I've seen (internal) complaints about this, and I think the irritation from the noise outweighs the usefulness of these statements, so they should be removed. It's a remain from the past (actually from libxml2 code) where DEBUG was used in a far more specific fashion and really doesn't bring any useful information now. so yes this makes sense, applied and commited to CVS, thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
Dan Smith wrote: Allow check for containers support to be done without CLONE_NEWNET, and then determine support on the fly by checking for iproute2 support and a successful clone(CLONE_NEWNET). This lets us set a flag for later, as well as not completely disable LXC support on a system without NETNS support. The CLONE_NEWNET will fail if the network namespace is not compiled in. I understand this check but it looks like a little random. You are not 100% sure this clone has failed because the network namespace is not supported. That can be another subsystem or namespace which has failed during the initialization of the namespaces. Why don't you simply check the presence of the 'netns' process ? Concerning iproute2, I think this is the work of the installer to check the dependencies, eg. the libvirt rpm depends on iproute2-x.y.z version rpm. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
DL The CLONE_NEWNET will fail if the network namespace is not DL compiled in. I understand this check but it looks like a little DL random. You are not 100% sure this clone has failed because the DL network namespace is not supported. That can be another subsystem DL or namespace which has failed during the initialization of the DL namespaces. The check is performed twice, once with the basic set of flags and again with CLONE_NEWNET. If the first check fails, we assume no LXC support (as we did before). If the second fails, we assume LXC but no NETNS. Is there something else I'm missing here? DL Why don't you simply check the presence of the 'netns' process ? That seems like a valid way as well, although we already do our feature checks by testing the clone. Also, by doing it this way, we have a better confirmation that an actual clone(CLONE_NEWNET) will work, IMHO. DL Concerning iproute2, I think this is the work of the installer to DL check the dependencies, eg. the libvirt rpm depends on DL iproute2-x.y.z version rpm. Agreed, and I'm sure it will. Note DV's second comment here: https://www.redhat.com/archives/libvir-list/2008-June/msg00232.html Thanks! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpbFnsnVjeVY.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] quiet make syntax-check
[Here's a tiny patch, mainly to test our just-patched mailman.
Note the patch below, included verbatim from git format-patch output. ]
From c7ac46c5ea71bb17164b4f94bd83106b8001944d Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Tue, 13 May 2008 11:20:07 +0200
Subject: [PATCH] quiet make syntax-check
* Makefile.maint (strftime-check): Add @ prefix.
(po-check): Likewise.
---
Makefile.maint |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.maint b/Makefile.maint
index a593ae2..dff75fe 100644
--- a/Makefile.maint
+++ b/Makefile.maint
@@ -420,7 +420,7 @@ patch-check:
# which date accepts but GNU strftime does not.
extract_char = sed 's/^[^%][^%]*%\(.\).*/\1/'
strftime-check:
- if test -f $(srcdir)/src/date.c; then \
+ @if test -f $(srcdir)/src/date.c; then \
grep '^ %. ' $(srcdir)/src/date.c | sort\
| $(extract_char) [EMAIL PROTECTED];
\
{ echo N; \
@@ -467,7 +467,7 @@ m4-check:
# Verify that all source files using _() are listed in po/POTFILES.in.
# FIXME: don't hard-code file names below; use a more general mechanism.
po-check:
- if test -f po/POTFILES.in; then \
+ @if test -f po/POTFILES.in; then
\
grep -E -v '^(#|$$)' po/POTFILES.in \
| grep -v '^src/false\.c$$' | sort [EMAIL PROTECTED];
\
files=; \
--
1.5.6.57.g6615b
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Packaged Java bindings for libvirt
Now that java is officially free, it's a good time to get the bindings the full support they deserve. This work is based on Tóth István ealier 0.0.1 version sent to the list. I refactored the tree a bit, added auto* configure capabilities, spec file and added it in CVS. I used a separate tree for CVS, I think we don't need to couple the releases for both. The package is named libvirt-java (no suprize), it compiles, build and seems to work fine on Fedora 9 with OpenJDK 6, compilation seems to also work with gcj but my build failed because jar failed to run du to a missing class... I'm really not a Java expert, I would really welcome addition from those who know, there is many things to be added: - ant makefile - Eclipse integration/makefile - making it work on Windows - completing the API to cover the full 0.4.x set - many things that Java experts will find missing ! I think we can keep this mailing-list as the primary channel for discussions. The CVS base is next to the libvirt one, use the same instructions but use 'co libvirt-java' instead of 'co libvirt', next thing I need to do is write a documentation page to put on libvirt.org. Anyway: libvirt-java-0.1.0 can be fetched from ftp://libvirt.org/libvirt/java/ I will submit this for Fedora inclusion too, feedback and patches very welcome. many thanks to Tóth, he's the one who did all the code, and he reviewed my first version :-) enjoy ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Packaged Java bindings for libvirt
Daniel Veillard schreef: I will submit this for Fedora inclusion too, feedback and patches very welcome. I wonder, now I have created a HTTP version of the (partial) API, would it be possible to get it adopted here? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] quiet make syntax-check
On Wed, Jun 25, 2008 at 04:14:41PM +0200, Jim Meyering wrote: [Here's a tiny patch, mainly to test our just-patched mailman. Note the patch below, included verbatim from git format-patch output. ] From c7ac46c5ea71bb17164b4f94bd83106b8001944d Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Tue, 13 May 2008 11:20:07 +0200 Subject: [PATCH] quiet make syntax-check * Makefile.maint (strftime-check): Add @ prefix. (po-check): Likewise. Went just fine. +1 for mailan fix, +1 for push to CVS :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Packaged Java bindings for libvirt
On Wed, Jun 25, 2008 at 04:50:11PM +0200, Stefan de Konink wrote: Daniel Veillard schreef: I will submit this for Fedora inclusion too, feedback and patches very welcome. I wonder, now I have created a HTTP version of the (partial) API, would it be possible to get it adopted here? Honnestly I'm still lost trying to understand what you wanted to do. I didn't understand the point, I just noted you wanted to put things in libvirtd, something about event API while to me i don't see the even side of the proposal. Now suggesting to convey this as part of Java *bindings* sounds even more confusing, how does that relate at all ? I'm lost, even more than before... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
Dan Smith wrote: DL The CLONE_NEWNET will fail if the network namespace is not DL compiled in. I understand this check but it looks like a little DL random. You are not 100% sure this clone has failed because the DL network namespace is not supported. That can be another subsystem DL or namespace which has failed during the initialization of the DL namespaces. The check is performed twice, once with the basic set of flags and again with CLONE_NEWNET. If the first check fails, we assume no LXC support (as we did before). If the second fails, we assume LXC but no NETNS. Is there something else I'm missing here? DL Why don't you simply check the presence of the 'netns' process ? That seems like a valid way as well, although we already do our feature checks by testing the clone. Also, by doing it this way, we have a better confirmation that an actual clone(CLONE_NEWNET) will work, IMHO. You are not doing clone(CLONE_NEWNET) in this code. You call clone(CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER|CLONE_NEWIPC|SIGCHLD|CLONE_NEWNET) When this call fails, you 'assume' netns is not compiled in. I agree the clone should have returned ENOSYS in this case, but it returns EINVAL and that do not means 'netns in not active'. If you look at the processes, you have a kthread called '[netns]', which indicates the network namespaces are actives in the kernel and this is not an assumption. DL Concerning iproute2, I think this is the work of the installer to DL check the dependencies, eg. the libvirt rpm depends on DL iproute2-x.y.z version rpm. Agreed, and I'm sure it will. Note DV's second comment here: https://www.redhat.com/archives/libvir-list/2008-June/msg00232.html In your code, you launch the ip command and if it fails with a particular exit code, you 'assume' netns is not supported. Another assumption ... IMHO you should rely on the package dependencies/command version. Or if you absolutely want to detect that at startup, perhaps doing ip link help | grep netns is more secure :) -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] MinGW environment for libvirt (at this moment))
On Thu, Jun 19, 2008 at 09:23:20AM +0900, Atsushi SAKAI wrote: Here is the update for instruction to make install on MinGW. (Since I goes to from make only to pass to make install) Hum, if that works maybe that should be made available from http://libvirt.org/windows.html 1.Install MinGW-5.1.4.exe [snip] 14.execute /usr/local/bin/virsh.exe Hope virsh.exe works on MinGW. If that works (I don't know), could you submit a patch for docs/windows.html.in to make a new Compiling from source separating the original Cygwin part and a new MinGW and either include those instructions or just link to the archive from there https://www.redhat.com/archives/libvir-list/2008-June/msg00145.html thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
DL You call DL clone(CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER|CLONE_NEWIPC|SIGCHLD|CLONE_NEWNET) DL When this call fails, you 'assume' netns is not compiled in. No, actually, I do this: int flags = CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER| CLONE_NEWIPC|SIGCHLD|extra_flags; Where extra_flags=0 for the LXC detection and extra_flags=CLONE_NEWNET for the NETNS detection. See the lxcCheckContainerSupport() calls in lxcProbe() and lxcCheckNetNsSupport(). DL In your code, you launch the ip command and if it fails with a DL particular exit code, you 'assume' netns is not supported. Another DL assumption The ip command returns a different error code for an invalid subcommand than for a failure of a known subcommand. That seems like a pretty reasonable sentinel (and certainly better than scraping the help output), IMHO. DL ... IMHO you should rely on the package dependencies/command DL version. Or if you absolutely want to detect that at startup, DL perhaps doing ip link help | grep netns is more secure :) DV has already said he'd like to see it done dynamically at the driver probe stage. I'll let him comment on his preferred way of doing that. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpmeZLY1dUi4.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] HTTP-API for libvirt
New thread. Honnestly I'm still lost trying to understand what you wanted to do. I have implemented a webserver plugin that allows (by mDNS) to access all 'VMs' on the network. http://xen.bot.nu/virt/ - demo I didn't understand the point, I just noted you wanted to put things in libvirtd, something about event API while to me i don't see the even side of the proposal. Using mDNS, mDNS events can be used on the network to subscribe to certain VM changes. Reboot/Shutdown/etc. Now suggesting to convey this as part of Java *bindings* sounds even more confusing, how does that relate at all ? You proposed (new) bindings for Java. I have written new bindings using the HTTP protocol. I wonder what should be done to get it adapted into libvirt, or standardize the format (like any other API). Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] ULLONG_MAX undeclared
Hi, I subscribed today on the list because I have a compilation problem of libvirt 0.4.2 and 0.4.3 (didn't try the other versions). I'm trying to compile libvirt on a Debian Etch with Xen 3.2.0 (also tried with a 3.2.1) Every time I have this mistake: storage_conf.c: In function 'virStorageSize': storage_conf.c:659: error: 'ULLONG_MAX' undeclared (first use in this function) storage_conf.c:659: error: (Each undeclared identifier is reported only once storage_conf.c:659: error: for each function it appears in.) make[2]: *** [libvirt_la-storage_conf.lo] Error 1 make[2]: Leaving directory `/usr/src/libvirt-0.4.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/libvirt-0.4.2' make: *** [all] Error 2 I looked for ULLONG_MAX and find it in /usr/include/limits.h and /usr/include/linux/kernel.h So first I decided to add #include limits.h inside storage_conf.c but it didn't change anything. Surely the definition of ULLONG_MAX is surrounded by an unwelcome condition. So actually to succeed the compilation I directly added: # define ULLONG_MAX 18446744073709551615ULL inside the files (storage_backend_fs.c need it too). I know that's dirty, so is there anybody who can help me to make it in a clean way? Thank you by advance. Best Regards, Alex -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ULLONG_MAX undeclared
On Wed, Jun 25, 2008 at 06:01:10PM +0200, [EMAIL PROTECTED] wrote: Hi, I subscribed today on the list because I have a compilation problem of libvirt 0.4.2 and 0.4.3 (didn't try the other versions). I'm trying to compile libvirt on a Debian Etch with Xen 3.2.0 (also tried with a 3.2.1) Every time I have this mistake: storage_conf.c: In function 'virStorageSize': storage_conf.c:659: error: 'ULLONG_MAX' undeclared (first use in this function) storage_conf.c:659: error: (Each undeclared identifier is reported only once storage_conf.c:659: error: for each function it appears in.) make[2]: *** [libvirt_la-storage_conf.lo] Error 1 make[2]: Leaving directory `/usr/src/libvirt-0.4.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/libvirt-0.4.2' make: *** [all] Error 2 I looked for ULLONG_MAX and find it in /usr/include/limits.h and /usr/include/linux/kernel.h So first I decided to add #include limits.h inside storage_conf.c but it didn't change anything. Surely the definition of ULLONG_MAX is surrounded by an unwelcome condition. On Fedora at least the definition is surrounded by a __USE_ISOC99. I'm not sure why that would work with Fedora but not with Debian. What version of GLibc and GCC is used on Debian Etch ? 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] HTTP-API for libvirt
On Wed, Jun 25, 2008 at 05:24:06PM +0200, Stefan de Konink wrote: New thread. Honnestly I'm still lost trying to understand what you wanted to do. I have implemented a webserver plugin that allows (by mDNS) to access all 'VMs' on the network. http://xen.bot.nu/virt/ - demo I didn't understand the point, I just noted you wanted to put things in libvirtd, something about event API while to me i don't see the even side of the proposal. Using mDNS, mDNS events can be used on the network to subscribe to certain VM changes. Reboot/Shutdown/etc. Now suggesting to convey this as part of Java *bindings* sounds even more confusing, how does that relate at all ? You proposed (new) bindings for Java. I have written new bindings using the HTTP protocol. I wonder what should be done to get it adapted into libvirt, or standardize the format (like any other API). If I'm understanding what you're doing, it is sort of a REST style web services API. It is also adding in certain higher level API semantics by using mDNS to aggregate info from multiple hosts ? As such its kind of straddling the boundary between being a service vs an application. I'd be interested in seeing the source to understand better what it is doing. I'd certainly be fine with adding it to our applications page on the website wiki. I'm wary of proprosing an 'offficial' web application since there are many people building web applications ontop of libvirt[1] I don't want to take sides saying one is better than the other. Daniel [1] Enomalism, oVirt and another I can't remember the name of, offhand. -- |: 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] Question about compilation on MinGW(StorageAPI)
On Wed, Jun 18, 2008 at 11:58:17AM +0900, Atsushi SAKAI wrote: Hi, Dan How about this? With this patch, make, make check, make syntax-check on libvirt is running (some test are skipped.). At this moment make install is failed on virsh install like this. The output is like thisat src directory # ../libtool --mode=install /usr/bin/install -c 'virsh.exe' '/usr/local/bin/virsh.exe' ../libtool: ./virsh.: No such file or directory I am investigating this issue at this moment. qemud/Makefile.am |2 ++ src/driver.h |4 src/internal.h|2 ++ src/libvirt.c |4 src/qemu_driver.c |8 src/remote_internal.c |6 ++ tests/Makefile.am |9 ++--- tests/testutils.c |5 - tests/testutilsqemu.c |3 ++- tests/virshtest.c |7 ++- 10 files changed, 44 insertions(+), 6 deletions(-) This patch looks good to me. 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
Re: [libvirt] HTTP-API for libvirt
Daniel P. Berrange schreef: If I'm understanding what you're doing, it is sort of a REST style web services API. Why is everyone using this REST buzzword lately? :D It is also adding in certain higher level API semantics by using mDNS to aggregate info from multiple hosts ? It is what I proposed to be in libvirtd (native support for clouds), but then implemented as a client application for libvirtd, that is a service provider for avahi. And a webserver plugin for Cherokee that is a client for avahi. Something as namespace collision prevention is something that is 'on going'. I propose to integrate the libvirtd-client/avahi-service provider (domumdns in the sourcetree) into libvirtd. As such its kind of straddling the boundary between being a service vs an application. It is. But you could also see it as a 'protocol' that is implemented by an application. What I want to get formalized how such protocol *should* look like. I'd be interested in seeing the source to understand better what it is doing. I'd certainly be fine with adding it to our applications page on the website wiki. http://repo.or.cz/w/handlervirt.git I'm wary of proprosing an 'offficial' web application since there are many people building web applications ontop of libvirt[1] I don't want to take sides saying one is better than the other. I don't want you to pick sides, but I want to get the 'protocol' formalised or at least molded into something that has been done for the Python API. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ULLONG_MAX undeclared
Thank you for the quick reply. - Daniel P. Berrange [EMAIL PROTECTED] wrote: On Fedora at least the definition is surrounded by a __USE_ISOC99. I'm not sure why that would work with Fedora but not with Debian. What version of GLibc and GCC is used on Debian Etch ? gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) and: libc-2.3.6 Alex PS: sorry for the direct reply -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
Dan Smith wrote: DL You call DL clone(CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER|CLONE_NEWIPC|SIGCHLD|CLONE_NEWNET) DL When this call fails, you 'assume' netns is not compiled in. No, actually, I do this: int flags = CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER| CLONE_NEWIPC|SIGCHLD|extra_flags; Where extra_flags=0 for the LXC detection and extra_flags=CLONE_NEWNET for the NETNS detection. See the lxcCheckContainerSupport() calls in lxcProbe() and lxcCheckNetNsSupport(). lxcCheckContainerSupport(0) = clone(CLONE_NEWPID| CLONE_NEWNS| CLONE_NEWUTS| CLONE_NEWUSER| CLONE_NEWIPC| SIGCHLD); lxcCheckNetNsSupport() = lxcCheckContainerSupport(CLONE_NEWNET) = clone(CLONE_NEWPID| CLONE_NEWNS| CLONE_NEWUTS| CLONE_NEWUSER| CLONE_NEWIPC| SIGCHLD|CLONE_NEWNET); Did I missed something ? DL In your code, you launch the ip command and if it fails with a DL particular exit code, you 'assume' netns is not supported. Another DL assumption The ip command returns a different error code for an invalid subcommand than for a failure of a known subcommand. That seems like a pretty reasonable sentinel (and certainly better than scraping the help output), IMHO. Who told to scrap the output :) Just verify the return code of the command. Anyway, catching a specific return code for an unknown subcommand makes sense for this check. DL ... IMHO you should rely on the package dependencies/command DL version. Or if you absolutely want to detect that at startup, DL perhaps doing ip link help | grep netns is more secure :) DV has already said he'd like to see it done dynamically at the driver probe stage. I'll let him comment on his preferred way of doing that. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
DL Did I missed something ? I think I misinterpreted your original statement, so let me go back. You said: DL When this call fails, you 'assume' netns is not compiled in. Why is this not an appropriate assumption? If I can't clone(CLONE_NETNS) for the check, then why should I not assume that this will fail later when I try to clone() to create the container itself (despite the presence or absence of netns support)? Would you argue that testing for basic container support is not reasonably accomplished by the existing clone() test? If I check for the presence of a kthread, which could go away if the implementation is changed down the road, then I would falsely conclude that the feature is not available. This test would fail, even though I could clone() with the flag and get the proper behavior... Correct? DL Who told to scrap the output :) Just verify the return code of the DL command. You're still scraping the output, just pushing the burden for doing so onto grep. But, fair enough :) DL Anyway, catching a specific return code for an unknown subcommand DL makes sense for this check. Okay, cool. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpwCP7xIX2bn.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4 of 4] [LXC] Add setup/cleanup of container network interfaces
DL Is it called when the last process of the container dies ? Yes, it (lxcVMCleanup()) is called from lxcSigHandler() which gets run if the container dies unexpectedly. It's also called from lxcDomainDestroy() which covers the 'shutdown' and 'destroy' cases as well. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgprE7tfPnxso.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
Dan Smith wrote: DL Did I missed something ? I think I misinterpreted your original statement, so let me go back. You said: DL When this call fails, you 'assume' netns is not compiled in. Why is this not an appropriate assumption? If I can't clone(CLONE_NETNS) for the check, then why should I not assume that this will fail later when I try to clone() to create the container itself (despite the presence or absence of netns support)? Would you argue that testing for basic container support is not reasonably accomplished by the existing clone() test? 1 - You use a combination of flags to check the network namespace is implemented. One of the namespaces can fail when trying to create it and the clone will fail, and you will deduce the network namespace is not compiled in. But you can do the assumption that never happens. 2 - You try to use only the CLONE_NEWNET flag, and that can fails for another reasons than it is not implemented. The network namespace initialization will trigger the initialization of probably more than one hundred network subsystems which can fail for some reasons. You can assume that never happens too. Honestly, these cases are not frequent but they exists. IMO, it is up to me to warn you when there are some corner cases like these. And it is up to you to consider you can ignore them because that happens only when we reach some limits. If I check for the presence of a kthread, which could go away if the implementation is changed down the road, then I would falsely conclude that the feature is not available. This test would fail, even though I could clone() with the flag and get the proper behavior... Correct? It is a good point. But I added this kthread because I needed a separate workq to cleanup the namespace, without this kthread the network namespace can not work properly. IMO, it will not be removed very soon :) But again, you can ignore that, if you prefer to use the 'ip' command. DL Who told to scrap the output :) Just verify the return code of the DL command. You're still scraping the output, just pushing the burden for doing so onto grep. But, fair enough :) DL Anyway, catching a specific return code for an unknown subcommand DL makes sense for this check. Okay, cool. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4 of 4] [LXC] Add setup/cleanup of container network interfaces
Dan Smith wrote: DL Is it called when the last process of the container dies ? Yes, it (lxcVMCleanup()) is called from lxcSigHandler() which gets run if the container dies unexpectedly. It's also called from lxcDomainDestroy() which covers the 'shutdown' and 'destroy' cases as well. So the container is supposed to stay alive until we explicitly shutdown it, right ? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
DL Honestly, these cases are not frequent but they exists. IMO, it is DL up to me to warn you when there are some corner cases like DL these. And it is up to you to consider you can ignore them because DL that happens only when we reach some limits. Fair enough :) DL It is a good point. But I added this kthread because I needed a DL separate workq to cleanup the namespace, without this kthread the DL network namespace can not work properly. IMO, it will not be DL removed very soon :) I'm not saying that will be, but it's a side effect of your implementation, which may or may not be present in a subsequent revision. DL But again, you can ignore that, if you prefer to use the 'ip' DL command. When it really comes down to it, it doesn't matter if the kernel support is present if the user doesn't have an updated 'ip' binary. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpLreJsR7PFS.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Change virsh list behavior
At the popular request of pretty much everyone in Sun who uses virsh...
Change virsh list to list all domains, and add an --active flag to
list only the active domains.
Signed-off-by: Ryan Scott [EMAIL PROTECTED]
--- a/src/virsh.c
+++ b/src/virsh.c
@@ -551,6 +551,7 @@ static vshCmdInfo info_list[] = {
static vshCmdOptDef opts_list[] = {
{inactive, VSH_OT_BOOL, 0, gettext_noop(list inactive domains)},
+{active, VSH_OT_BOOL, 0, gettext_noop(list only active domains)},
{all, VSH_OT_BOOL, 0, gettext_noop(list inactive active domains)},
{NULL, 0, 0, NULL}
};
@@ -559,13 +560,17 @@ static vshCmdOptDef opts_list[] = {
static int
cmdList(vshControl * ctl, vshCmd * cmd ATTRIBUTE_UNUSED)
{
-int inactive = vshCommandOptBool(cmd, inactive);
+int inactiveOpt = vshCommandOptBool(cmd, inactive);
+int activeOpt = vshCommandOptBool(cmd, active);
int all = vshCommandOptBool(cmd, all);
-int active = !inactive || all ? 1 : 0;
+int active, inactive;
int *ids = NULL, maxid = 0, i;
char **names = NULL;
int maxname = 0;
-inactive |= all;
+
+/* If no options are specified, default to both active and inactive */
+active = activeOpt || all || !inactiveOpt;
+inactive = inactiveOpt || all || !activeOpt;
if (!vshConnectionUsability(ctl, ctl-conn, TRUE))
return FALSE;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] MinGW environment for libvirt (at this moment))
Hi, Daniel Thank you for commenting this. I will post the procedure as next step(after commit the patch). Thanks Atsushi SAKAI Daniel Veillard [EMAIL PROTECTED] wrote: On Thu, Jun 19, 2008 at 09:23:20AM +0900, Atsushi SAKAI wrote: Here is the update for instruction to make install on MinGW. (Since I goes to from make only to pass to make install) Hum, if that works maybe that should be made available from http://libvirt.org/windows.html 1.Install MinGW-5.1.4.exe [snip] 14.execute /usr/local/bin/virsh.exe Hope virsh.exe works on MinGW. If that works (I don't know), could you submit a patch for docs/windows.html.in to make a new Compiling from source separating the original Cygwin part and a new MinGW and either include those instructions or just link to the archive from there https://www.redhat.com/archives/libvir-list/2008-June/msg00145.html thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] minor Solaris patches
Hi,
Most of the changes in the attached patch are trivial #ifdef
corrections for Solaris compilation.
The biggest part of the change gets 'virsh capabilities' running
correctly under Xen on Solaris.
Signed-off-by: Mark Johnson [EMAIL PROTECTED]
--- a/src/xs_internal.c
+++ b/src/xs_internal.c
@@ -35,7 +35,7 @@
#ifdef __linux__
#define XEN_HYPERVISOR_SOCKET /proc/xen/privcmd
-#elif define(__sun__)
+#elif defined(__sun)
#define XEN_HYPERVISOR_SOCKET /dev/xen/privcmd
#else
#error unsupported platform
--- a/src/xen_internal.c
+++ b/src/xen_internal.c
@@ -75,7 +75,7 @@ typedef struct v1_hypercall_struct
#define XEN_V1_IOCTL_HYPERCALL_CMD \
_IOC(_IOC_NONE, 'P', 0, sizeof(v1_hypercall_t))
typedef v1_hypercall_t hypercall_t;
-#elif define(__sun__)
+#elif defined(__sun)
typedef privcmd_hypercall_t hypercall_t;
#else
#error unsupported platform
@@ -340,8 +340,10 @@ lock_pages(void *addr, size_t len)
{
#ifdef __linux__
return (mlock(addr, len));
-#elif define(__sun)
+#elif defined(__sun)
return (0);
+#else
+#error unsupported platform
#endif
}
@@ -350,8 +352,10 @@ unlock_pages(void *addr, size_t len)
{
#ifdef __linux__
return (munlock(addr, len));
-#elif define(__sun)
+#elif defined(__sun)
return (0);
+#else
+#error unsupported platform
#endif
}
@@ -666,7 +670,7 @@ typedef struct xen_op_v2_dom xen_op_v2_d
#define XEN_HYPERVISOR_SOCKET /proc/xen/privcmd
#define HYPERVISOR_CAPABILITIES
/sys/hypervisor/properties/capabilities
#define CPUINFO/proc/cpuinfo
-#elif define(__sun__)
+#elif defined(__sun)
#define XEN_HYPERVISOR_SOCKET /dev/xen/privcmd
#define HYPERVISOR_CAPABILITIES
#define CPUINFO/dev/cpu/self/cpuid
@@ -1948,7 +1952,7 @@ xenHypervisorInit(void)
goto detect_v2;
}
-#ifndef __sun__
+#ifndef __sun
/*
* check if the old hypercall are actually working
*/
@@ -2265,6 +2269,92 @@ xenHypervisorBuildCapabilities(virConnec
return NULL;
}
+#ifdef __linux__
+void
+loadCapabilities(FILE *cpuinfo, FILE *capabilities, char *hvm_type,
+int *host_pae, char *line, int LINE_SIZE)
+{
+regmatch_t subs[4];
+
+/* /proc/cpuinfo: flags: Intel calls HVM vmx, AMD calls it svm.
+ * It's not clear if this will work on IA64, let alone other
+ * architectures and non-Linux. (XXX)
+ */
+if (cpuinfo) {
+while (fgets (line, LINE_SIZE, cpuinfo)) {
+if (regexec (flags_hvm_rec, line,
+sizeof(subs)/sizeof(regmatch_t), subs, 0) == 0
+ subs[0].rm_so != -1) {
+strncpy (hvm_type,
+ line[subs[1].rm_so], subs[1].rm_eo-subs[1].rm_so+1);
+hvm_type[subs[1].rm_eo-subs[1].rm_so] = '\0';
+} else if (regexec (flags_pae_rec, line, 0, NULL, 0) == 0)
+*host_pae = 1;
+}
+}
+
+/* Expecting one line in this file - ignore any more. */
+(void) fgets(line, LINE_SIZE, capabilities);
+}
+
+#else
+void
+loadCapabilities(FILE *cpuinfo, FILE *capabilities, char *hvm_type,
+int *host_pae, char *line, int LINE_SIZE)
+{
+struct {
+uint32_t r_eax, r_ebx, r_ecx, r_edx;
+} _r, *rp = _r;
+int d, cmd;
+char *s;
+hypercall_t hc;
+
+
+if ((d = open(CPUINFO, O_RDONLY)) == -1) {
+goto cpuinfo_open_fail;
+}
+
+if (pread(d, rp, sizeof (*rp), 0) != sizeof (*rp)) {
+goto cpuinfo_pread_fail;
+}
+
+s = (char *)rp-r_ebx;
+if (strncmp(s, Auth cAMD enti, 12) == 0) {
+if (pread(d, rp, sizeof (*rp), 0x8001) == sizeof (*rp)) {
+/* Read secure virtual machine bit (bit 2 of ECX feature ID) */
+if ((rp-r_ecx 2) 1) {
+strcpy(hvm_type, svm);
+}
+if ((rp-r_edx 6) 1) {
+*host_pae = 1;
+}
+}
+} else if (strncmp(s, Genu ntel ineI, 12) == 0) {
+if (pread(d, rp, sizeof (*rp), 0x0001) == sizeof (*rp)) {
+/* Read VMXE feature bit (bit 5 of ECX feature ID) */
+if ((rp-r_ecx 5) 1) {
+strcpy(hvm_type, vmx);
+}
+if ((rp-r_edx 6) 1) {
+*host_pae = 1;
+}
+}
+}
+cpuinfo_pread_fail:
+(void) close(d);
+cpuinfo_open_fail:
+
+d = open(XEN_HYPERVISOR_SOCKET, O_RDWR);
+hc.op = __HYPERVISOR_xen_version;
+hc.arg[0] = (unsigned long) XENVER_capabilities;
+hc.arg[1] = (unsigned long) line;
+cmd = IOCTL_PRIVCMD_HYPERCALL;
+(void) ioctl(d, cmd, (unsigned long) hc);
+close(d);
+}
+
+#endif
+
/**
* xenHypervisorGetCapabilities:
* @conn: pointer to the connection block
@@ -2278,7 +2368,8 @@ xenHypervisorMakeCapabilitiesXML(virConn
const char *hostmachine,
FILE *cpuinfo, FILE *capabilities)
{
-char line[1024], *str, *token;
+
Re: [libvirt] [PATCH] Change virsh list behavior
It looks good to me. +1 Thanks Atsushi SAKAI Ryan Scott [EMAIL PROTECTED] wrote: At the popular request of pretty much everyone in Sun who uses virsh... Change virsh list to list all domains, and add an --active flag to list only the active domains. Signed-off-by: Ryan Scott [EMAIL PROTECTED] -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Using Xen config files
Is it possible to directly utilize the Xen config files when using the python bindings for libvirt? If not, is there any automated method of converting the Xen config to a libvirt XML config? -- Thomas Moyer Graduate Student CSE Department Penn State University [EMAIL PROTECTED] http://www.cse.psu.edu/~tmmoyer PGP.sig Description: This is a digitally signed message part -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
