Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Dietmar Maurer
> >>Or is it good enough to use local ARP tables for that? > >> > >># cat /proc/net/arp > > oh, yes ! I didn't thinked about that. > it should be faster and a lot less overhead. yes, sometimes things are easier than expected ;-) ___ pve-devel mailing li

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Alexandre DERUMIER
>>Or is it good enough to use local ARP tables for that? >> >># cat /proc/net/arp oh, yes ! I didn't thinked about that. it should be faster and a lot less overhead. - Mail original - De: "Dietmar Maurer" À: "Alexandre DERUMIER" Cc: pve-devel@pve.proxmox.com Envoyé: Lundi 3 Mars

Re: [pve-devel] [PATCH] Add CT suspend/resume to PVE API

2014-03-02 Thread Dietmar Maurer
Please can you rebase your patch? Applying: Add CT suspend/resume to PVE API error: patch failed: PVE/API2/OpenVZ.pm:1391 error: PVE/API2/OpenVZ.pm: patch does not apply error: patch failed: PVE/OpenVZ.pm:1205 ... > -Original Message- > From: pve-devel [mailto:pve-devel-boun...@pve.proxmo

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Dietmar Maurer
> It's possible with ipset, to dynamicaly add to ipset ipmap, an src ip from a > iptables match Or is it good enough to use local ARP tables for that? # cat /proc/net/arp ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi

[pve-devel] spice shell script

2014-03-02 Thread Dietmar Maurer
Hi all, The spice API changed recently to avoid CSRF attacks (use POST instead of GET). So the shell script to connect (originally posted by Alexandre) is now a bit more complicated. I added a copy to /usr/share/doc/pve-manager/examples/spice-example-sh see https://git.proxmox.com/?p=pve-mana

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Dietmar Maurer
> It's possible with ipset, to dynamicaly add to ipset ipmap, an src ip from a > iptables match > > > "iptables -m mac --mac-source $macaddr -j SET --add-set tapxxxipmap src" > > > > So, maybe is it possible to create 1 ipset ipmap by tap device, and in tap-out > chain, add src(s) to tap ipset

Re: [pve-devel] Create template from CT

2014-03-02 Thread Dietmar Maurer
> I have made a few changes to the web GUI to add a new option under the > container context menu to make a template from a stopped container and > wanted to know if you would consider including it in the main distribution? This is basically the same as 'Backup' - so what are the advantages?

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Alexandre DERUMIER
Another Idea : It's possible with ipset, to dynamicaly add to ipset ipmap, an src ip from a iptables match "iptables -m mac --mac-source $macaddr -j SET --add-set tapxxxipmap src" So, maybe is it possible to create 1 ipset ipmap by tap device, and in tap-out chain, add src(s) to tap ipset.

Re: [pve-devel] Create template from CT

2014-03-02 Thread Daniel Hunsaker
Yes, at http://pve.proxmox.com/wiki/Developer_Documentation ; to "compile" the Ext.js code, simply run make (all it does is concatenate the various .js files together in an intelligent order). Immediate feedback: "createtemplate" is a tad on the long side for an API endpoint, and somewhat redunda

[pve-devel] Create template from CT

2014-03-02 Thread James A. Coyle
Hi all, I have made a few changes to the web GUI to add a new option under the container context menu to make a template from a stopped container and wanted to know if you would consider including it in the main distribution? I don't know how to compile the code from your git repo for testing

Re: [pve-devel] New Feature: ZFS 'generic' support for LUN management.

2014-03-02 Thread Daniel Hunsaker
> I might have misunderstand what you are trying to do. If I've followed this correctly, it's basically set it up to call a script instead of implementing things internally, and each storage entry (in storage.cfg) defines which script to call. So you have scripts for each LUN implementation you u

Re: [pve-devel] New Feature: ZFS 'generic' support for LUN management.

2014-03-02 Thread Michael Rasmussen
On Sun, 2 Mar 2014 07:50:09 + Dietmar Maurer wrote: > > Why do you want a single script? We can have multiple scripts, one for each > server type. > I might have misunderstand what you are trying to do. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Alexandre DERUMIER
>>Bu t i just noticed that we need 2 different marks, because we can traffic >>from VM1 to VM2. So we need 2 marks/zones? Yes, in 1line conntrack line, you have in/out. not sure how to implemented that, as they are only 1 mark or 1 zone field. - Mail original - De: "Dietmar Maurer"

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Alexandre DERUMIER
>>What is the disadvantage having that as default? Well, the default value is quite low (if I remember 64000). And in the past, I have had packets drop (when netfilter conntrack was enabled on bridges in kernel) because this really track all connections, also not yet established (like a syn fl

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Daniel Hunsaker
Another reason is that a user might have more VMs on their system than our default will allow. Granted, they'd need a really powerful server to do that, and would probably also know what to tweak to adapt, but a dynamic value allows us to allocate the resources we need instead of just an arbitrary

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Dietmar Maurer
> >>What is the advantage of using dynamic value? You want to save RAM? > I'm thinking of users who's have small server, will small ram and other users > who's have big server and big ram. > > But sure, we can tune net.netfilter.nf_conntrack_max, but users must be > warned to do it. What is the d

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Dietmar Maurer
Thanks for that link. Bu t i just noticed that we need 2 different marks, because we can traffic from VM1 to VM2. So we need 2 marks/zones? > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5 > d0aa2ccd4699a01cfdf14886191c249d7b45a01 > > netfilter: nf_conntrack: add sup

Re: [pve-devel] pvefw: using ctmark to associacte connections to VMs

2014-03-02 Thread Alexandre DERUMIER
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5d0aa2ccd4699a01cfdf14886191c249d7b45a01 netfilter: nf_conntrack: add support for "conntrack zones" Normally, each connection needs a unique identity. Conntrack zones allow to specify a numerical zone using the CT target, c