Update from 4.0.7 to .10 - pct list function is broken

M

mr.x

Well-Known Member
Feb 16, 2010
49
0
46
Hi all,

I think we found a bug while running the update from .7 to .10.
Right now we are on this versions.

Code: 
 pveversion -vproxmox-ve: 4.0-10 (running kernel: 4.1.3-1-pve)
pve-manager: 4.0-36 (running version: 4.0-36/9815097f)
pve-kernel-4.1.3-1-pve: 4.1.3-7
pve-kernel-4.2.0-1-pve: 4.2.0-10
lvm2: 2.02.116-pve1
corosync-pve: 2.3.4-2
libqb0: 0.17.1-3
pve-cluster: 4.0-17
qemu-server: 4.0-23
pve-firmware: 1.1-7
libpve-common-perl: 4.0-20
libpve-access-control: 4.0-8
libpve-storage-perl: 4.0-21
pve-libspice-server1: 0.12.5-1
vncterm: 1.2-1
pve-qemu-kvm: 2.4-5
pve-container: 0.9-18
pve-firewall: 2.0-11
pve-ha-manager: 1.0-5
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u1
lxc-pve: 1.1.3-1
lxcfs: 0.9-pve2
cgmanager: 0.37-pve2
criu: 1.6.0-1

Before we had:
Code: 
root@server:~# pct listVMID       Status     Name
181        running    181.domain.com
190        running    190.domain.com
205        running    205.domain.com

After the update:
Code: 
root@server:~# pct listVMID       Status     Name
181        running    181.domain.com
205        running    205.domain.com

VM 190 is missing !

Root cause is located in the new config handling. Before we had the config file inside the <VM-ID>-folder. After the update the found a <VM-ID>.conf within the lxc folder.
Moving the config to <VM-ID>.conf helped a bit but still parsing errors visible.

Code: 
root@s100:/etc/pve/lxc# pct list
vm 190 - unable to parse config: pve.disksize = 50
vm 190 - unable to parse config: pve.onboot = 1
vm 190 - unable to parse config: pve.volid = local:190/vm-190-rootfs.raw
vm 190 - unable to parse config: pve.network.bridge = vmbr0
vm 190 - unable to parse config: pve.network.gw = a.b.c.d
vm 190 - unable to parse config: pve.network.ip = a.b.c.d/28
vm 190 - unable to parse config: lxc.network.veth.pair = veth190.0
VMID       Status     Name
181        running    181.domain.com
190        stopped    CT190
205        running    205.domain.com

Is this the expected behavior?

Br
Mr.X
 
Yes somewhat, we changed the config format and location so that it shares some more behavior to the VM configs.

After the upgrade a script should have parsed the old configs to the new ones.
All custom config entries cannot be parsed automatically.

In your case the CTs 181 and 205 were parsed successfully and 190 caused some problems, I guess. Look at the upgrade logs if there is some output.
No data is lost and if you adapt the config manually so it matches the new format (see other cfgs as guideline) everything should work like before.

Sorry for the inconvenience, as it's a beta some stuff may break sometimes but we tried to make the upgrade as smooth as possible.
 
Hi Thomas,

thanks for your fast reply !

t.lamprecht said:
Yes somewhat, we changed the config format and location so that it shares some more behavior to the VM configs.
Click to expand...

Nothing was written in the read.me or changelog. Would have been nice .-) Anyhow, we found the issue.

After the upgrade a script should have parsed the old configs to the new ones.
All custom config entries cannot be parsed automatically.

In your case the CTs 181 and 205 were parsed successfully and 190 caused some problems, I guess. Look at the upgrade logs if there is some output.
No data is lost and if you adapt the config manually so it matches the new format (see other cfgs as guideline) everything should work like before.
Click to expand...

I found this in the Logs

Code: 
converting /etc/pve/lxc/181/config to /etc/pve/lxc/181.conf
converting /etc/pve/lxc/190/config to /etc/pve/lxc/190.conf 
failed to create required config key 'ostype' at /usr/sbin/pve-update-lxc-config line 586.
converting /etc/pve/lxc/205/config to /etc/pve/lxc/205.conf

Maybe it helps a bit.

Sorry for the inconvenience, as it's a beta some stuff may break sometimes but we tried to make the upgrade as smooth as possible.
Click to expand...

No problem at all. Just for all the other proxmox users !
Great software ! Keep going.

Br
Mr.X
 
mr.x said:
Hi Thomas,

I found this in the Logs

Code: 
converting /etc/pve/lxc/181/config to /etc/pve/lxc/181.conf
converting /etc/pve/lxc/190/config to /etc/pve/lxc/190.conf 
failed to create required config key 'ostype' at /usr/sbin/pve-update-lxc-config line 586.
converting /etc/pve/lxc/205/config to /etc/pve/lxc/205.conf
Click to expand...

