Add more configurable settings for VMs #167

Open
opened 2023-11-08 12:30:32 -05:00 by joshuaboniface · 3 comments

virsh has a few tunables that can be turned into additional metainformation about the VM. Some choice examples include:

  • migrate --auto-converge: Adjust autoconverge settings during the migration, might be useful to investigate in detail and tune.

  • migrate --compressed: Adjust compression settings during migration, might be useful to investigate in detail and tune.

  • migrate-[get|set]maxdowntime: Adjust the maximum amount of downtime (in ms) for the final pause of the VM during a migration. Default is 300ms.

  • migrate-[get|set]speed: Adust the maximum speed of the migration copies. The default and the units specified don't make a whole lot of sense (it says the unit is MiB but the value is 8796093022207 or about 8 EiB which can't be right).

  • migrate-compcache: Adjust the compression cache size. Default is 64 MiB.

  • schedinfo: Shows or tunes scheduler info. Could be useful to tune.

Some things I noticed during this infodump that might also be useful:

  • blkdeviotune: Tune block I/O settings (limit IOPS, etc.). Needs more reading.

  • numatune: Tune NUMA settings. Needs more reading.

  • ttyconsole: Shows the raw /dev/tty device for the domain console. Could help with remote console support perhaps?

  • domblkstat: Shows block device stats for the VM. Could provide more info.

  • dommemstat: Shows memory stats for the VM. Could provide more info.

  • domstats: Show all stats ("balloon" = "mem") for the VM. Could provide mode info. Do I use this already?

  • domjobinfo: Show information on migration jobs. Might be very useful to observe with the migrate command to provide progress updates during live migrations. "--completed" shows finished job stats for the final update.

  • domdisplay: Show the URI of the VNC/Spice/RDP console of the VM.

  • domfsinfo: Shows the (real) mapping of volumes in the guest. Could be very useful in VM information showing.

  • reset: To reboot what destroy is to shutdown. Might be worth implementing if reboot commands time out.

  • screenshot: Takes a screenshot of the console. Might be worth implementing.

  • send-key: Sends a keypress to the domain. Might be worth implementing.

`virsh` has a few tunables that can be turned into additional metainformation about the VM. Some choice examples include: * `migrate --auto-converge`: Adjust autoconverge settings during the migration, might be useful to investigate in detail and tune. * `migrate --compressed`: Adjust compression settings during migration, might be useful to investigate in detail and tune. * `migrate-[get|set]maxdowntime`: Adjust the maximum amount of downtime (in ms) for the final pause of the VM during a migration. Default is 300ms. * `migrate-[get|set]speed`: Adust the maximum speed of the migration copies. The default and the units specified don't make a whole lot of sense (it says the unit is `MiB` but the value is `8796093022207` or about 8 EiB which can't be right). * `migrate-compcache`: Adjust the compression cache size. Default is 64 MiB. * `schedinfo`: Shows or tunes scheduler info. Could be useful to tune. Some things I noticed during this infodump that might also be useful: * `blkdeviotune`: Tune block I/O settings (limit IOPS, etc.). Needs more reading. * `numatune`: Tune NUMA settings. Needs more reading. * `ttyconsole`: Shows the raw `/dev/tty` device for the domain console. Could help with remote console support perhaps? * `domblkstat`: Shows block device stats for the VM. Could provide more info. * `dommemstat`: Shows memory stats for the VM. Could provide more info. * `domstats`: Show all stats ("balloon" = "mem") for the VM. Could provide mode info. Do I use this already? * `domjobinfo`: Show information on migration jobs. Might be very useful to observe with the migrate command to provide progress updates during live migrations. "--completed" shows finished job stats for the final update. * `domdisplay`: Show the URI of the VNC/Spice/RDP console of the VM. * `domfsinfo`: Shows the (real) mapping of volumes in the guest. Could be very useful in VM information showing. * `reset`: To `reboot` what `destroy` is to `shutdown`. Might be worth implementing if `reboot` commands time out. * `screenshot`: Takes a screenshot of the console. Might be worth implementing. * `send-key`: Sends a keypress to the domain. Might be worth implementing.
joshuaboniface added this to the 1.0 milestone 2023-11-17 01:37:16 -05:00
Author
Owner

Included in 1.0 milestone as some of these have good potential but more R&D is required.

Included in 1.0 milestone as some of these have good potential but more R&D is required.
joshuaboniface added the
API
Daemon
feature
labels 2023-11-17 01:50:31 -05:00
Author
Owner

migrate-setmaxdowntime has become a priority as I've seen more and more VMs in the wild where this has to be tuned.

This also makes me think of doing some enhancements around VM migrations to better capture what's going on with them. While the current process works, it can also be error prone and leave VMs in weird states if it fails. The opportunity to use domjobinfo to get live stats about the migration is also compelling, as would a command to view these stats during the migration.

`migrate-setmaxdowntime` has become a priority as I've seen more and more VMs in the wild where this has to be tuned. This also makes me think of doing some enhancements around VM migrations to better capture what's going on with them. While the current process works, it can also be error prone and leave VMs in weird states if it fails. The opportunity to use `domjobinfo` to get live stats about the migration is also compelling, as would a command to *view* these stats during the migration.
Author
Owner

Decoupling the last two update items, I think implementing maxdowntime as a new meta field and then simply calling the relevant command on VM start/receive is best, as that can be done fairly easily. Enhancing VM migrations is a much bigger job, including ideally a move of those into the workers, so that can wait as a separate task.

Decoupling the last two update items, I think implementing `maxdowntime` as a new meta field and then simply calling the relevant command on VM start/receive is best, as that can be done fairly easily. Enhancing VM migrations is a much bigger job, including ideally a move of those into the workers, so that can wait as a separate task.
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: parallelvirtualcluster/pvc#167
No description provided.