>On 03/10/2017 08:51 AM, Gandalf Corvotempesta wrote:
>> Il 10 mar 2017 8:05 AM, "Thomas Lamprecht" ha
>> scritto:
>>
>> Hi,
>> Migration between nodes in the same cluster with no shared storage
can be
>> already achieved,
>>
>> Directly migrating in via WebUI is not yet exposed, AFAIK, but on
Il 10 mar 2017 8:05 AM, "Thomas Lamprecht" ha
scritto:
Hi,
Migration between nodes in the same cluster with no shared storage can be
already achieved,
Directly migrating in via WebUI is not yet exposed, AFAIK, but on the CLI
you may try to use
qm migrate -oneline -with-local-disks
-oneline
On 03/10/2017 06:35 AM, Alexandre DERUMIER wrote:
> Hi,
>
>> First, thanks for your work!
>
> And thanks for your review ! :)
>
>
>> I did some shallow review of most patches, I hope most of it is somewhat
>> constructive (I had to include a few nit picks, sorry :))
>
> I'll try to take time to re
>>we have https://git.proxmox.com/?p=pve-apiclient.git ;)
Oh great. I didn't known about this.
>>there were/are plans of moving the cluster join operation to connect
>>over the API (and let the user verify the TLS certificate fingerprint to
>>create the initial trusted link) instead of the cu
On Fri, Mar 10, 2017 at 06:35:23AM +0100, Alexandre DERUMIER wrote:
> Hi,
>
> >>First, thanks for your work!
>
> And thanks for your review ! :)
>
>
> >>I did some shallow review of most patches, I hope most of it is somewhat
> >>constructive (I had to include a few nit picks, sorry :))
>
>
Migration between nodes in the same cluster with no shared storage can
be already achieved,
Directly migrating in via WebUI is not yet exposed, AFAIK, but on the
CLI you may try to use
qm migrate -oneline -with-local-disks
ugh, typo: s/oneline/online/
# qm migrate -online -with-lo
Hi,
On 03/09/2017 07:49 PM, Gandalf Corvotempesta wrote:
Sorry for the noise but is this something we will see before 5.0?
This exactly patch set probably not, no.
I'm really interested in all regarding live migration without shared
storage
You can do this now already? This patchset is for
Hi,
>>First, thanks for your work!
And thanks for your review ! :)
>>I did some shallow review of most patches, I hope most of it is somewhat
>>constructive (I had to include a few nit picks, sorry :))
I'll try to take time to reply for each patch comments.
>>Some general methods like doi
fixed the intend in fuse fuse_operations as well
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/data/s
Hello Thomas,
Am 09.03.2017 um 18:09 schrieb Thomas Lamprecht:
> On 03/09/2017 05:26 PM, Stefan Priebe wrote:
>> This allows us to use management software for files inside of /etc/pve.
>> f.e. saltstack which rely on being able to set uid,gid and chmod
>>
>> Signed-off-by: Stefan Priebe
>> ---
>
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/data/s
Sorry for the noise but is this something we will see before 5.0?
I'm really interested in all regarding live migration without shared
storage
and as I'm planning a new server with 4.4, I would like to know if this is
something I'll see in the near term without a major upgrade
Il 22 feb 2017 2:33
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
Hi,
This patches serie implement a new method
qm migrateexternal -targetstorage
to allow to live migrate+storage migrate a vm to a remote proxmox cluster,
with a new vmid on the target cluster.
Main differences with classic live storage mig
On 03/09/2017 05:26 PM, Stefan Priebe wrote:
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 41 -
1 file ch
Ok, that makes sense.
> Am 09.03.2017 um 17:35 schrieb Dietmar Maurer:
> > To clarify things: this does not allow to change anything? It just allows
> > chown class which would result in no change at all?
>
> Sorry yes. But this returns success if a programm wants to chown or
> chmod to the value
> On March 9, 2017 at 5:35 PM Dietmar Maurer wrote:
>
>
> To clarify things: this does not allow to change anything? It just allows
> chown class which would result in no change at all?
s/class/calls/
___
pve-devel mailing list
pve-devel@pve.proxmox.
Am 09.03.2017 um 17:35 schrieb Dietmar Maurer:
> To clarify things: this does not allow to change anything? It just allows
> chown class which would result in no change at all?
Sorry yes. But this returns success if a programm wants to chown or
chmod to the values pve-cluster already has / support
To clarify things: this does not allow to change anything? It just allows
chown class which would result in no change at all?
> On March 9, 2017 at 5:26 PM Stefan Priebe wrote:
>
>
> This allows us to use management software for files inside of /etc/pve.
> f.e. saltstack which rely on being abl
This and the previous patch should get squashed together.
If a variable gets renamed or replaced it should be done all at once,
at least if it does not changes the logic of code.
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm | 2 +-
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git
Same intendas:
[PATCH 12/19] phase3 : don't destroy local copy
AFAIS, so it could be done in one patch, reducing the total patch count
a bit.
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm | 22 +-
1 file cha
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm | 6 ++
1 file changed, 6 insertions(+)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 35b752e..6c238b7 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -1043
The patch semantics are OK, imo.
But I'm not sure if the default behavior should be the one where we let
the source VM fully intact,
I'm mean a (wrongful) start could result in conflicts like duplicate IP
addresses or similar.
I would think that at leas an option to delete the source VM, on
s
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm | 19 +++
1 file changed, 19 insertions(+)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 1ca445d..13952cb 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigr
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 616632c..b711564 100644
--- a/PVE/QemuMi
On Thu, Mar 09, 2017 at 02:54:28PM +0100, Wolfgang Bumiller wrote:
> otherwise it'll leak cgroup directories...
>
> Note that we need to escape the lxc@.service context (by
> entering a new scope) as well as close our ties to the lxc
> monitor (the stdout pipe), otherwise this never finishes
> pro
otherwise it'll leak cgroup directories...
Note that we need to escape the lxc@.service context (by
entering a new scope) as well as close our ties to the lxc
monitor (the stdout pipe), otherwise this never finishes
properly.
---
src/lxc-pve-poststop-hook | 35 +--
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm | 10 ++
1 file changed, 10 insertions(+)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index a2fa17a..616632c 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm | 15 +++
1 file changed, 15 insertions(+)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 71af817..a2fa17a 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.
On 02/22/2017 02:33 PM, Alexandre Derumier wrote:
need to implement a method to check that remotly. that later in ssh tunnel ?
A possibility would be getting the remote storages over the API, i.e.:
/storage/
In fact, almost all should be done over the API, and if not we should
try to enhance
Signed-off-by: Fabian Grünbichler
---
changelog.Debian | 6 ++
Makefile | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/changelog.Debian b/changelog.Debian
index dcde72a..15b89de 100644
--- a/changelog.Debian
+++ b/changelog.Debian
@@ -1,3 +1,9 @@
+pve-kernel (4.
Signed-off-by: Fabian Grünbichler
---
Makefile | 2 +
...001-TTY-n_hdlc-fix-lockdep-false-positive.patch | 111 +++
...02-tty-n_hdlc-get-rid-of-racy-n_hdlc.tbuf.patch | 319 +
3 files changed, 432 insertions(+)
create mode 10064
Fabian Grünbichler (3):
fix CVE-2017-2636: local privilege escalation in n_hdlc
bump version to 4.4.44-84
update make upload target
changelog.Debian | 6 +
Makefile | 6 +-
...001-TTY-n_hdlc-fix-lockdep-false-po
Signed-off-by: Fabian Grünbichler
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index bfd2048..e397fd2 100644
--- a/Makefile
+++ b/Makefile
@@ -456,7 +456,7 @@ ${FW_DEB} fw: control.firmware linux-firmware.git/WHENCE
dvb-firmware.git/README
The order of this patch is a bit strange to me, at this point the patch
cannot work, it needs the other one later in this series, or am I mistaken?
I'd try to introduce this only at the point where it can (minimally) work
with the previous patches.
some other small comments inline, but looks ok i
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
having our ceph.service pulled in by ceph.target does not
work anymore, because "systemctl start ceph.target" hangs
forever on ceph-common upgrades. multi-user.target seems to
work as well, and we are ordered after pve-cluster anyway.
only replace the old ceph.service if it is an exact match.
Sig
I don't really think someone uses non-utf8 locales on the host ...
So I will not apply this for now.
> On February 28, 2017 at 12:06 PM Dominik Csapak wrote:
>
>
> to explicitely use utf8 mode in the terminals via SPICE/VNC
> even when the host locale is not set to xx_XX.UTF-8
>
> this should
Hi,
I'm appreciating your effort on this topic, I try to give the patches an
initial look.
This patch as done is problematic and its title a bit misleading, you do not
make the VMID optional in qm only but in the API, that's a difference, while
it can be OK in qm it isn't in the API.
I know that
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
44 matches
Mail list logo