Ok that explains why the conversion of this type failed, we need to know the ostype of the container as every OS needs some different startup/configuration processes.
For the specific config the script was unable to detect the 'ostype' parameter (it wasn't plainly written in the old config format, so not that easy to extract) and failed.

Out of interest, what OS was the failed container?

The good thing: the config format is now stable and doesn't need such an big change anymore, so it won't happen again.
And if someone start with PVE4 beta2 he already has the new format and so no problems, at least with this. :)

Thanks for noticing this here, it could really help other beta users.
Most of the time the conversion should be successful.
 
Hi Thomas,

t.lamprecht said:
Ok that explains why the conversion of this type failed, we need to know the ostype of the container as every OS needs some different startup/configuration processes.
For the specific config the script was unable to detect the 'ostype' parameter (it wasn't plainly written in the old config format, so not that easy to extract) and failed.

Out of interest, what OS was the failed container?
Click to expand...

Here we go:

old openvz config

Code: 
server:/etc/pve/openvz# cat 190.conf# PVE default config for 256MB RAM


ONBOOT="yes"


# Primary parameters
NUMPROC="1024:1024"
NUMTCPSOCK="9223372036854775807:9223372036854775807"
NUMOTHERSOCK="9223372036854775807:9223372036854775807"
VMGUARPAGES="0:unlimited"


# Secondary parameters
KMEMSIZE="1951399936:2147483648"
OOMGUARPAGES="0:unlimited"
PRIVVMPAGES="unlimited"
TCPSNDBUF="9223372036854775807:9223372036854775807"
TCPRCVBUF="9223372036854775807:9223372036854775807"
OTHERSOCKBUF="9223372036854775807:9223372036854775807"
DGRAMRCVBUF="9223372036854775807:9223372036854775807"


# Auxiliary parameters
NUMFILE="9223372036854775807:9223372036854775807"
NUMFLOCK="9223372036854775807:9223372036854775807"
NUMPTY="255:255"
NUMSIGINFO="1024:1024"
DCACHESIZE="975175680:1073741824"
LOCKEDPAGES="524288:524288"
SHMPAGES="9223372036854775807:9223372036854775807"
NUMIPTENT="9223372036854775807:9223372036854775807"
PHYSPAGES="0:1048576"


# Disk quota parameters
DISKSPACE="52428800:57671680"
DISKINODES="10000000:11000000"
QUOTATIME="0"
QUOTAUGIDLIMIT="0"


# CPU fair sheduler parameter
CPUUNITS="1000"
CPUS="4"
VE_ROOT="/var/lib/vz/root/$VEID"
VE_PRIVATE="/var/lib/vz/private/$VEID"
OSTEMPLATE="ubuntu-9.04-standard_9.04-3_i386"
ORIGIN_SAMPLE="pve.auto"
IP_ADDRESS="a.b.c.d"
HOSTNAME="domain.com"


SEARCHDOMAIN="domain.com"
FEATURES="nfs:on "
SWAPPAGES="0"

and the converted version
Code: 
lxc.arch = amd64lxc.cgroup.cpu.cfs_period_us = 100000
lxc.cgroup.cpu.cfs_quota_us = 400000
lxc.cgroup.cpu.shares = 1024
lxc.cgroup.memory.limit_in_bytes = 4294967296
lxc.cgroup.memory.memsw.limit_in_bytes = 4294967296
lxc.rootfs = loop:/var/lib/vz/images/190/vm-190-rootfs.raw
lxc.utsname = domain.com
pve.disksize = 50
pve.onboot = 1
pve.volid = local:190/vm-190-rootfs.raw
lxc.network.type = veth
pve.network.bridge = vmbr0
pve.network.gw = a.b.c.d
lxc.network.hwaddr = 76:11:22:B1:BC:0B
pve.network.ip = a.b.c.d/28
lxc.network.name = eth0
lxc.network.veth.pair = veth190.0
lxc.mount.auto = proc sys cgroup

The good thing: the config format is now stable and doesn't need such an big change anymore, so it won't happen again.
And if someone start with PVE4 beta2 he already has the new format and so no problems, at least with this. :)
Click to expand...
Good to know for all others !

Thanks for noticing this here, it could really help other beta users.
Most of the time the conversion should be successful.
Click to expand...

Yes

BR
Mr.X
 
You OpenVZ config contains

OSTEMPLATE="ubuntu-9.04-standard_9.04-3_i386"

This is simply too old and already in unsupported state (no more updates available).
We currently support Ubuntu version 12.04, 14.04 and 15.04.
 
Hi Dietmar,

dietmar said:
You OpenVZ config contains

OSTEMPLATE="ubuntu-9.04-standard_9.04-3_i386"

This is simply too old and already in unsupported state (no more updates available).
We currently support Ubuntu version 12.04, 14.04 and 15.04.
Click to expand...

Yes, this is one of our oldest VMs .-)

Br
Mr.X
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back