Re: [Libvir] [RFC] 1/3 Base linux container support
This patch all looks sensible. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 2/3 Config functions for managing linux containers
The code looks sensible, and its self-contained so +1. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 3/3 Driver functions for linux container support
Looks good. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
Dave Leskovec [EMAIL PROTECTED] wrote:
The following set of patches add the first batch of linux container
support to libvirt. The work is not complete but I wanted to start
getting some of this out for comments. This set of patches supports
the following:
Hi Dave,
Something (your mail client?) seems to have corrupted those patches
by removing leading spaces and splitting lines, so most of the parts
do not apply:
$ patch -p0 /t/p
patching file configure.in
patch: malformed patch at line 30: [ --with-qemu add
QEMU/KVM support (on)],[],[with_qemu=yes])
I know you said this is only preliminary,
so here are some mostly-superficial suggestions:
* please mark all new diagnostics with _(...), so that translators
see them. Since you add a new *Error function, please add its name to
the err_func_re definition in Makefile.maint. Then, running
make syntax-check will inform you of remaining unmarked strings.
Also, declare your new log function with the printf __attribute__,
so that gcc checks each format string against its arguments.
[Go ahead and add your new function for now, but I suspect there
should not be a new log function for each new subsystem.
These are all nearly-identical clones:
qemudReportError
virStorageReportError
ReportError
I hope someone finds the time to factor this out.
It's on my medium-term TODO list.
]
* check for strdup failure if the resulting pointer may be dereferenced
without being checked for NULL. There seem to be two of those:
one in lxcParseDomainName, the other in lxcLoadDriverConfig.
In each case, it looks like the pointer is later assumed to be
non-NULL and dereferenced (probable segfault).
* Something to think about:
People should be able to install libvirt using e.g., --prefix=/foo,
which would ideally make your code use /foo/etc/libvirt/lxc,
rather than the currently-hard-coded /etc/libvirt/lxc.
Or maybe that file name should be even more configurable...
Note that openvz_conf.c has a similar problem, though at least it
does work with --prefix=/usr/local.
* please use virBufferAddLit when there is no % directive:
$ grep -E 'virBufferVSprintf *\([^,]+, *[^%]+\)' /t/p
+if (virBufferVSprintf(buf, container\n) 0) {
+if (virBufferVSprintf(buf, /filesystem\n) 0) {
+if (virBufferVSprintf(buf, /container\n) 0) {
+if (virBufferVSprintf(buf, devices\n) 0) {
Jim
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
On Thu, Feb 21, 2008 at 11:11:40AM +0100, Jim Meyering wrote: Dave Leskovec [EMAIL PROTECTED] wrote: The following set of patches add the first batch of linux container support to libvirt. The work is not complete but I wanted to start getting some of this out for comments. This set of patches supports the following: Hi Dave, Something (your mail client?) seems to have corrupted those patches by removing leading spaces and splitting lines, so most of the parts do not apply: Which is one of the reason I usually prefer patch being sent as attachment. It also has the good property of giving them a name. 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: [Libvir] default hypervisor selection
DV What do people think ? I would be tempted to provide a patch to DV change do_open() behaviour on linux in the case name is NULL or DV , and then check what hypervisor might be present and running, This has been bugging me recently as well, so I'm definitely in favor of a change. Is there any reason not to also allow setting the default URI in an environment variable to solve the dual-hypervisor problem? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpjVT7Wc4yqR.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 1/3 Base linux container support
On Wed, Feb 20, 2008 at 10:24:49PM -0800, Dave Leskovec wrote: This patch contains the base linux container support * new switch --with-lxc to enable support (off by default) Any reason this can't be on-by-default ? I know OpenVZ is off by default but I'd like to see that on by default too. As it stands it never even gets compiled by most people so we don't see whether it breaks. Support for Linux containers can be enabled/disable by user on the fly just by rebooting into a new enough kernel, so we should enable it in libvirt no matter what probe at runtime if needed. * Add new source files to Makefile.am * Add define for lxc in driver.h * Add call to lxcRegister() in libvirt.c * Add define for errors from lxc in virterror.h * Add case for errors from lxc in virterror.c Rest of this patch looks fine. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 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: [Libvir] [RFC] 2/3 Config functions for managing linux containers
On Wed, Feb 20, 2008 at 10:25:11PM -0800, Dave Leskovec wrote:
This patch contains the new files lxc_conf.c and lxc_conf.h
This looks pretty good to me - you follow all our coding conventions
and use all the appropriate utility / helper functions. Only thing
I ca nfind to comment on so far is:
+lxc_vm_t *lxcFindVMByName(const lxc_driver_t *driver,
+ const char *name)
+{
+lxc_vm_t *vm;
+
+for (vm = driver-vms; vm; vm = vm-next) {
+if (!strcmp(vm-def-name, name)) {
+return vm;
+}
+}
+
+return NULL;
+}
Use STREQ() here instead of !strcmp
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 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: [Libvir] [RFC] 3/3 Driver functions for linux container support
On Wed, Feb 20, 2008 at 10:28:36PM -0800, Dave Leskovec wrote: This patch contains the new files lxc_driver.c and lxc_driver.h Looks fine to me. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 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: [Libvir] [RFC] 1/3 Base linux container support
On Thu, Feb 21, 2008 at 02:40:07PM +, Daniel P. Berrange wrote: On Wed, Feb 20, 2008 at 10:24:49PM -0800, Dave Leskovec wrote: This patch contains the base linux container support * new switch --with-lxc to enable support (off by default) Any reason this can't be on-by-default ? I know OpenVZ is off by default but I'd like to see that on by default too. As it stands it never even gets compiled by most people so we don't see whether it breaks. Actually I should clarify - it should be on by default *IF* configure is run on Linux - obviously not applicable for Solaris. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 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: [Libvir] default hypervisor selection
On Thu, Feb 21, 2008 at 09:26:38AM -0500, Daniel Veillard wrote:
While going though the ovirt installation steps I got annoyed with
the need to add -c qemu:///system each time we are trying to start a
virsh command if using KVM. The dfault setup is basically to assume
a Xen hypervisor if the URI is not specified, this is glued in the
do_open internal opening routine associated to the opening of connections:
--
static virConnectPtr
do_open (const char *name,
virConnectAuthPtr auth,
int flags)
{
int i, res;
virConnectPtr ret = NULL;
xmlURIPtr uri;
/* Convert NULL or to xen:/// for back compat */
if (!name || name[0] == '\0')
name = xen:///;
--
In one hand this is the default behaviour of the library, but
in my opinion it's not very smart. We should be able to be smarter than
that, for example:
- if /proc/xen doesn't exist (on linux, or /dev/xen on Solaris) well
we should not do that we are pretty sure we will get an error when
trying to connect
- if /proc/vz is present, well it's very likely that if the kernel
has been compiled with OpenVZ support, it's likely to be used as the
default virtualization
- if there is a kvm module loaded well we should probably use
qemu:///system if running as root or qemu:///session otherwise
I guess on Solaris an easy heuristic would allow to pick the right
hypervisor by default too.
At some point we may have multiple hypervisor support simultaneously
on a linux system thanks to pv_ops, but right now it doesn't make too
much sense to force a default Xen connection even when we know it won't
work.
For a virsh specific solution there is the VIRSH_DEFAULT_CONNECT_URI
environment variable, but it's not really user friendly and not very
generic,
I've proposed that we make this generic :
http://www.redhat.com/archives/libvir-list/2008-January/msg00234.html
I never got around to fixing the patch to also address the virsh issue
Soren raised, but I think we should do this env var.
What do people think ? I would be tempted to provide a patch to change
do_open() behaviour on linux in the case name is NULL or , and
then check what hypervisor might be present and running,
I think it is worthwhile - the 'default to Xen' behavious is a major cause
of pain for people initially using libvirt, particularly since KVM is
becoming the defacto standard for Linux platforms. I'd see the following
levels of customization:
- If a non-NULL URI is passed in virConnectOpen, use that
- Else if LIBVIRT_DEFAULT_URI is set use that URI
- Else probe each registered driver in order until one succeeds
For the latter I think we could add a 'probe' method to the internal driver
API table. Then we can just call 'probe' on each driver in turn until we
find one which is available on the system.
At the same time it could be worth having a public API to 'detect drivers'
which will call probe for each driver and return a list of all drivers
which are available. This allows an app to easily ask libvirt what it
supports - because long term we'll definitely get hosts supporting many
drivers at once. We can also advertise this list of supported drivers
using the Avahi mDNS broadcasts we do from the remote daemon.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 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
[Libvir] default hypervisor selection
While going though the ovirt installation steps I got annoyed with
the need to add -c qemu:///system each time we are trying to start a
virsh command if using KVM. The dfault setup is basically to assume
a Xen hypervisor if the URI is not specified, this is glued in the
do_open internal opening routine associated to the opening of connections:
--
static virConnectPtr
do_open (const char *name,
virConnectAuthPtr auth,
int flags)
{
int i, res;
virConnectPtr ret = NULL;
xmlURIPtr uri;
/* Convert NULL or to xen:/// for back compat */
if (!name || name[0] == '\0')
name = xen:///;
--
In one hand this is the default behaviour of the library, but
in my opinion it's not very smart. We should be able to be smarter than
that, for example:
- if /proc/xen doesn't exist (on linux, or /dev/xen on Solaris) well
we should not do that we are pretty sure we will get an error when
trying to connect
- if /proc/vz is present, well it's very likely that if the kernel
has been compiled with OpenVZ support, it's likely to be used as the
default virtualization
- if there is a kvm module loaded well we should probably use
qemu:///system if running as root or qemu:///session otherwise
I guess on Solaris an easy heuristic would allow to pick the right
hypervisor by default too.
At some point we may have multiple hypervisor support simultaneously
on a linux system thanks to pv_ops, but right now it doesn't make too
much sense to force a default Xen connection even when we know it won't
work.
For a virsh specific solution there is the VIRSH_DEFAULT_CONNECT_URI
environment variable, but it's not really user friendly and not very
generic,
What do people think ? I would be tempted to provide a patch to change
do_open() behaviour on linux in the case name is NULL or , and
then check what hypervisor might be present and running,
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: [Libvir] default hypervisor selection
On Thu, 2008-02-21 at 14:57 +, Daniel P. Berrange wrote: On Thu, Feb 21, 2008 at 02:51:20PM +, Richard W.M. Jones wrote: I'm mostly with Dan Berrange here. Surely an environment variable is the right thing to do, and then later we can add some advanced probing if the environment variable alone doesn't satisfy users. The only problem I see is making the NULL case unpredictable or introducing unreproducible bugs. But I guess that's not very likely. I agree - possible, but not likely too bad - I think we'll easily have a net win thanks to a more pleasant default end user experiance. (Re-suggesting something that was shot down before just in case it makes more sense to people this time around :-) I've never liked the fact that the individual drivers are exposed in the API and to the user. IMHO, the default behaviour for open(NULL), virsh, virt-manager etc. should be to talk to *all* drivers and aggregate the results. When you define a VM, that's the only time you should care about Xen vs. KVM etc. After that, it should just be a question of referring to a VM by name. The only time you should really need to specify a URI is when connecting to a remote host, IMHO. Adding a heuristic to select sensible driver by default won't help someone running e.g. KVM VMs and linux containers on the same host, which I don't think is such a crazy notion. Yes, you'd be trying to merge overlapping namespaces, but some ideas on that front: - If you simply prevent someone defining a VM using the same name as an existing VM defined via another driver, that gets you 90% there - Never aggregate a user's private namespace with the system namespace - e.g. for a normal user, an open(NULL) connection would only show the user's own VMs and we'd have another URI (or e.g. a virsh --system switch) for dealing with system-level VMs - If someone connects directly to a driver, or goes behind libvirt's back, and creates a VM with conflicting names, then just return an error if someone tries to perform an operation using the conflicting name ... and force the user to again connect to the specific driver or go behind libvirt's back - Also, figure out some way to deprecate the VM id attribute which is the most obvious point of conflict ... name and uuid should be enough identifiers, surely Cheers, Mark. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
On Wed, Feb 20, 2008 at 10:24:18PM -0800, Dave Leskovec wrote: The following set of patches add the first batch of linux container support to libvirt. The work is not complete but I wanted to start getting some of this out for comments. This set of patches supports the following: * new switch --with-lxc to enable linux container support (off by default) * virConnectOpen * virConnectClose * virConnectListDomains (of course none are listed since we can't start the containers yet) * virConnectNumOfDomains * virConnectListDefinedDomains * virConnectNumOfDefinedDomains * virDomainLookupByUUID * virDomainLookupByName * virDomainGetInfo * virDomainGetXMLDesc * virDomainDefineXML * virDomainUndefine A sample XML format that can be used to define a linux container domain: domain type='linuxcontainer' nameTestContainer3/name container filesystem type='mount' source dir='/home/user/lxc_files/etc/'/ target dir='/etc/'/ /filesystem filesystem type='mount' source dir='/home/user/lxc_files/var/'/ target dir='/var/'/ /filesystem init/usr/sbin/container_init/init /container memory65536/memory devices console tty='/dev/pts/4'/ /devices /domain Having thought about this all since our previous round of discussions on the matter I'm of the opinion we should /not/ use the container block for filesystem setup - it should be part of the devices block. This will simplify impl for apps which already have support for dealing with devices and hot add/remove (virDomainAttachDevice/virDomainDetachDevice). The init element can stay in container or perhap go inside an os block since that's where we describe booting for non-container virt. WRT to OpenVZ driver already using container we can change it to follow the new style - if we need compat we can let it continue to parse the old style too. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 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: [Libvir] default hypervisor selection
I'm mostly with Dan Berrange here. Surely an environment variable is the right thing to do, and then later we can add some advanced probing if the environment variable alone doesn't satisfy users. The only problem I see is making the NULL case unpredictable or introducing unreproducible bugs. But I guess that's not very likely. Dan's patch (http://www.redhat.com/archives/libvir-list/2008-January/msg00234.html) is fine except it should include a DEBUG() statement so we have some chance to gather information from bug reports about what it was actually trying to connect to. At the moment, the first DEBUG() isn't done until after the URI is parsed, and URI parsing is quite likely to be a failure point. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] default hypervisor selection
On Thu, Feb 21, 2008 at 03:26:08PM +, Mark McLoughlin wrote: On Thu, 2008-02-21 at 14:57 +, Daniel P. Berrange wrote: On Thu, Feb 21, 2008 at 02:51:20PM +, Richard W.M. Jones wrote: I'm mostly with Dan Berrange here. Surely an environment variable is the right thing to do, and then later we can add some advanced probing if the environment variable alone doesn't satisfy users. The only problem I see is making the NULL case unpredictable or introducing unreproducible bugs. But I guess that's not very likely. I agree - possible, but not likely too bad - I think we'll easily have a net win thanks to a more pleasant default end user experiance. (Re-suggesting something that was shot down before just in case it makes more sense to people this time around :-) I've never liked the fact that the individual drivers are exposed in the API and to the user. IMHO, the default behaviour for open(NULL), virsh, virt-manager etc. should be to talk to *all* drivers and aggregate the results. When you define a VM, that's the only time you should care about Xen vs. KVM etc. After that, it should just be a question of referring to a VM by name. The only time you should really need to specify a URI is when connecting to a remote host, IMHO. Adding a heuristic to select sensible driver by default won't help someone running e.g. KVM VMs and linux containers on the same host, which I don't think is such a crazy notion. Applications can explicitly connect to multiple drivers as desired. Yes, you'd be trying to merge overlapping namespaces, but some ideas on that front: - If you simply prevent someone defining a VM using the same name as an existing VM defined via another driver, that gets you 90% there Which we're unable to prevent. We are fundamentally dealing with different namespaces with both 'name' and 'id' values - any attempt to merge them is doomed to failure. The only globally unique identifier we have is UUID. - Never aggregate a user's private namespace with the system namespace - e.g. for a normal user, an open(NULL) connection would only show the user's own VMs and we'd have another URI (or e.g. a virsh --system switch) for dealing with system-level VMs - If someone connects directly to a driver, or goes behind libvirt's back, and creates a VM with conflicting names, then just return an error if someone tries to perform an operation using the conflicting name ... and force the user to again connect to the specific driver or go behind libvirt's back The name namespace is not under libvirt's control, and is fundamentally going to clash between virtualization backends. We merely have illusion of control wrt to QEMU because currently all QEMU guests are directly managed by libvirt - even this won't neccessarily be true long term if we implement the ability to manage externally started QEMU instances. - Also, figure out some way to deprecate the VM id attribute which is the most obvious point of conflict ... name and uuid should be enough identifiers, surely The ID number is very convenient because it is short simple and unique over the lifetime of a VM. The name is also unique, but name can change during the lifetime of a VM. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 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: [Libvir] default hypervisor selection
On Thu, Feb 21, 2008 at 09:26:38AM -0500, Daniel Veillard wrote: I guess on Solaris an easy heuristic would allow to pick the right hypervisor by default too. /dev/xen isn't quite right as it can exist even when not booted into dom0. # cat /dev/xen/domcaps control_d This should do it, though. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvir] [PATCH] Double free in openvzGetVPSInfo
On Thu, Feb 21, 2008 at 03:20:41PM +, Richard W.M. Jones wrote: On Thu, Feb 21, 2008 at 06:07:48PM +0300, Anton Protopopov wrote: Hi, without this openvzGetVPSInfo() will cause double free when parse bad (i.e., really bad or empty) output from vzlist. Patch applied, thanks. Can you send patches as attachments next time please. That one had the spaces munged so it didn't apply cleanly. Or at least make sure email client is configured to not mangle inline patches: http://lwn.net/Articles/249669/ Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 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: [libvir] [PATCH] Double free in openvzGetVPSInfo
On Thu, Feb 21, 2008 at 06:07:48PM +0300, Anton Protopopov wrote: Hi, without this openvzGetVPSInfo() will cause double free when parse bad (i.e., really bad or empty) output from vzlist. Patch applied, thanks. Can you send patches as attachments next time please. That one had the spaces munged so it didn't apply cleanly. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] default hypervisor selection
On Thu, Feb 21, 2008 at 02:36:10PM +, Daniel P. Berrange wrote: On Thu, Feb 21, 2008 at 09:26:38AM -0500, Daniel Veillard wrote: What do people think ? I would be tempted to provide a patch to change do_open() behaviour on linux in the case name is NULL or , and then check what hypervisor might be present and running, I think it is worthwhile - the 'default to Xen' behavious is a major cause of pain for people initially using libvirt, particularly since KVM is becoming the defacto standard for Linux platforms. I'd see the following levels of customization: - If a non-NULL URI is passed in virConnectOpen, use that - Else if LIBVIRT_DEFAULT_URI is set use that URI - Else probe each registered driver in order until one succeeds For the latter I think we could add a 'probe' method to the internal driver API table. Then we can just call 'probe' on each driver in turn until we find one which is available on the system. Yup, that's even better than ad-hoc attempt at detecting, it really should go in the driver. At the same time it could be worth having a public API to 'detect drivers' which will call probe for each driver and return a list of all drivers which are available. This allows an app to easily ask libvirt what it supports - because long term we'll definitely get hosts supporting many drivers at once. We can also advertise this list of supported drivers using the Avahi mDNS broadcasts we do from the remote daemon. That can be done in a second step, less urgent IMHO but useful too, 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: [Libvir] default hypervisor selection
On Thu, 2008-02-21 at 15:40 +, Daniel P. Berrange wrote: Yes, you'd be trying to merge overlapping namespaces, but some ideas on that front: - If you simply prevent someone defining a VM using the same name as an existing VM defined via another driver, that gets you 90% there Which we're unable to prevent. I was talking about the trivial case - prevent a user from creating a conflict using the default connection. That gets us the right thing in at least 90% of use cases IMHO. We are fundamentally dealing with different namespaces with both 'name' and 'id' values - any attempt to merge them is doomed to failure. Yes, they are fundamentally different namespaces. But the fact that they are fundamentally different namespaces is nothing but a hinderance to users, and fudging an aggregation of these fundamentally different namespaces should be both possible and beneficial to most users. Cheers, Mark. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH] Useless statement in openvzGetVPSInfo
Hi,
the patch is now in attachement..
I think, that the statement
if (!vm)
vm = *pnext;
will never be executed: in the first pass, we have already check this a few
lines before; in next passes, vm remains the same...
Anton
diff --git a/src/openvz_conf.c b/src/openvz_conf.c
index 79d1e90..c5b6588 100644
--- a/src/openvz_conf.c
+++ b/src/openvz_conf.c
@@ -530,9 +530,6 @@ openvzGetVPSInfo(virConnectPtr conn) {
goto error;
}
-if(!vm)
-vm = *pnext;
-
if (fscanf(fp, %d %s\n, veid, status) != 2) {
error(conn, VIR_ERR_INTERNAL_ERROR,
Failed to parse vzlist output);
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] Useless statement in openvzGetVPSInfo
On Thu, Feb 21, 2008 at 08:59:01PM +0300, Anton Protopopov wrote: Hi, the patch is now in attachement.. I think, that the statement if (!vm) vm = *pnext; will never be executed: in the first pass, we have already check this a few lines before; in next passes, vm remains the same... Anton Hum, that doesn't match what I see. vm is initialized to NULL on entry and no changed before the loop, so on first iteration of the loop vm is set using that code. I don't understand the logic of your patch, 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
Fwd: [Libvir] [PATCH] Useless statement in openvzGetVPSInfo
Oops, forgot the list... -- Forwarded message -- From: Anton Protopopov [EMAIL PROTECTED] Date: 21.02.2008 21:25 Subject: Re: [Libvir] [PATCH] Useless statement in openvzGetVPSInfo To: [EMAIL PROTECTED] I think, that if pnext = vm; and *pnext = calloc(...); then vm = calloc(...); Isn't it? 2008/2/21, Daniel Veillard [EMAIL PROTECTED]: On Thu, Feb 21, 2008 at 08:59:01PM +0300, Anton Protopopov wrote: Hi, the patch is now in attachement.. I think, that the statement if (!vm) vm = *pnext; will never be executed: in the first pass, we have already check this a few lines before; in next passes, vm remains the same... Anton Hum, that doesn't match what I see. vm is initialized to NULL on entry and no changed before the loop, so on first iteration of the loop vm is set using that code. I don't understand the logic of your patch, 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: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
Hi Jim, Thanks for the comments. I'll go back to attaching patches rather than putting them inline and make the other suggested changes. -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: Fwd: [Libvir] [PATCH] Useless statement in openvzGetVPSInfo
On Thu, Feb 21, 2008 at 09:38:21PM +0300, Anton Protopopov wrote: Oops, forgot the list... -- Forwarded message -- From: Anton Protopopov [EMAIL PROTECTED] Date: 21.02.2008 21:25 Subject: Re: [Libvir] [PATCH] Useless statement in openvzGetVPSInfo To: [EMAIL PROTECTED] I think, that if pnext = vm; and *pnext = calloc(...); then vm = calloc(...); Isn't it? 2008/2/21, Daniel Veillard [EMAIL PROTECTED]: On Thu, Feb 21, 2008 at 08:59:01PM +0300, Anton Protopopov wrote: Hi, the patch is now in attachement.. I think, that the statement if (!vm) vm = *pnext; will never be executed: in the first pass, we have already check this a few lines before; in next passes, vm remains the same... Anton Hum, that doesn't match what I see. vm is initialized to NULL on entry and no changed before the loop, so on first iteration of the loop vm is set using that code. I don't understand the logic of your patch, Well clearly I didn't understood the logic of the function :-) Maybe what's needed is a bit more than just removal to that dead code, 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: [Libvir] [RFC] 1/3 Base linux container support
Daniel P. Berrange wrote: On Wed, Feb 20, 2008 at 10:24:49PM -0800, Dave Leskovec wrote: This patch contains the base linux container support * new switch --with-lxc to enable support (off by default) Any reason this can't be on-by-default ? I know OpenVZ is off by default but I'd like to see that on by default too. As it stands it never even gets compiled by most people so we don't see whether it breaks. Support for Linux containers can be enabled/disable by user on the fly just by rebooting into a new enough kernel, so we should enable it in libvirt no matter what probe at runtime if needed. I left it off by default because OpenVZ is that way but also because compiles on older (pre 2.6.24) kernels will get errors due to missing CLONE flags in sched.h -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] Rewrite openvzSetUUID.
Jim Meyering [EMAIL PROTECTED] wrote: So here's that same patch without the useless fseek: diff --git a/src/openvz_conf.c b/src/openvz_conf.c index a274223..2e7b153 100644 I've committed that change: Rewrite openvzSetUUID. * src/openvz_conf.c (openvzSetUUID): Rewrite to avoid unchecked lseek, write, and close as well as a potential file descriptor leak. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
Daniel P. Berrange wrote: On Wed, Feb 20, 2008 at 10:24:18PM -0800, Dave Leskovec wrote: A sample XML format that can be used to define a linux container domain: domain type='linuxcontainer' nameTestContainer3/name container filesystem type='mount' source dir='/home/user/lxc_files/etc/'/ target dir='/etc/'/ /filesystem filesystem type='mount' source dir='/home/user/lxc_files/var/'/ target dir='/var/'/ /filesystem init/usr/sbin/container_init/init /container memory65536/memory devices console tty='/dev/pts/4'/ /devices /domain Having thought about this all since our previous round of discussions on the matter I'm of the opinion we should /not/ use the container block for filesystem setup - it should be part of the devices block. This will simplify impl for apps which already have support for dealing with devices and hot add/remove (virDomainAttachDevice/virDomainDetachDevice). The init element can stay in container or perhap go inside an os block since that's where we describe booting for non-container virt. That makes sense to me. I guess I'd lean towards leaving init in the container block since a container isn't really starting a new os image. Perhaps Dan Smith has some comments on this... -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: default hypervisor selection
Daniel Veillard wrote: - if /proc/xen doesn't exist (on linux, or /dev/xen on Solaris) well we should not do that we are pretty sure we will get an error when trying to connect - if /proc/vz is present, well it's very likely that if the kernel has been compiled with OpenVZ support, it's likely to be used as the default virtualization - if there is a kvm module loaded well we should probably use qemu:///system if running as root or qemu:///session otherwise While I definitely like the direction this thread is going in, I'd just warn that this sort of probing can be equally as harmful as the current behavior. While Xen and KVM are mutually exclusive, the same is not true with OpenVZ/Linux Containers. While it may be unlikely that both are actively being used, I find it very likely that in future distributions, both features will be present. So you may probe that this is a Linux Containers capable host, but you may in fact be intending on using KVM for virtualization (and vice versa). Regards, Anthony Liguori I guess on Solaris an easy heuristic would allow to pick the right hypervisor by default too. At some point we may have multiple hypervisor support simultaneously on a linux system thanks to pv_ops, but right now it doesn't make too much sense to force a default Xen connection even when we know it won't work. For a virsh specific solution there is the VIRSH_DEFAULT_CONNECT_URI environment variable, but it's not really user friendly and not very generic, What do people think ? I would be tempted to provide a patch to change do_open() behaviour on linux in the case name is NULL or , and then check what hypervisor might be present and running, Daniel -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
DL That makes sense to me. I guess I'd lean towards leaving init DL in the container block since a container isn't really starting a DL new os image. Perhaps Dan Smith has some comments on this... Oh I *always* have some comments... :) From the above example, init would be the only member of container, right? That seems broken to me, unless there are other things planned to be in container. In the context of a container, the value of init seems suited for the os block. From the view of a component that consumes the libvirt XML interface, I think I'd prefer avoiding more domain-level nodes, and would rather the relevant information be packed into existing areas (such as os and devices) instead of adding a new one (containers). -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpevy1GcnEjm.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [Discussion] 0/4 Implement DHCP host mappings for virtual networks
This is a series of patches to implement DHCP IP hostname mappings for libvirt virtual networks. ** NOTE: This patch is not to be applied. There is some memory corruption bug which I'm still tracking down. What this patch allows you to do is to create a table of IP address to host (defined by its hardware / MAC address) for each virtual network. Optionally you can also assign a hostname. When a host starts up and requests an IP address through DHCP, if it is in this table then it gets the fixed IP address from the table and, optionally, a fixed hostname. Four new API calls are added. Two are required to list the contents of the mapping table. Two more allow you to add and delete a mapping. The mapping table is semi-permanent. It is stored in /var/lib/libvirt/hosts-networkname.conf and survives across libvirtd restarts. The implementation simply uses dnsmasq's --dhcp-hostsfile flag. Refer to the dnsmasq(1) manual page. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] 2/4 QEMU driver
This patch implements the QEMU driver part of the change.
We run dnsmasq with the extra --dhcp-hostsfile=... parameter, and then
include functions to read and write this file.
When the file changes we send SIGHUP to dnsmasq.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
Index: src/driver.h
===
RCS file: /data/cvs/libvirt/src/driver.h,v
retrieving revision 1.42
diff -u -r1.42 driver.h
--- src/driver.h20 Feb 2008 15:06:53 - 1.42
+++ src/driver.h21 Feb 2008 20:43:48 -
@@ -377,6 +377,22 @@
(*virDrvNetworkSetAutostart)(virNetworkPtr network,
int autostart);
+typedef int
+(*virDrvNetworkNumOfDHCPHostMappings) (virNetworkPtr network);
+typedef int
+(*virDrvNetworkListDHCPHostMappings) (virNetworkPtr network,
+ virNetworkDHCPHostMappingPtr *const mappings,
+ int maxmappings);
+typedef int
+(*virDrvNetworkAddDHCPHostMapping) (virNetworkPtr network,
+ const char *hwaddr,
+ const char *ipaddr,
+ const char *hostname,
+ unsigned int flags);
+typedef int
+(*virDrvNetworkDeleteDHCPHostMapping) (virNetworkPtr network,
+ const char *hwaddr);
+
typedef struct _virNetworkDriver virNetworkDriver;
typedef virNetworkDriver *virNetworkDriverPtr;
@@ -410,6 +426,10 @@
virDrvNetworkGetBridgeName networkGetBridgeName;
virDrvNetworkGetAutostart networkGetAutostart;
virDrvNetworkSetAutostart networkSetAutostart;
+virDrvNetworkNumOfDHCPHostMappings networkNumOfDHCPHostMappings;
+virDrvNetworkListDHCPHostMappings networkListDHCPHostMappings;
+virDrvNetworkAddDHCPHostMappingnetworkAddDHCPHostMapping;
+virDrvNetworkDeleteDHCPHostMapping networkDeleteDHCPHostMapping;
};
Index: src/qemu_driver.c
===
RCS file: /data/cvs/libvirt/src/qemu_driver.c,v
retrieving revision 1.52
diff -u -r1.52 qemu_driver.c
--- src/qemu_driver.c 7 Feb 2008 16:50:17 - 1.52
+++ src/qemu_driver.c 21 Feb 2008 20:43:50 -
@@ -831,6 +831,7 @@
2 + /* --except-interface lo */
2 + /* --listen-address 10.0.0.1 */
1 + /* --dhcp-leasefile=path */
+1 + /* --dhcp-hostsfile=path */
(2 * network-def-nranges) + /* --dhcp-range 10.0.0.2,10.0.0.254 */
1; /* NULL */
@@ -884,6 +885,10 @@
LOCAL_STATE_DIR, network-def-name);
APPEND_ARG(*argv, i++, buf);
+snprintf(buf, sizeof(buf),
+ --dhcp-hostsfile= DHCP_HOSTS_FORMAT, network-def-name);
+APPEND_ARG(*argv, i++, buf);
+
range = network-def-ranges;
while (range) {
snprintf(buf, sizeof(buf), %s,%s,
@@ -914,6 +919,7 @@
dhcpStartDhcpDaemon(virConnectPtr conn,
struct qemud_network *network)
{
+char buf[PATH_MAX];
char **argv;
int ret, i;
@@ -923,6 +929,15 @@
return -1;
}
+/* Touch the DHCP hosts file so it exists before dnsmasq starts up. */
+snprintf (buf, sizeof buf, DHCP_HOSTS_FORMAT, network-def-name);
+ret = open (buf, O_CREAT|O_WRONLY, 0644);
+if (ret == -1) {
+qemudReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
+ %s: %s, buf, strerror (errno));
+return -1;
+}
+
argv = NULL;
if (qemudBuildDnsmasqArgv(conn, network, argv) 0)
return -1;
@@ -2853,6 +2868,302 @@
return 0;
}
+static void
+qemudFreeDHCPHostMappings (virNetworkDHCPHostMappingPtr *mappings,
+ int nr_mappings)
+{
+int i;
+
+for (i = 0; i nr_mappings; ++i)
+if (mappings[i]) {
+free (mappings[i]-hwaddr);
+free (mappings[i]-ipaddr);
+free (mappings[i]-hostname);
+free (mappings[i]);
+}
+free (mappings);
+}
+
+/* This allocates the array and returns the number of mappings in the
+ * array or -1 on error.
+ */
+static int
+qemudParseDHCPHostMappingsFile (virNetworkPtr net,
+struct qemud_network *network,
+virNetworkDHCPHostMappingPtr **mappings)
+{
+char buf[PATH_MAX];
+FILE *fp;
+int col;
+int lines = 0;
+int allocated = 0;
+char *str;
+char *token;
+char *saveptr = NULL;
+virNetworkDHCPHostMappingPtr *old_mappings;
+
+if (mappings) *mappings = NULL;
+
+snprintf (buf, sizeof buf, DHCP_HOSTS_FORMAT, network-def-name);
+fp = fopen (buf, r);
[Libvir] 3/4 Remote driver
This implements the changes in the client server ends of the remote
driver.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
Index: src/remote_internal.c
===
RCS file: /data/cvs/libvirt/src/remote_internal.c,v
retrieving revision 1.60
diff -u -r1.60 remote_internal.c
--- src/remote_internal.c 20 Feb 2008 15:23:36 - 1.60
+++ src/remote_internal.c 21 Feb 2008 20:44:08 -
@@ -2681,9 +2681,104 @@
return 0;
}
+static int
+remoteNetworkNumOfDHCPHostMappings (virNetworkPtr network)
+{
+remote_network_num_of_dhcp_host_mappings_args args;
+remote_network_num_of_dhcp_host_mappings_ret ret;
+GET_NETWORK_PRIVATE (network-conn, -1);
+
+make_nonnull_network (args.net, network);
+
+if (call (network-conn, priv, 0,
REMOTE_PROC_NETWORK_NUM_OF_DHCP_HOST_MAPPINGS,
+ (xdrproc_t) xdr_remote_network_num_of_dhcp_host_mappings_args,
(char *) args,
+ (xdrproc_t) xdr_remote_network_num_of_dhcp_host_mappings_ret,
(char *) ret) == -1)
+return -1;
+
+return ret.num;
+}
+
+
+static int
+remoteNetworkListDHCPHostMappings (virNetworkPtr network,
+ virNetworkDHCPHostMappingPtr *const
mappings,
+ int maxmappings)
+{
+remote_network_list_dhcp_host_mappings_args args;
+remote_network_list_dhcp_host_mappings_ret ret;
+int i;
+GET_NETWORK_PRIVATE (network-conn, -1);
+
+make_nonnull_network (args.net, network);
+args.maxmappings = maxmappings;
+if (call (network-conn, priv, 0,
REMOTE_PROC_NETWORK_LIST_DHCP_HOST_MAPPINGS,
+ (xdrproc_t) xdr_remote_network_list_dhcp_host_mappings_args,
(char *) args,
+ (xdrproc_t) xdr_remote_network_list_dhcp_host_mappings_ret,
(char *) ret) == -1)
+return -1;
+
+if (ret.mappings.mappings_len maxmappings) {
+error (network-conn, VIR_ERR_INTERNAL_ERROR,
+ _(remote end returned more mappings than we asked for));
+return -1;
+}
+
+/* We allocate them, caller frees. */
+for (i = 0; i ret.mappings.mappings_len; ++i) {
+mappings[i] = malloc (sizeof (virNetworkDHCPHostMapping));
+mappings[i]-hwaddr = ret.mappings.mappings_val[i].hwaddr;
+mappings[i]-ipaddr = ret.mappings.mappings_val[i].ipaddr;
+mappings[i]-hostname =
+ret.mappings.mappings_val[i].hostname == NULL ?
+NULL : *(ret.mappings.mappings_val[i].hostname);
+}
+
+return ret.mappings.mappings_len;
+}
+static int
+remoteNetworkAddDHCPHostMapping (virNetworkPtr network,
+ const char *hwaddr,
+ const char *ipaddr,
+ const char *hostname,
+ unsigned int flags)
+{
+remote_network_add_dhcp_host_mapping_args args;
+GET_NETWORK_PRIVATE (network-conn, -1);
+
+make_nonnull_network (args.net, network);
+args.hwaddr = (char *) hwaddr;
+args.ipaddr = (char *) ipaddr;
+args.hostname = hostname == NULL ? NULL : (char **) hostname;
+args.flags = flags;
+
+if (call (network-conn, priv, 0,
REMOTE_PROC_NETWORK_ADD_DHCP_HOST_MAPPING,
+ (xdrproc_t) xdr_remote_network_add_dhcp_host_mapping_args, (char
*) args,
+ (xdrproc_t) xdr_void, (char *) NULL) == -1)
+return -1;
+
+return 0;
+}
+
+static int
+remoteNetworkDeleteDHCPHostMapping (virNetworkPtr network,
+const char *hwaddr)
+{
+remote_network_add_dhcp_host_mapping_args args;
+GET_NETWORK_PRIVATE (network-conn, -1);
+
+make_nonnull_network (args.net, network);
+args.hwaddr = (char *) hwaddr;
+
+if (call (network-conn, priv, 0,
REMOTE_PROC_NETWORK_DELETE_DHCP_HOST_MAPPING,
+ (xdrproc_t) xdr_remote_network_delete_dhcp_host_mapping_args,
(char *) args,
+ (xdrproc_t) xdr_void, (char *) NULL) == -1)
+return -1;
+
+return 0;
+}
+
/*--*/
static int
@@ -4671,6 +4766,10 @@
.networkGetBridgeName = remoteNetworkGetBridgeName,
.networkGetAutostart = remoteNetworkGetAutostart,
.networkSetAutostart = remoteNetworkSetAutostart,
+.networkNumOfDHCPHostMappings = remoteNetworkNumOfDHCPHostMappings,
+.networkListDHCPHostMappings = remoteNetworkListDHCPHostMappings,
+.networkAddDHCPHostMapping = remoteNetworkAddDHCPHostMapping,
+.networkDeleteDHCPHostMapping = remoteNetworkDeleteDHCPHostMapping,
};
static virStorageDriver storage_driver = {
Index: qemud/remote.c
===
RCS file:
[Libvir] 4/4 virsh
This adds four new subcommands to virsh allowing you to control the
new functionality.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
Index: src/virsh.c
===
RCS file: /data/cvs/libvirt/src/virsh.c,v
retrieving revision 1.132
diff -u -r1.132 virsh.c
--- src/virsh.c 20 Feb 2008 15:29:13 - 1.132
+++ src/virsh.c 21 Feb 2008 20:44:28 -
@@ -2437,6 +2437,168 @@
/*
+ * net-dhcp-host-list command
+ */
+static vshCmdInfo info_network_dhcp_host_list[] = {
+{syntax, net-dhcp-host-list network},
+{help, gettext_noop(list DHCP host mappings on a network)},
+{desc, gettext_noop(Returns list of DHCP host mappings on a network.)},
+{NULL, NULL}
+};
+
+static vshCmdOptDef opts_network_dhcp_host_list[] = {
+{network, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(network name, id or
uuid)},
+{NULL, 0, 0, NULL}
+};
+
+static int
+cmdNetworkDHCPHostList (vshControl *ctl, vshCmd *cmd)
+{
+virNetworkPtr network;
+int i, ret;
+char *name;
+virNetworkDHCPHostMappingPtr *mappings;
+int nr_mappings;
+
+if (!vshConnectionUsability(ctl, ctl-conn, TRUE))
+return FALSE;
+
+if (!(network = vshCommandOptNetwork(ctl, cmd, network, name)))
+return FALSE;
+
+nr_mappings = virNetworkNumOfDHCPHostMappings (network);
+if (nr_mappings == -1) {
+virNetworkFree (network);
+return FALSE;
+}
+
+mappings =
+vshMalloc (ctl,
+ nr_mappings * sizeof (virNetworkDHCPHostMappingPtr));
+ret = virNetworkListDHCPHostMappings (network, mappings, nr_mappings);
+
+if (ret == -1) {
+virNetworkFree (network);
+return FALSE;
+}
+
+for (i = 0; i ret; ++i) {
+printf (%-20s %-20s , mappings[i]-hwaddr, mappings[i]-ipaddr);
+if (mappings[i]-hostname) printf (%s, mappings[i]-hostname);
+printf (\n);
+}
+
+virNetworkFreeDHCPHostMappings (mappings, nr_mappings);
+free (mappings);
+virNetworkFree(network);
+
+return TRUE;
+}
+
+
+/*
+ * net-dhcp-host-add command
+ */
+static vshCmdInfo info_network_dhcp_host_add[] = {
+{syntax, net-dhcp-host-list network hwaddr ipaddr [hostname]},
+{help, gettext_noop(add a DHCP host mappings)},
+{desc, gettext_noop(Adds a DHCP host mapping to the given network.)},
+{NULL, NULL}
+};
+
+static vshCmdOptDef opts_network_dhcp_host_add[] = {
+{network, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(network name, id or
uuid)},
+{hwaddr, VSH_OT_STRING, VSH_OFLAG_REQ, gettext_noop(hardware (MAC)
address)},
+{ipaddr, VSH_OT_STRING, VSH_OFLAG_REQ, gettext_noop(IP address)},
+{hostname, VSH_OT_STRING, VSH_OFLAG_NONE, gettext_noop(optional
hostname to assign over DHCP)},
+{NULL, 0, 0, NULL}
+};
+
+static int
+cmdNetworkDHCPHostAdd (vshControl *ctl, vshCmd *cmd)
+{
+virNetworkPtr network;
+int ret;
+char *name;
+char *hwaddr, *ipaddr, *hostname;
+
+if (!vshConnectionUsability(ctl, ctl-conn, TRUE))
+return FALSE;
+
+if (!(network = vshCommandOptNetwork(ctl, cmd, network, name)))
+return FALSE;
+
+if (!(hwaddr = vshCommandOptString (cmd, hwaddr, NULL))) {
+virNetworkFree (network);
+return FALSE;
+}
+if (!(ipaddr = vshCommandOptString (cmd, ipaddr, NULL))) {
+virNetworkFree (network);
+return FALSE;
+}
+
+hostname = vshCommandOptString (cmd, hostname, NULL);
+
+ret = virNetworkAddDHCPHostMapping (network, hwaddr, ipaddr, hostname, 0);
+if (ret == -1) {
+virNetworkFree (network);
+return FALSE;
+}
+
+virNetworkFree(network);
+
+return TRUE;
+}
+
+
+/*
+ * net-dhcp-host-delete command
+ */
+static vshCmdInfo info_network_dhcp_host_delete[] = {
+{syntax, net-dhcp-host-list network hwaddr},
+{help, gettext_noop(delete a DHCP host mappings)},
+{desc, gettext_noop(Deletes a DHCP host mapping from the given
network.)},
+{NULL, NULL}
+};
+
+static vshCmdOptDef opts_network_dhcp_host_delete[] = {
+{network, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(network name, id or
uuid)},
+{hwaddr, VSH_OT_STRING, VSH_OFLAG_REQ, gettext_noop(hardware (MAC)
address)},
+{NULL, 0, 0, NULL}
+};
+
+static int
+cmdNetworkDHCPHostDelete (vshControl *ctl, vshCmd *cmd)
+{
+virNetworkPtr network;
+int ret;
+char *name;
+char *hwaddr;
+
+if (!vshConnectionUsability(ctl, ctl-conn, TRUE))
+return FALSE;
+
+if (!(network = vshCommandOptNetwork(ctl, cmd, network, name)))
+return FALSE;
+
+if (!(hwaddr = vshCommandOptString (cmd, hwaddr, NULL))) {
+virNetworkFree (network);
+return FALSE;
+}
+
+ret = virNetworkDeleteDHCPHostMapping (network,
[Libvir] 1/4 Additions to the public API
This just adds the four new functions to the public API.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
Index: src/libvirt.c
===
RCS file: /data/cvs/libvirt/src/libvirt.c,v
retrieving revision 1.123
diff -u -r1.123 libvirt.c
--- src/libvirt.c 20 Feb 2008 16:54:36 - 1.123
+++ src/libvirt.c 21 Feb 2008 20:43:11 -
@@ -3683,6 +3683,194 @@
return -1;
}
+/**
+ * virNetworkNumOfDHCPHostMappings:
+ * @network: a network object
+ *
+ * Returns the number of DHCP host mappings, or -1 in case of error.
+ */
+int
+virNetworkNumOfDHCPHostMappings (virNetworkPtr network)
+{
+virConnectPtr conn;
+DEBUG(network=%p, network);
+
+if (!VIR_IS_NETWORK(network)) {
+virLibNetworkError (NULL, VIR_ERR_INVALID_NETWORK, __FUNCTION__);
+return -1;
+}
+
+conn = network-conn;
+
+if (conn-networkDriver
+conn-networkDriver-networkNumOfDHCPHostMappings)
+return conn-networkDriver-networkNumOfDHCPHostMappings (network);
+
+virLibConnError (conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
+return -1;
+}
+
+/**
+ * virNetworkListDHCPHostMappings:
+ * @network: a network object
+ * @mappings: an array of virNetworkDHCPHostMappingPtr
+ * @maxmappings: the length of the array
+ *
+ * This can be used to return a list of DHCP host mappings for the
+ * network.
+ *
+ * Use virNetworkFreeDHCPHostMappings to free the returned list.
+ *
+ * Returns the number of DHCP host mappings, or -1 in case of error.
+ */
+int
+virNetworkListDHCPHostMappings (virNetworkPtr network,
+virNetworkDHCPHostMappingPtr *const mappings,
+int maxmappings)
+{
+virConnectPtr conn;
+DEBUG(network=%p, mappings=%p, maxmappings=%d,
+ network, mappings, maxmappings);
+
+if (!VIR_IS_NETWORK(network)) {
+virLibNetworkError (NULL, VIR_ERR_INVALID_NETWORK, __FUNCTION__);
+return -1;
+}
+
+conn = network-conn;
+
+if (!mappings) {
+virLibNetworkError (conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
+return -1;
+}
+
+if (maxmappings == 0) return 0;
+
+memset (mappings, 0, sizeof (virNetworkDHCPHostMappingPtr) * maxmappings);
+
+if (conn-networkDriver
+conn-networkDriver-networkListDHCPHostMappings)
+return conn-networkDriver-networkListDHCPHostMappings (network,
+ mappings,
+ maxmappings);
+
+virLibConnError (conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
+return -1;
+}
+
+/**
+ * virNetworkFreeDHCPHostMappings:
+ * @mappings: an array of virNetworkDHCPHostMappingPtr
+ * @maxmappings: the length of the array
+ *
+ * Free the array of mappings returned by virNetworkListDHCPHostMappings.
+ *
+ * Return -1 on error or 0 on success.
+ */
+int
+virNetworkFreeDHCPHostMappings (virNetworkDHCPHostMappingPtr *const mappings,
+int maxmappings)
+{
+int i;
+
+DEBUG(mappings=%p, maxmappings=%d, mappings, maxmappings);
+
+if (!mappings) {
+virLibNetworkError (NULL, VIR_ERR_INVALID_ARG, __FUNCTION__);
+return -1;
+}
+
+for (i = 0; i maxmappings; ++i) {
+if (mappings[maxmappings]) {
+free (mappings[maxmappings]-hwaddr);
+free (mappings[maxmappings]-hostname);
+free (mappings[maxmappings]-ipaddr);
+free (mappings[maxmappings]);
+}
+}
+
+return 0;
+}
+
+/**
+ * virNetworkAddDHCPHostMapping:
+ * @network: a network object
+ * @hwaddr: hardware (MAC) address
+ * @ipaddr: IP address
+ * @hostname: hostname
+ * @flags: unused, pass 0
+ *
+ * Add a DHCP hardware address to IP address mapping, and optionally
+ * a DHCP hostname for the IP address (if hostname is not NULL).
+ *
+ * The mappings are keyed on the hardware (MAC) address. If the hardware
+ * address already has a mapping, then this call replaces it.
+ *
+ * Return -1 on error or 0 on success.
+ */
+int
+virNetworkAddDHCPHostMapping (virNetworkPtr network,
+ const char *hwaddr,
+ const char *ipaddr,
+ const char *hostname,
+ unsigned int flags)
+{
+virConnectPtr conn;
+DEBUG(network=%p, hwaddr=%s, hostname=%s, ipaddr=%s, flags=%d,
+ network, hwaddr, hostname, ipaddr, flags);
+
+if (!VIR_IS_NETWORK(network)) {
+virLibNetworkError (NULL, VIR_ERR_INVALID_NETWORK, __FUNCTION__);
+return -1;
+}
+
+conn = network-conn;
+
+if (flags != 0) {
+virLibNetworkError (NULL, VIR_ERR_INVALID_ARG,
Re: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
Dan Smith wrote: DL That makes sense to me. I guess I'd lean towards leaving init DL in the container block since a container isn't really starting a DL new os image. Perhaps Dan Smith has some comments on this... Oh I *always* have some comments... :) From the above example, init would be the only member of container, right? That seems broken to me, unless there are other things planned to be in container. Right. For a container, init would be the only member of os as well right? At the moment, I don't know of anything else that we will be adding to container. In the context of a container, the value of init seems suited for the os block. From the view of a component that consumes the libvirt XML interface, I think I'd prefer avoiding more domain-level nodes, and would rather the relevant information be packed into existing areas (such as os and devices) instead of adding a new one (containers). I guess my only hangup there is the case where the value of init specifies something that is not an init like application. In that case, at least to me, it seems less suited there. Of course, I don't know how likely or feasible such a use would be. I can definitely agree with your comments from a consumers perspective. I don't have a big problem with moving init to the os block. -- Best Regards, Dave Leskovec IBM Linux Technology Center Open Virtualization -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
DL Right. For a container, init would be the only member of os DL as well right? At the moment, I don't know of anything else that DL we will be adding to container. No, os contains lots of stuff, just none of it applies to a container :) From the perspective of a consumer of the interface, there is only one block that needs to be examined. If you put init in container, then I have to look at container (maybe) in addition to os (maybe). DL I guess my only hangup there is the case where the value of init DL specifies something that is not an init like application. In that DL case, at least to me, it seems less suited there. But from libvirt's perspective, it's still a virtual machine(-like) entity, regardless of what is really running inside. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpTx2iQ1VEmI.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] 1/4 Additions to the public API
On Thu, Feb 21, 2008 at 08:56:17PM +, Richard W.M. Jones wrote:
This just adds the four new functions to the public API.
[...]
+/**
+ * virNetworkDHCPHostMapping:
+ *
+ * hostname mappings are returned by virNetworkListDHCPHostMapping.
+ */
+typedef struct _virNetworkDHCPHostMapping {
+ char *hwaddr;
+ char *ipaddr;
+ char *hostname;
+} virNetworkDHCPHostMapping;
+
+typedef virNetworkDHCPHostMapping *virNetworkDHCPHostMappingPtr;
+
[...]
+int virNetworkListDHCPHostMappings
+(virNetworkPtr network,
+ virNetworkDHCPHostMappingPtr *const mappings,
+ int maxmappings);
+int virNetworkFreeDHCPHostMappings
+ (virNetworkDHCPHostMappingPtr *const
mappings,
+ int maxmappings);
Hum, do we really need to expose this structure at the API level, since we
use it only for listing. Since everything is provided as strings why not
use something like
int virNetworkListDHCPHostMappings (virNetworkPtr network,
int maxmappings,
char **hwaddrtab,
char **ipaddrtab,
char **hostnametab);
This also avoids the free function too, same functionality, quite a simpler
interface.
Also I don't understand the 'const' in that function and what
virNetworkFreeDHCPHostMappings is supposed to be used for. If mappings
is allocated by the user, it doesn't need a library deallocator, if it's
allocated by the library I can't see how it's const, the API confuses me
I must admit.
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: [Libvir] 1/4 Additions to the public API
On Thu, Feb 21, 2008 at 05:13:51PM -0500, Daniel Veillard wrote:
On Thu, Feb 21, 2008 at 08:56:17PM +, Richard W.M. Jones wrote:
This just adds the four new functions to the public API.
[...]
+/**
+ * virNetworkDHCPHostMapping:
+ *
+ * hostname mappings are returned by virNetworkListDHCPHostMapping.
+ */
+typedef struct _virNetworkDHCPHostMapping {
+ char *hwaddr;
+ char *ipaddr;
+ char *hostname;
+} virNetworkDHCPHostMapping;
+
+typedef virNetworkDHCPHostMapping *virNetworkDHCPHostMappingPtr;
+
[...]
+int virNetworkListDHCPHostMappings
+(virNetworkPtr network,
+ virNetworkDHCPHostMappingPtr *const mappings,
+ int maxmappings);
+int virNetworkFreeDHCPHostMappings
+ (virNetworkDHCPHostMappingPtr *const
mappings,
+ int maxmappings);
Hum, do we really need to expose this structure at the API level, since we
use it only for listing. Since everything is provided as strings why not
use something like
int virNetworkListDHCPHostMappings (virNetworkPtr network,
int maxmappings,
char **hwaddrtab,
char **ipaddrtab,
char **hostnametab);
This also avoids the free function too, same functionality, quite a simpler
interface.
Simpler for who ? Apps using this data now have to pass around a whole
bunch of pointers, instead of a single virNetworkDHCPHostMapping. When
you map this API into higher level languages a struct is also going to be
a much nicer thing to represent.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 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: [Libvir] [RFC] 0/3 Add Linux Container support to libvirt
On Thu, Feb 21, 2008 at 02:04:31PM -0800, Dan Smith wrote: DL Right. For a container, init would be the only member of os DL as well right? At the moment, I don't know of anything else that DL we will be adding to container. No, os contains lots of stuff, just none of it applies to a container :) From the perspective of a consumer of the interface, there is only one block that needs to be examined. If you put init in container, then I have to look at container (maybe) in addition to os (maybe). I always think of 'os' as providing data about the way your start the virtual machine. eg, the kernel / initrd for paravirt, the BIOS boot device for fullvirt, and thus. the 'init' process for containers. Oh, pretend you didn't see the 'bootloader' tag outside the os block. A historical mistake :-( Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 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: [Libvir] [PATCH]: Make iSCSI login actually work
On Thu, Feb 21, 2008 at 05:27:17PM -0500, Chris Lalancette wrote: Hello, I mentioned this before, but this patch must have been dropped when Dan committed storage stuff to CVS. In order for iSCSI login to work properly, you must properly --sendtargets before trying to login, otherwise your logins will fail. This patch just adds a --sendtargets command right before the login to make sure things succeed. ACK. Forgot to commit this. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 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: [Libvir] 1/4 Additions to the public API
On Thu, Feb 21, 2008 at 10:21:09PM +, Daniel P. Berrange wrote:
On Thu, Feb 21, 2008 at 05:13:51PM -0500, Daniel Veillard wrote:
On Thu, Feb 21, 2008 at 08:56:17PM +, Richard W.M. Jones wrote:
This just adds the four new functions to the public API.
[...]
+/**
+ * virNetworkDHCPHostMapping:
+ *
+ * hostname mappings are returned by virNetworkListDHCPHostMapping.
+ */
+typedef struct _virNetworkDHCPHostMapping {
+ char *hwaddr;
+ char *ipaddr;
+ char *hostname;
+} virNetworkDHCPHostMapping;
+
+typedef virNetworkDHCPHostMapping *virNetworkDHCPHostMappingPtr;
+
[...]
+int virNetworkListDHCPHostMappings
+(virNetworkPtr network,
+ virNetworkDHCPHostMappingPtr *const mappings,
+ int maxmappings);
+int virNetworkFreeDHCPHostMappings
+ (virNetworkDHCPHostMappingPtr *const
mappings,
+ int maxmappings);
Hum, do we really need to expose this structure at the API level, since we
use it only for listing. Since everything is provided as strings why not
use something like
int virNetworkListDHCPHostMappings (virNetworkPtr network,
int maxmappings,
char **hwaddrtab,
char **ipaddrtab,
char **hostnametab);
This also avoids the free function too, same functionality, quite a
simpler
interface.
Simpler for who ? Apps using this data now have to pass around a whole
bunch of pointers, instead of a single virNetworkDHCPHostMapping. When
you map this API into higher level languages a struct is also going to be
a much nicer thing to represent.
if the struct was a simpler representation it would be used for Add too,
I don't think it's the case. Maybe the 3 arrays is not the nicest but
defining a public structure holding 3 strings feels strange to me,
especially when in the other place we use the 3 strings directly.
Having a deallocator but no allocator function looks strange to me too.
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
[Libvir] [PATCH]: Make iSCSI login actually work
Hello,
I mentioned this before, but this patch must have been dropped when Dan
committed storage stuff to CVS. In order for iSCSI login to work properly, you
must properly --sendtargets before trying to login, otherwise your logins will
fail. This patch just adds a --sendtargets command right before the login to
make sure things succeed.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
--- /home/boston/clalance/devel/libvirt--devel/src/storage_backend_iscsi.c 2008-02-13 13:48:32.497466000 -0500
+++ libvirt-0.4.0/src/storage_backend_iscsi.c 2008-02-11 17:19:35.0 -0500
@@ -143,6 +143,14 @@ static int virStorageBackendISCSIConnect
--targetname, pool-def-source.devices[0].path, action, NULL
};
+const char *cmdsendtarget[] = {
+ISCSIADM, --mode, discovery, --type, sendtargets,
+--portal, portal, NULL
+};
+
+if (virRun(conn, (char **)cmdsendtarget, NULL) 0)
+return -1;
+
if (virRun(conn, (char **)cmdargv, NULL) 0)
return -1;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Please add RSS for libvirt updates.
Atsushi SAKAI wrote: Hi, I have a request about libvirt updates. Currently I am checking software updates by seeing RSS reader. Of course, mercurial(hg) and git creates RSS feeds. But CVS does not create such kind of feeds. I hope some day libvirt adds RSS feeds by using cvs2rss etc. http://laughingmeme.org/cvs2rss/ See http://git.et.redhat.com/?p=libvirt.git;a=summary -Ryan Thanks Atsushi SAKAI -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Please add RSS for libvirt updates.
Thanks! Its very helpful Thanks Atsushi SAKAI Ryan Scott [EMAIL PROTECTED] wrote: Atsushi SAKAI wrote: Hi, I have a request about libvirt updates. Currently I am checking software updates by seeing RSS reader. Of course, mercurial(hg) and git creates RSS feeds. But CVS does not create such kind of feeds. I hope some day libvirt adds RSS feeds by using cvs2rss etc. http://laughingmeme.org/cvs2rss/ See http://git.et.redhat.com/?p=libvirt.git;a=summary -Ryan Thanks Atsushi SAKAI -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Please add RSS for libvirt updates.
Hi, Ryan One question as just for confirmation, Does the libvirt git repository synchonize to the CVS repository? Thanks Atsushi SAKAI Atsushi SAKAI [EMAIL PROTECTED] wrote: Thanks! Its very helpful Thanks Atsushi SAKAI Ryan Scott [EMAIL PROTECTED] wrote: Atsushi SAKAI wrote: Hi, I have a request about libvirt updates. Currently I am checking software updates by seeing RSS reader. Of course, mercurial(hg) and git creates RSS feeds. But CVS does not create such kind of feeds. I hope some day libvirt adds RSS feeds by using cvs2rss etc. http://laughingmeme.org/cvs2rss/ See http://git.et.redhat.com/?p=libvirt.git;a=summary -Ryan Thanks Atsushi SAKAI -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
