Re: [libvirt] [PATCH] fix compilation for MinGW (with LXC)
On Fri, Jun 27, 2008 at 11:25:59AM +0900, Atsushi SAKAI wrote: Hello, Dan Smith May I commit this patch for MinGW compilation? veth.c is not necessary for MinGW. That sounds fine to me at least, 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] HTTP-API for libvirt
On Wed, Jun 25, 2008 at 06:27:00PM +0200, Stefan de Konink wrote:
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
Useful to distinguish from other web services APIs like SOAP or
WSDL. REST is nice crack-free :-)
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'.
How tied is the webserver plugin to Cherokee - I think you'd get more
interest if there was the option to plugin to apache, since Cherokee
isn't very widely used / known by comparison. Having never written
plugins for either I don't know if this is possible, but having a
generic plugin for the application logic and then bridges to apache,
cherokee other web servers would be nice.
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've had a quick look, but not got it up running due to not having
cherokee in Fedora. My first thought would be that the URL spec needs
to be more fine-grained / well-defined.
Virtual machine names are only guarenteed to be unique to a single host,
so with your avahi broadcasts aggregating info from multiple hosts you
will inevitably get namespace clashes based on name alone.
I'd provide several parallel URL spaces based on the different naming
/vm/{UUID}/
/host/{HOSTNAME}/vm/{NAME}
/host/{HOSTNAME}/vm/{ID}
UUID is guarenteed to be unique globally, while the other two are only
per-host unique. I included the /vm/ prefix under the /host/ so you
can also expose other bits of per-host information such as networking,
capabilities and device info, eg for virtual networks:
/vnet/{UUID}/
/host/{HOSTNAME}/vnet/{NAME}
I'd also thing of structuring it so that the default install just gives
info on a single host, and then have an add-on plugin to enable the
multi-host aggregration. You could have a /local/ shortcut URI to refer
to the /host/{HOSTNAME} of the local machine. This gives admins the
flexibility to run a mini web service on each node, or have a central
service on a 3rd part node.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] LXC veth.c issue
Hello, Dan Smith Please check your moveInterfaceToNetNs on veth.c **rc** and **len** have warning problem. http://builder.virt-manager.org/logs/modules/libvirt--devel-build-output.log P.S. Many Dan stay in this mailing list. Also My previous patch save this problem for general users but not for LXC users :-) Thanks Atsushi SAKAI -- 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:
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'.
How tied is the webserver plugin to Cherokee - I think you'd get more
interest if there was the option to plugin to apache, since Cherokee
isn't very widely used / known by comparison. Having never written
plugins for either I don't know if this is possible, but having a
generic plugin for the application logic and then bridges to apache,
cherokee other web servers would be nice.
I wrote it for Cherokee because I like Cherokee and I think Cherokee
kicks Apache + Lighttpd ass ;) No seriously I wrote it as real C code
plugin to get integration without dependencies on interpreter languages,
but I guess anyone would be able to do the same thing in Python, once a
standard has been set.
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've had a quick look, but not got it up running due to not having
cherokee in Fedora. My first thought would be that the URL spec needs
to be more fine-grained / well-defined.
There must be an RPM floating around, was on the mailinglist lately, but
since it is external plugin development, it is still a bit 'LFS' like to
get it running.
Virtual machine names are only guarenteed to be unique to a single host,
so with your avahi broadcasts aggregating info from multiple hosts you
will inevitably get namespace clashes based on name alone.
True, but my intention is to start the host from the webservice too.
Only if it is not present on the network. Exactly this can be prevented,
*if* libvirtd would look on the network (aka integrate all this in
libvirtd).
I'd provide several parallel URL spaces based on the different naming
/vm/{UUID}/
/host/{HOSTNAME}/vm/{NAME}
/host/{HOSTNAME}/vm/{ID}
UUID is guarenteed to be unique globally, while the other two are only
per-host unique. I included the /vm/ prefix under the /host/ so you
can also expose other bits of per-host information such as networking,
capabilities and device info, eg for virtual networks:
/vnet/{UUID}/
/host/{HOSTNAME}/vnet/{NAME}
I'd also thing of structuring it so that the default install just gives
info on a single host, and then have an add-on plugin to enable the
multi-host aggregration. You could have a /local/ shortcut URI to refer
to the /host/{HOSTNAME} of the local machine. This gives admins the
flexibility to run a mini web service on each node, or have a central
service on a 3rd part node.
I need the user as separate thing too, because I want to have different
users (thus different authentication). I don't really get why you want
to 'webservice' libvirt per host... but the current implementation will
work transparently. You can start it on any machine, and it would
probably be possible to only take 'local' avahi domains.
Stefan
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] [LXC] Remove unused variable and fix uninitialized variable
Also remove a stale comment in the area. This makes libvirt compile when
passed --with-lxc and --enable-compiler-warnings=error
diff -r bd08a3f22fb2 -r fa048279476d src/veth.c
--- a/src/veth.cThu Jun 26 16:09:48 2008 +
+++ b/src/veth.cFri Jun 27 06:48:10 2008 -0700
@@ -192,14 +192,12 @@
*/
int moveInterfaceToNetNs(const char* interface, int pidInNs)
{
-int rc;
-/* offset of the pid field in the following args */
+int rc = -1;
char *pid = NULL;
const char *argv[] = {
ip, link, set, interface, netns, NULL, NULL
};
int cmdResult;
-int len;
if (NULL == interface) {
goto error_out;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [LXC] Remove unused variable and fix uninitialized variable
On Fri, Jun 27, 2008 at 06:48:17AM -0700, Dan Smith wrote: Also remove a stale comment in the area. This makes libvirt compile when passed --with-lxc and --enable-compiler-warnings=error Sure, also see other feedback from Atsushi Sakai, 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] fix compilation for MinGW (with LXC)
AS May I commit this patch for MinGW compilation? veth.c is not AS necessary for MinGW. Yep, looks okay to me :) -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpzuL9xSI6Jh.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
