Search results

Since I had no replication running, it was enough to killall pvescheduler until no pvescheduler was running anymore, Then service pvescheduler start. And at least migrate and remograte the VMs, that the new libpbs was used. A reboot was not needed in my case.

Ok .... I removed the openvswitch stuff from one node and tried it again. Unfortunately this doesn't solve the problem. To be more precise: If I move a windows server from an old node to an old node and back, it works. If I move a windows server from an old node to a new node it works. But if...

Some new tests: The migration to cpu11 was working. The problem starts when migrating back to cpu02. The difference: cpu02 uses openvswitch, while cpu11 didn't. It looks like that the migration from a node without openvswitch to a node with openvswitch results in this behaviour. The interfaces...

Always when we migrate Windows Servers they stuck with an error screen. After a reboot they work normal again. Today I migrated some VMs to an other node and back to update the pbs library which is used by the VMs. All 4 VMs needed a restart afterwards. It was a DomainController, 2...

On friday I created a sync job to copy files from PBS-02 to PBS-01 PBS-02 has different datastores and PBS-01 uses the 'new' namespace feature. Both PBS are running the latest no-subscription version 2.2.5 Updated 29.07.2022 and both rebootet, On PBS-01 (target) I get...

You are lucky, I found a node where it still is the case: root@pm-cpu-173:~# ps ax|grep pvesche 390618 ? Ss 61:21 pvescheduler 1271153 ? Ss 29:05 pvescheduler 2016484 ? Ss 50:23 pvescheduler 2711818 ? Ss 6:58 pvescheduler 3602118 ? Ss 43:26...

It's working now as expected. kill -9 xxxx was not needed. killall pvescheduler terminates all processes. I found more pve nodes where multiple instances of pvescheduler was 'running'. How can this happen? And why does a start of pvescheduler does not simply terminate all old running...

stop does nearly nothing: root@pm-cpu-175:~# systemctl stop pvescheduler root@pm-cpu-175:~# ps ax|grep pvesched 126214 ? Ss 4:56 pvescheduler 1723109 ? Ss 32:41 pvescheduler 1875725 ? Ss 33:47 pvescheduler 2224202 ? S 0:00 pvescheduler 2224204 pts/0...

There is no tree, only single processes: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 1 0 2916892 1 20 0 333232 19788 hrtime Ss ? 39:05 pvescheduler 4 0 608389 1 20 0 15504 5396 do_epo Ss ? 0:02...

journalctl (from the day where I restarted the pvescheduler): Jul 21 18:04:31 pm-cpu-175 systemd[1]: Stopping Proxmox VE scheduler... Jul 21 18:04:32 pm-cpu-175 pvescheduler[3508258]: received signal TERM Jul 21 18:04:32 pm-cpu-175 pvescheduler[3508258]: got shutdown request, signal running jobs...

I did this systemctl restart pvescheduler on friday. Still the same message in the log of the backup job: file /etc/pve/storage.cfg line 158 (section 'pm-pbs01-ednt') - unable to parse value of 'namespace': unexpected property 'namespace'

As written in #18, I did a systemctl reload-or-restart pveproxy pvedaemon pvescheduler It's getting worse. Now a few VMs more (also from other nodes) are not respect the namespace (which were Ok last times): And I can still see: file /etc/pve/storage.cfg line 158 (section 'pm-pbs01-ednt') -...

The backups are running via the backup-job, because I'm not in the company at 11pm. I just checked PBSPlugin.pm on this node. in sub options { is definately namespace => { optional => 1 }, inside.

Hi, still the same problem, but ... I saw a new error message in the backup log: file /etc/pve/storage.cfg line 158 (section 'pm-pbs01-ednt') - unable to parse value of 'namespace': unexpected property 'namespace' But I swear, the node has no missing updates. So I try now the restart of the...

No, on this PBS are only stored VMs and CTs from one cluster. But I want 2 namespaces since the VMs and CTs are owned by 2 different customers. So there is no chance to have double IDs. This PBS is synced to a second PBS, but as slave. The other PBS syncs from this one.

In the backup log of this node I see only the 'right' backup from 2022-07-19 00:09:13: INFO: trying to get global lock - waiting... INFO: got global lock INFO: starting new backup job: vzdump 118 246 140 141 199 128 145 181 1241 185 186 100 107 225 227 231 228 233 238 234 236 237 201 240 254 275...

That is the great mystery, I only migrated the VMs from the one node away and back. I did nothing with VMs on other nodes.

More ups ... Some VMs of this node were backuped twice this night. For example vm/114: stored in root at 2022-07-18 23:00:12 (count 5) stored in ednt at 2022-07-19 00:09:13 (count 1) But as you can see in the first post, there is only one backup job where this VM is included.

Hi, partly success. But ... still some VMs and all CTs are not stored in the namespace. All with count 5 are still wrong. Here is the status of vm/114 proxmox-support: pbs-dirty-bitmap: 1 pbs-dirty-bitmap-migration: 1 pbs-dirty-bitmap-savevm: 1...

I did now an online migration with the VMs. They report now 1.31 as pbs-library. But what's with the CTs ? Do they also need a 'restart' ?