---
src/PVE/VZDump/LXC.pm | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/PVE/VZDump/LXC.pm b/src/PVE/VZDump/LXC.pm
index 21fb3c1..c984abb 100644
--- a/src/PVE/VZDump/LXC.pm
+++ b/src/PVE/VZDump/LXC.pm
@@ -9,6 +9,7 @@ use PVE::Cluster qw(cfs_read_file);
use PVE
On 07/31/2015 07:51 AM, Wolfgang Bumiller wrote:
On Thu, Jul 30, 2015 at 02:33:42PM +0200, Thomas Lamprecht wrote:
How about:
fieldLabel: 'root ' + gettext('password'),
So it's clear and translation doesn't becomes a problem.
Word order may differ across languages, though. The ideal soluti
On Thu, Jul 30, 2015 at 02:33:42PM +0200, Thomas Lamprecht wrote:
> How about:
>
> fieldLabel: 'root ' + gettext('password'),
>
>
> So it's clear and translation doesn't becomes a problem.
Word order may differ across languages, though. The ideal solution would
be to use a formatting print with
> >>But I would like to have full featured zfs and ceph support first.
>
> I'll work on ceph support.
>
> (I need it for a customer in cmoming months)
great!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/l
It's works fine for me with pve-kernel 4.1 from today git
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Jeudi 30 Juillet 2015 13:09:35
Objet: Re: [pve-devel] [PATCH] add vlan aware ifupdown script v3
> >>I tested with debian kernel:
>
> >>linux-image-4.1.0-t
>>But I would like to have full featured zfs and ceph support first.
I'll work on ceph support.
(I need it for a customer in cmoming months)
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Jeudi 30 Juillet 2015 14:04:56
Objet: Re: [pve-devel] lxc : disk file na
On 07/30/2015 04:02 PM, Dietmar Maurer wrote:
How about:
fieldLabel: 'root ' + gettext('password'),
So it's clear and translation doesn't becomes a problem.
This does not need to be the 'root' password at all (although it is currently)?
Yes, currently it's root. And the code suggests also t
> How about:
>
> fieldLabel: 'root ' + gettext('password'),
>
>
> So it's clear and translation doesn't becomes a problem.
This does not need to be the 'root' password at all (although it is currently)?
___
pve-devel mailing list
pve-devel@pve.proxmo
How about:
fieldLabel: 'root ' + gettext('password'),
So it's clear and translation doesn't becomes a problem.
On 07/30/2015 12:46 PM, Dietmar Maurer wrote:
I am not keen to to add that, because we need to re-translate it for all
languages.
Worse, 'root' is a system name, and it is quite uncl
> >>well, you just need an idea how to implement backup/restore/snapshots ...
> >>I guess it is possible, but it is really much work ...
>
> Yes, maybe for later releases
OK, thought a bit more about it, and I think we can implement it - it not really
that hard.
But I would like to have full fe
---
www/manager/lxc/Network.js | 115 +++--
1 file changed, 112 insertions(+), 3 deletions(-)
diff --git a/www/manager/lxc/Network.js b/www/manager/lxc/Network.js
index 5fe798c..7d152cc 100644
--- a/www/manager/lxc/Network.js
+++ b/www/manager/lxc/Network.j
---
src/PVE/VZDump/LXC.pm | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/PVE/VZDump/LXC.pm b/src/PVE/VZDump/LXC.pm
index 21fb3c1..6fad10f 100644
--- a/src/PVE/VZDump/LXC.pm
+++ b/src/PVE/VZDump/LXC.pm
@@ -9,6 +9,7 @@ use PVE::Cluster qw(cfs_read_file);
us
this patch recovers the config form the tarball.
It will nt recover the nework setting if you recover from OVZ
---
src/PVE/API2/LXC.pm | 30 +++-
src/PVE/LXCCreate.pm | 105 +++---
src/PVE/VZDump/ConvertOVZ.pm | 319 +++
src/PVE/VZD
>>well, you just need an idea how to implement backup/restore/snapshots ...
>>I guess it is possible, but it is really much work ...
Yes, maybe for later releases
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Jeudi 30 Juillet 2015 13:16:58
Objet: Re: [pve-deve
On Thu, Jul 30, 2015 at 12:36:04PM +0200, Dietmar Maurer wrote:
> > >>Besides, I am quite unsure it we want to add support for multiple disks
> > >>at this stage. This makes things like backup/restore much more complex.
> >
> > Ok, right. Maybe later when all features will be implemented ?
>
> H
> >>But multi-volume container is a bit too much for me, and it is
> >>unclear to me why we need it?
>
> to use different storages with different speed for example. (CT with ssd +
> hdd)
well, you just need an idea how to implement backup/restore/snapshots ...
I guess it is possible, but it is
> >>I tested with debian kernel:
>
> >>linux-image-4.1.0-trunk-amd64_4.1.2-1~exp1_amd64.deb
>
> >>that works.
>
> >>I also update pve-kernel to 4.1.3 (ubuntu wily):
>
> >>https://git.proxmox.com/?p=pve-kernel.git;a=summary
>
> >>but got same problem with this kernel.
>
> that's strange, any
---
src/PVE/LXCSetup/Debian.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/PVE/LXCSetup/Debian.pm b/src/PVE/LXCSetup/Debian.pm
index 4fa2be9..9d26c4b 100644
--- a/src/PVE/LXCSetup/Debian.pm
+++ b/src/PVE/LXCSetup/Debian.pm
@@ -113,7 +113,7 @@ sub setup_network {
>>But multi-volume container is a bit too much for me, and it is
>>unclear to me why we need it?
to use different storages with different speed for example. (CT with ssd + hdd)
>>Honestly, the plan was to support lxc.mount.entry, so that the user
>>can mount additional data (nfs, bind mounts).
I am not keen to to add that, because we need to re-translate it for all
languages.
Worse, 'root' is a system name, and it is quite unclear how to translate that
;-)
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mail
> >>Yes. Else people can use it for KVM (we need a way to avoid that).
>
> so, using ct- as prefix instead vm- could prevent that right ?
>
> ct-100-1.raw
ah, yes!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/ma
we need this for krbd volumes
Signed-off-by: Alexandre Derumier
---
src/PVE/API2/LXC.pm | 15 +++
src/PVE/LXC.pm | 12
2 files changed, 27 insertions(+)
diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
index 9e82bc4..f41d0df 100644
--- a/src/PVE/API2/LXC.pm
+
> >>Besides, I am quite unsure it we want to add support for multiple disks
> >>at this stage. This makes things like backup/restore much more complex.
>
> Ok, right. Maybe later when all features will be implemented ?
Honestly, the plan was to support lxc.mount.entry, so that the user
can mount
> >>do we really need to have rootfs or ext4fs in filename ?
>>Yes. Else people can use it for KVM (we need a way to avoid that).
so, using ct- as prefix instead vm- could prevent that right ?
ct-100-1.raw
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Jeu
>>I tested with debian kernel:
>>linux-image-4.1.0-trunk-amd64_4.1.2-1~exp1_amd64.deb
>>that works.
>>I also update pve-kernel to 4.1.3 (ubuntu wily):
>>https://git.proxmox.com/?p=pve-kernel.git;a=summary
>>but got same problem with this kernel.
that's strange, any difference in CONFIG files
It seems according to
http://pve.proxmox.com/pipermail/pve-user/2015-July/008954.html
some users get confused about this field.
---
www/manager/lxc/CreateWizard.js | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/www/manager/lxc/CreateWizard.js b/www/manager/lxc/CreateWizar
>> to store config,
>> the at vm_start,
>
>we update when you change 'pve.volid'. It is not really necessary to
>do it at start time.
oh ok, thanks.
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Jeudi 30 Juillet 2015 11:11:49
Objet: Re: [pve-devel] lxc : disk
>>Besides, I am quite unsure it we want to add support for multiple disks
>>at this stage. This makes things like backup/restore much more complex.
Ok, right. Maybe later when all features will be implemented ?
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Je
> So, it coud be easy to extend it to manage multiple disk
Besides, I am quite unsure it we want to add support for multiple disks
at this stage. This makes things like backup/restore much more complex.
___
pve-devel mailing list
pve-devel@pve.proxmox.c
> Oh, I didn't that It's almost what we are doing currently ?
yes
> pve.volid : storeid:volname
> lxc.rootfs: loop:/var/lib/vz/images/128/vm-128-rootfs.raw
>
>
>
> So, it coud be easy to extend it to manage multiple disk
>
> pve.volid1 : storeid:volname:/
> lxc.rootfs: loop:/var/lib/vz/images
> >>do we really need to have rootfs or ext4fs in filename ?
Yes. Else people can use it for KVM (we need a way to avoid that).
> for example : lxc.rootfs = .../100/vm-100-rootfs.raw
>
>
> if not, why not something generic like ct-$vmid-$i.raw ?
>
> (ct for container, vm for vms)
>
> lxc.roo
>>Also,
>>I see that currently we put loop,nbd in config with path
>>
>>lxc.rootfs = loop:/var/lib/vz/images/100/ct-100-1.raw
>>
>>I think we should do like in qemu
>>
>>lxc.rootfs = storeid:100/ct-100-1.raw
>>Then generate the path , activate_volumes with mounting loop,rbd at ct start.
>>
>>
>>I
While the previous strategy was enough for ipv6, ipv4 has
the concept of primary and secondary addresses (and
permanent, deprecated, ...), and so adding additional ip
addresses marked them as 'secondary'. The side effect of
this is that deleting the primary ip deletes all other ip
addresses within
The live ip address updating of running containers needs to
deal with dhcp and slaac settings by not trying to add these
keywords as ip addresses via the ip command.
(And fixing a typo...)
---
src/PVE/LXC.pm | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --
---
src/PVE/LXCSetup/Debian.pm | 8
src/PVE/LXCSetup/Redhat.pm | 5 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/PVE/LXCSetup/Debian.pm b/src/PVE/LXCSetup/Debian.pm
index 7635e08..4fa2be9 100644
--- a/src/PVE/LXCSetup/Debian.pm
+++ b/src/PVE/LXCSetup/Debian.pm
>>vm-$vmid-rootfs-$i.raw
>>
>>or
>>
>>vm-$vmid-ext4fs-$i.raw
>>
>>or
>>
>>vm-$vmid-lxc-$i.raw
>>
>>?
>>do we really need to have rootfs or ext4fs in filename ?
for example : lxc.rootfs = .../100/vm-100-rootfs.raw
if not, why not something generic like ct-$vmid-$i.raw ?
(ct for contain
Can be use by lxc (but also qemu)
Signed-off-by: Alexandre Derumier
---
PVE/Storage/RBDPlugin.pm | 25 +
1 file changed, 25 insertions(+)
diff --git a/PVE/Storage/RBDPlugin.pm b/PVE/Storage/RBDPlugin.pm
index 2c45a68..92df9eb 100644
--- a/PVE/Storage/RBDPlugin.pm
+++ b/P
> On July 30, 2015 at 9:18 AM Alexandre DERUMIER wrote:
>
>
> Currently for lxc,
>
> we create root disk with vm-$vmid-rootfs.raw.
>
> I'm thinking if we want to add multiple disk support, with different mount
> points,
>
> Could be use same format than qemu
>
> vm-$vmid-disk-$i
>
> Like
> > . sysctl tuning maybe ?
>
> >>I cannot find any relevant difference.
>
> I'm out of ideas
I tested with debian kernel:
linux-image-4.1.0-trunk-amd64_4.1.2-1~exp1_amd64.deb
that works.
I also update pve-kernel to 4.1.3 (ubuntu wily):
https://git.proxmox.com/?p=pve-kernel.git;
Currently for lxc,
we create root disk with vm-$vmid-rootfs.raw.
I'm thinking if we want to add multiple disk support, with different mount
points,
Could be use same format than qemu
vm-$vmid-disk-$i
Like this, we could re-use easily PVE::Storage.
(I'm thinking to add ceph krbd support)
__
This is fixed in qemu 2.4rc3
- Mail original -
De: "Wolfgang Bumiller"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Mercredi 29 Juillet 2015 10:33:51
Objet: Re: [pve-devel] Regression with latest qemu and iothreads option ?
On Wed, Jul 29, 2015 at 10:22:11AM +0200, Wolfgang Bumiller wrote:
> . sysctl tuning maybe ?
>>I cannot find any relevant difference.
I'm out of ideas
Not sure it's related, but here a patched iproute2, to avoir the truncated
display when too much vlans are defined.
http://odisoweb1.odiso.net/iproute2_4.1.1-1_amd64.deb
- Mail original -
42 matches
Mail list logo
