---
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);
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 diet...@proxmox.com
À: aderumier aderum...@odiso.com
Cc: pve-devel pve-devel@pve.proxmox.com
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
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 +++
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 featured
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.proxmox.com
---
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
+++
It's works fine for me with pve-kernel 4.1 from today git
- Mail original -
De: dietmar diet...@proxmox.com
À: aderumier aderum...@odiso.com
Cc: pve-devel pve-devel@pve.proxmox.com
Envoyé: Jeudi 30 Juillet 2015 13:09:35
Objet: Re: [pve-devel] [PATCH] add vlan aware ifupdown script v3
I
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
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 diet...@proxmox.com
À: aderumier aderum...@odiso.com
Cc: pve-devel pve-devel@pve.proxmox.com
Envoyé: Jeudi 30 Juillet
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 a
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
In commit 8d70213 we started to generate pveui.js from include/ui.js
with a patch, but the same patch was applied to master and stable 3
branch. So there was only lxc and when we try to open a noVNC
console on a OpenVZ container a implement me exception gets thrown
and the window shows nothing.
On July 30, 2015 at 9:18 AM Alexandre DERUMIER aderum...@odiso.com 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
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 container, vm for vms)
. 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):
Can be use by lxc (but also qemu)
Signed-off-by: Alexandre Derumier aderum...@odiso.com
---
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
---
. 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 -
This is fixed in qemu 2.4rc3
- Mail original -
De: Wolfgang Bumiller w.bumil...@proxmox.com
À: aderumier aderum...@odiso.com
Cc: pve-devel pve-devel@pve.proxmox.com
Envoyé: Mercredi 29 Juillet 2015 10:33:51
Objet: Re: [pve-devel] Regression with latest qemu and iothreads option ?
On
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)
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
we need this for krbd volumes
Signed-off-by: Alexandre Derumier aderum...@odiso.com
---
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
---
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
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
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
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).
in
---
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 {
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
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 diet...@proxmox.com
À: aderumier
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 diet...@proxmox.com
À: aderumier aderum...@odiso.com
Cc: pve-devel pve-devel@pve.proxmox.com
Envoyé: Jeudi 30
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
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 between
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 diet...@proxmox.com
À: aderumier
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:
---
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
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
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 think we can't use this
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.rootfs =
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
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 really
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 ?
Honestly, the
42 matches
Mail list logo
