Re: [libvirt] static ip address
On Sat, Aug 2, 2008 at 11:22 PM, Fabian Deutsch [EMAIL PROTECTED]wrote: Hey, I'm using KVM with the wonderful help of libvir (virsh), on a to-be-production-ready server of mine. I would like to be able to choose on a way or another the ip of each of my VM. As far as I can understand, the only way to get an IP (from a vm point of view) if the dhcp it. But I have no garantee vm1 will always get x.x.x.1 Ip adress... I suppose you are speaking about the NAt-Solution. Yes. Sorry. My server has 1 public IP address. Host will host an Apache proxying http services hosted by VMs. VMs will have private IP addresses (192.168.0.x). I can not have any other public IP addresses, so bridging is not a solution (AFAICU) Nat seems good choice in my case, I think. Have a look at some bridge-Solution: http://libvirt.org/formatnetwork.html#examplesRoute Ok. You are proposing me to use : network namelocal/name bridge name=virbr1 / forward mode=route dev=eth1/ ip address=192.168.122.1 netmask=255.255.255.0 dhcp range start=192.168.122.2 end=192.168.122.254 / /dhcp /ip /network I understand this defines a network, where IP address of host in VM-World is 192.168.122.1, and DHCP distributes IP addresses to VMs. Nat is disabled ? I just don't understand how I can specify that VM1 (with its mac address), should have .1 IP address. Natting will be automagic ? I must admit I don't really know how to use routing system, I presume :( Thanx for your help, http://libvirt.org/formatnetwork.html#examplesRoute - fabian Olivier. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt-java storage support and refactoring
On Sat, Aug 02, 2008 at 05:42:36PM +0200, Tóth István wrote:
Hello!
Welcome back :-)
This patch contains the following:
- The complete storage handling API
- Fixing memory leaks in the VirConnect JNI implementation
Very cool !
I've written the new classes using a new approach.
I've found that libvirt for the most part has a very perdicitble and
repetitive API (great design!), and as a result I've found myself
copying the same code over and over again.
I've decided to make generic JNI functions, that can handle multiple
libvirt functions with function pointers.
The generic functions are in generic.c and they are used extensively in
the new Storage JNI implementation.
I'd like to have your input on this architecture, my current plan is to
refactor all trivial JNI functions to use these generics, unless there
are objections.
The positive aspects of the new architecture:
- No code duplication, one generic function fix affects all similar
functions
- Less code
The negative aspects:
- Ugly syntax (but JNI is ugly enough already)
- Easier to make errors in JNI code due to function type casts.
I think that the benefits outweigh the negatives, esepecialy when we
start cleaning up memory allocation, 64/32 bit cleannes stuff,
threading, it will have to be done in one function, instead of 3 or 30
cut'n'pasted ones, scattered in 5 files.
Hum, I'm missing something jst by looking at the patch
JNIEXPORT jlong JNICALL Java_org_libvirt_Connect__1virNetworkCreateXML
- (JNIEnv *env, jobject obj, jlong VCP, jstring xmlDesc){
- return (jlong)virNetworkCreateXML((virConnectPtr)VCP,
(*env)-GetStringUTFChars(env, xmlDesc, NULL));
+ (JNIEnv *env, jobject obj, jlong VCP, jstring j_xmlDesc){
+ const char *xmlDesc=(*env)-GetStringUTFChars(env, j_xmlDesc, NULL);
+ jlong retval = (jlong)virNetworkCreateXML((virConnectPtr)VCP, xmlDesc);
+ (*env)-ReleaseStringUTFChars(env, j_xmlDesc, xmlDesc);
+ return retval;
}
How is it smaller code ?
It seems to be that the old code didn't ever tried to free allocated strings
and the new one does, which is the explanation of the code grows. I would side
with Chris on the usage of macros instead of call like this. There is 2 reasons
one is the readability, but also the static type checking. Bindings code is
as you noticed boring, repetitive, and a mistake there is easy. My approach
was to automate (as much as possible) the bindings for python based on the
XML description. But that's incomplete, manual bindings are fine, the best is
to try to avoid mistake due to repetitive nature of the code.
I would try an approach which allows the compiler to do the full type checking,
I think that's the best way to avoid some of the mistakes, it won't prevent
forgetting a piece of deallocation for example, but will catch mistakes in
arguments at least.
But I'm not opposed to a less flexible approach, I just try to weight the
pros and cons :-)
thanks a lot !
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] dnsmasq option in network XML file
Hi All, I would like to know if it's possible to configure in the network XML file more option than DHCP range like default gateway, static route, dns and so on... I fact I need to set up a complex virtual network with 3 DMZ and I would really appreciate to did it with virt-manager. Thank for your help... Didier. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] static ip address
lør, 02 08 2008 kl. 23:13 +0200, skrev Olivier Deckmyn: I would like to be able to choose on a way or another the ip of each of my VM. As far as I can understand, the only way to get an IP (from a vm point of view) if the dhcp it. But I have no garantee vm1 will always get x.x.x.1 Ip adress... This has been discussed previously, see https://www.redhat.com/archives/libvir-list/2008-April/msg00327.html -- Mads Chr. Olesen [EMAIL PROTECTED] shiyee.dk -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] When are volumes 'detected' / refreshed
Stefan de Konink wrote: At what time are volumes currently detected on NetFS? I see there is some sort of storage now going on, since deleting files from NFS doesn't delete them from vol-list directly. (If this is fixed in a recent version... I'm sorry to bother) I haven't scoured the code, so I'm not sure if a pool will ever auto update its vol list aside from the initial lookup (I'm guessing not), but you can trigger this with the virStoragePoolRefresh function. - Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] fix syntax check error
Hi, This patch fixes syntax error(found TAB(s)) http://builder.virt-manager.org/module-libvirt--devel.html Thanks Atsushi SAKAI fix_typo20080804.patch Description: Binary data -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt-java storage support and refactoring
On Sun, 2008-08-03 at 05:56 -0400, Daniel Veillard wrote:
On Sat, Aug 02, 2008 at 05:42:36PM +0200, Tóth István wrote:
Hello!
Welcome back :-)
This patch contains the following:
- The complete storage handling API
- Fixing memory leaks in the VirConnect JNI implementation
Very cool !
I've written the new classes using a new approach.
I've found that libvirt for the most part has a very perdicitble and
repetitive API (great design!), and as a result I've found myself
copying the same code over and over again.
I've decided to make generic JNI functions, that can handle multiple
libvirt functions with function pointers.
The generic functions are in generic.c and they are used extensively in
the new Storage JNI implementation.
I'd like to have your input on this architecture, my current plan is to
refactor all trivial JNI functions to use these generics, unless there
are objections.
The positive aspects of the new architecture:
- No code duplication, one generic function fix affects all similar
functions
- Less code
The negative aspects:
- Ugly syntax (but JNI is ugly enough already)
- Easier to make errors in JNI code due to function type casts.
I think that the benefits outweigh the negatives, esepecialy when we
start cleaning up memory allocation, 64/32 bit cleannes stuff,
threading, it will have to be done in one function, instead of 3 or 30
cut'n'pasted ones, scattered in 5 files.
Hum, I'm missing something jst by looking at the patch
JNIEXPORT jlong JNICALL Java_org_libvirt_Connect__1virNetworkCreateXML
- (JNIEnv *env, jobject obj, jlong VCP, jstring xmlDesc){
- return (jlong)virNetworkCreateXML((virConnectPtr)VCP,
(*env)-GetStringUTFChars(env, xmlDesc, NULL));
+ (JNIEnv *env, jobject obj, jlong VCP, jstring j_xmlDesc){
+ const char *xmlDesc=(*env)-GetStringUTFChars(env, j_xmlDesc, NULL);
+ jlong retval = (jlong)virNetworkCreateXML((virConnectPtr)VCP, xmlDesc);
+ (*env)-ReleaseStringUTFChars(env, j_xmlDesc, xmlDesc);
+ return retval;
}
How is it smaller code ?
Actually, that's not the new-style code, It's just the bugfixed one. I
have not converted that file yet.
To see the new style code, look at the *Storage*.c files.
A similar function looks like this there:
JNIEXPORT jlong JNICALL Java_org_libvirt_StoragePool__1storageVolCreateXML
(JNIEnv *env, jobject obj, jlong VSPP, jstring xmlDesc, jint flags){
return generic_CreateDefineXML_with_flags(env, obj, VSPP, xmlDesc, flags,
(void* (*)(void*, const char *, unsigned int))virStorageVolCreateXML);
}
It seems to be that the old code didn't ever tried to free allocated strings
and the new one does, which is the explanation of the code grows. I would side
with Chris on the usage of macros instead of call like this. There is 2
reasons
one is the readability, but also the static type checking.
Actually, the old-style function does static type checking, it's just
new style that suffers there.
Using macros is a great idea, that may get rid of all those nasty casts.
Bindings code is
as you noticed boring, repetitive, and a mistake there is easy. My approach
was to automate (as much as possible) the bindings for python based on the
XML description. But that's incomplete, manual bindings are fine, the best is
to try to avoid mistake due to repetitive nature of the code.
I would try an approach which allows the compiler to do the full type
checking,
I think that's the best way to avoid some of the mistakes, it won't prevent
forgetting a piece of deallocation for example, but will catch mistakes in
arguments at least.
But I'm not opposed to a less flexible approach, I just try to weight the
pros and cons :-)
thanks a lot !
Daniel
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt-java storage support and refactoring
On Mon, Aug 04, 2008 at 07:46:05AM +0200, Toth Istvan wrote:
On Sun, 2008-08-03 at 05:56 -0400, Daniel Veillard wrote:
How is it smaller code ?
Actually, that's not the new-style code, It's just the bugfixed one. I
have not converted that file yet.
heh, okay :-)
To see the new style code, look at the *Storage*.c files.
A similar function looks like this there:
JNIEXPORT jlong JNICALL Java_org_libvirt_StoragePool__1storageVolCreateXML
(JNIEnv *env, jobject obj, jlong VSPP, jstring xmlDesc, jint flags){
return generic_CreateDefineXML_with_flags(env, obj, VSPP, xmlDesc, flags,
(void* (*)(void*, const char *, unsigned int))virStorageVolCreateXML);
}
ah, yes, I see now !
It seems to be that the old code didn't ever tried to free allocated
strings
and the new one does, which is the explanation of the code grows. I would
side
with Chris on the usage of macros instead of call like this. There is 2
reasons
one is the readability, but also the static type checking.
Actually, the old-style function does static type checking, it's just
new style that suffers there.
Using macros is a great idea, that may get rid of all those nasty casts.
yes that's probably the best alternative,
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
