Re: [PVE-User] With cloud-init some bug?

2018-03-23 Thread lyt_yudi
> 在 2018年3月23日,下午6:39,Wolfgang Bumiller 写道: > 在 2018年3月23日,下午5:00,lyt_yudi > 写道: But, the cipassword for centos user is still not set! >>> >>> Sorry , my fault! The cipassword can set! It’s work

Re: [PVE-User] With cloud-init some bug?

2018-03-23 Thread lyt_yudi
> 在 2018年3月23日,下午3:21,Wolfgang Bumiller 写道: > > On Fri, Mar 23, 2018 at 02:28:12PM +0800, lyt_yudi wrote: >> 1. Use --sshkey issue: >> # qm set 111 --sshkey ~/.ssh/id_rsa.pub >> 400 Parameter verification failed. >> sshkeys: invalid format - invalid urlencoded string:

[PVE-User] With cloud-init some bug?

2018-03-23 Thread lyt_yudi
1. Use --sshkey issue: # qm set 111 --sshkey ~/.ssh/id_rsa.pub 400 Parameter verification failed. sshkeys: invalid format - invalid urlencoded string: /root/.ssh/id_rsa.pub qm set 111 --sshkey /root/.ssh/id_rsa.pub [OPTIONS] 2. Can't setup static ip address for vm's by cloud-init Test not

Re: [PVE-User] With cloud-init some bug?

2018-03-23 Thread Wolfgang Bumiller
On Fri, Mar 23, 2018 at 02:28:12PM +0800, lyt_yudi wrote: > 1. Use --sshkey issue: > # qm set 111 --sshkey ~/.ssh/id_rsa.pub > 400 Parameter verification failed. > sshkeys: invalid format - invalid urlencoded string: /root/.ssh/id_rsa.pub > > qm set 111 --sshkey /root/.ssh/id_rsa.pub [OPTIONS]

Re: [PVE-User] With cloud-init some bug?

2018-03-23 Thread lyt_yudi
Hi, > 在 2018年3月23日,下午4:36,lyt_yudi 写道: > >>> >>> must be with cloudinit >= 17.1? >> >> 0.7.9 from debian stretch should also work, older ones _may_ work with >> the configdrive2 type. I haven't tested older versions lately, but given >> that configdrive2 was the first

Re: [PVE-User] With cloud-init some bug?

2018-03-23 Thread Wolfgang Bumiller
On Fri, Mar 23, 2018 at 11:07:01AM +0100, Wolfgang Bumiller wrote: > On Fri, Mar 23, 2018 at 05:51:17PM +0800, lyt_yudi wrote: > > > > > > > 在 2018年3月23日,下午5:00,lyt_yudi 写道: > > > > > > But, the cipassword for centos user is still not set! > > > > Sorry , my fault! The

Re: [PVE-User] With cloud-init some bug?

2018-03-23 Thread lyt_yudi
> 在 2018年3月23日,下午3:21,Wolfgang Bumiller 写道: > > 0.7.9 from debian stretch should also work Debian 9, it’s work with cloud-init 0.7.9 It’s need to be modify interfaces conf: root@debian9-01:~# cat /etc/network/interfaces # This file describes the network interfaces

Re: [PVE-User] With cloud-init some bug?

2018-03-23 Thread Wolfgang Bumiller
On Fri, Mar 23, 2018 at 05:51:17PM +0800, lyt_yudi wrote: > > > > 在 2018年3月23日,下午5:00,lyt_yudi 写道: > > > > But, the cipassword for centos user is still not set! > > Sorry , my fault! The cipassword can set! It’s work with cloud-init-18.1! I just tried a fresh centos 7

Re: [PVE-User] With cloud-init some bug?

2018-03-23 Thread lyt_yudi
> 在 2018年3月23日,下午5:00,lyt_yudi 写道: > > But, the cipassword for centos user is still not set! Sorry , my fault! The cipassword can set! It’s work with cloud-init-18.1! Thanks ___ pve-user mailing list pve-user@pve.proxmox.com

