V 6.4 Live Migration Limitations?

[iprigger]

All,

First of all: 6.4 looks really great. Will have to look into the 5.11 kernel and decide, wheter or not I want to try.

I noticed two things:
1st: Live Migration Speed is down to ~32MiB/s after installing the new Version. On Purpose or did I miss something (before I had 500+MiB)
2nd: Single File restore: Cool feature... but doesn't work on windows guests... correct? Will that come at a later time?

Thanks!

Tobias

 

[aaron]

1st: Live Migration Speed is down to ~32MiB/s after installing the new Version. On Purpose or did I miss something (before I had 500+MiB)

Nothing on purpose. Might be something else as well. Which version did you run before the upgrade?

2nd: Single File restore: Cool feature... but doesn't work on windows guests... correct? Will that come at a later time?

Should work if it is a normal Windows install with NTFS.

 

[tom]

2nd: Single File restore: Cool feature... but doesn't work on windows guests... correct? Will that come at a later time?

See https://www.proxmox.com/en/training/video-tutorials/item/what-s-new-in-proxmox-ve-6-4

 

[iprigger]

Hi Tom

See https://www.proxmox.com/en/training/video-tutorials/item/what-s-new-in-proxmox-ve-6-4

irgendwie übersehe ich da was...

- PBS Server? Check
- Linux VMs? Funktioniert
- Windows? Nope

und im Video wird da nicht wirklich was "ausgeschlossen"... oder bin ich taub?

Tobias

 

[iprigger]

Hi aaron,

Nothing on purpose. Might be something else as well. Which version did you run before the upgrade?

6.3-3 (latest & greatest that existed before)

Funny enough, the amd machines are WAY faster (150M)

Should work if it is a normal Windows install with NTFS.

Hmmm. in that case I have to check again.

Tobias

 

[iprigger]

Hi Aaron,

Nothing on purpose. Might be something else as well. Which version did you run before the upgrade?

Seems to be a thing when migrationg from 6.3-3-hosts to 6.4-hosts. After a reboot (when migrating the VMs back) everything is fine (albeit maybe a tiny little bit slower)

Tobias

 

[t.lamprecht]

Note that the migration log, and how the speed was determined, changed quite a bit to better reflect what actually is moved, while not spamming the migration log that much. So one would need to compare total task log duration between those versions, else it could be a bit like apples to oranges.

 

[iprigger]

Note that the migration log, and how the speed was determined, changed quite a bit to better reflect what actually is moved, while not spamming the migration log that much. So one would need to compare total task log duration between those versions, else it could be a bit like apples to oranges.

Ah... that might be something.

Tobias

 

[EPM]

Hi,
Before upgrade:
2021-04-29 08:39:58 migration speed: 1024.00 MB/s - downtime 88 ms
2021-04-29 08:39:58 migration status: completed
2021-04-29 08:40:01 migration finished successfully (duration 00:00:09)
After upgrade :
2021-04-29 08:43:21 average migration speed: 136.8 MiB/s - downtime 56 ms
2021-04-29 08:43:21 migration status: completed
2021-04-29 08:43:24 migration finished successfully (duration 00:00:35)

L,

 

[iprigger]

Hi,

Hi,
Before upgrade:
2021-04-29 08:39:58 migration speed: 1024.00 MB/s - downtime 88 ms
2021-04-29 08:39:58 migration status: completed
2021-04-29 08:40:01 migration finished successfully (duration 00:00:09)
After upgrade :
2021-04-29 08:43:21 average migration speed: 136.8 MiB/s - downtime 56 ms
2021-04-29 08:43:21 migration status: completed
2021-04-29 08:43:24 migration finished successfully (duration 00:00:35)

L,

That's about what I see as well...

Tobias

 

[t.lamprecht]

You're actually right, I found a small regression which implies a 128 MiB/s (== 1 Gbps) migration bandwidth limit if none is set, which one may not notice if explicitly testing on a 1 Gbps link to see how VM migrations works when the guest trashes lots of memory -.-
A package is available on pvetest (qemu-server version 6.4-2) alternatively one can set the migration bandwidth limit in Datacenter -> Options to a higher value as workaround.

 

[EPM]

I am set 1024 (Datacenter -> Options):
2021-04-29 16:48:58 migration active, transferred 1018.0 MiB of 4.0 GiB VM-state, 1.4 GiB/s
2021-04-29 16:48:59 migration active, transferred 2.0 GiB of 4.0 GiB VM-state, 1.0 GiB/s
2021-04-29 16:49:00 migration active, transferred 3.0 GiB of 4.0 GiB VM-state, 1.0 GiB/s
2021-04-29 16:49:01 average migration speed: 1.0 GiB/s - downtime 120 ms
2021-04-29 16:49:01 migration status: completed
2021-04-29 16:49:03 migration finished successfully (duration 00:00:09)

Thank you !!

 

[iprigger]

Hi Thomas,

You're actually right, I found a small regression which implies a 128 MiB/s (== 1 Gbps) migration bandwidth limit if none is set, which one may not notice if explicitly testing on a 1 Gbps link to see how VM migrations works when the guest trashes lots of memory -.-
A package is available on pvetest (qemu-server version 6.4-2) alternatively one can set the migration bandwidth limit in Datacenter -> Options to a higher value as workaround.

Thanks! I set it to 256 MiBs on my site - makes sense to somewhat limit the migration traffic a bit if you don't have a dedicated migration network (which I normally implement at customers but not in our infrastructure / lab. Not because we can't. But bcaus we lazy f*cks )