Re: [PVE-User] 4.15 based test kernel for PVE 5.x available

2018-03-23 Thread Fabian Grünbichler
On Thu, Mar 22, 2018 at 05:32:23PM +0100, Colin 't Hart wrote: > Hi, > > The 4.15 kernel seems to work fine for me. I'm also installing > proposed updates from the Debian repository. The 4.13 kernel was > broken with the newer version of apparmor, but the 4.15 works with it > so I'm happy.

[PVE-User] Firewall settings for migration type insecure

2018-03-23 Thread Uwe Sauter
Hi there, I wanted to test "migration: type=insecure" in /etc/pve/datacenter.cfg but migrations fail with this setting. # log of failed insecure migration # 2018-03-23 14:58:44 starting migration of VM 101 to node 'px-bravo-cluster' (169.254.42.49) 2018-03-23 14:58:44 copying disk

Re: [PVE-User] pve-zsync processes

2018-03-23 Thread Thomas Lamprecht
On 3/21/18 1:51 PM, Wolfgang Link wrote: > >> So does this mean that all those processes are sitting in a "queue" waiting >> to execute? wouldn't it be more sensible for the script to terminate if a >> process is already running for the same job? >> > No because as I wrote 15 is default, but we

Re: [PVE-User] Firewall settings for migration type insecure

2018-03-23 Thread Thomas Lamprecht
Hi Uwe! On 3/23/18 3:02 PM, Uwe Sauter wrote: > Hi there, > > I wanted to test "migration: type=insecure" in /etc/pve/datacenter.cfg but > migrations fail with this setting. > > # log of failed insecure migration # > 2018-03-23 14:58:44 starting migration of VM 101 to node

Re: [PVE-User] Firewall settings for migration type insecure

2018-03-23 Thread Uwe Sauter
Thanks, I'll try again. Am 23.03.2018 um 15:15 schrieb Thomas Lamprecht: > Hi Uwe! > > On 3/23/18 3:02 PM, Uwe Sauter wrote: >> Hi there, >> >> I wanted to test "migration: type=insecure" in /etc/pve/datacenter.cfg but >> migrations fail with this setting. >> >> # log of failed insecure

Re: [PVE-User] Firewall settings for migration type insecure

2018-03-23 Thread Thomas Lamprecht
Uwe, On 3/23/18 3:31 PM, Uwe Sauter wrote: > a quick follow-up: is it possible to create PVE firewall rules for port > ranges? It seems that only a single port is allowed per > rule. If I enter "6-60050" it displays: > > Parameter verification failed. (400) > > sport: invalid format -

Re: [PVE-User] Firewall settings for migration type insecure

2018-03-23 Thread Uwe Sauter
Ah, syntax. Thanks again. Have a nice weekend. Am 23.03.2018 um 15:35 schrieb Thomas Lamprecht: > Uwe, > > On 3/23/18 3:31 PM, Uwe Sauter wrote: >> a quick follow-up: is it possible to create PVE firewall rules for port >> ranges? It seems that only a single port is allowed per >> rule. If I

Re: [PVE-User] Firewall settings for migration type insecure

2018-03-23 Thread Uwe Sauter
Thomas, a quick follow-up: is it possible to create PVE firewall rules for port ranges? It seems that only a single port is allowed per rule. If I enter "6-60050" it displays: Parameter verification failed. (400) sport: invalid format - invalid port '6-60050' dport: invalid format -

Re: [PVE-User] pmbalance

2018-03-23 Thread Alexandre DERUMIER
Thanks for your script, I was looking for something like that. I'll try it next week and try to debug. I'm seeing 2 improvements: - check that shared storage is available on target node - take ksm value in memory count. (with ksm enable, we can have all nodes at 80% memory usage, but with