A new daemon will be added to the qemu-kvm package.

The daemon should in general have the same permissions as the lvm_t context.  Based on some experiments with setroubleshoot, this is what it found

  require {
   	type paolo_t;
	type fixed_disk_device_t;
	type var_run_t;
	type lvm_control_t;
	type sysctl_fs_t;
	type user_home_t;
	type udev_var_run_t;
	type lvm_var_run_t;
	class file { execute getattr open read };
	class chr_file { getattr ioctl open read write };
	class dir { add_name remove_name write };
	class sock_file { create unlink };
	class process setcap;
	class capability { setpcap sys_admin sys_rawio };
	class blk_file { getattr ioctl open read write };
  }

  allow paolo_t fixed_disk_device_t:blk_file { getattr ioctl open read write };
  allow paolo_t lvm_control_t:chr_file { getattr ioctl open read write };
  allow paolo_t lvm_t:unix_stream_socket connectto;
  allow paolo_t self:capability { setpcap sys_admin sys_rawio };
  allow paolo_t self:process setcap;
  allow paolo_t sysctl_fs_t:file { getattr open read };
  allow paolo_t udev_var_run_t:file { getattr open read };
  allow paolo_t lvm_var_run_t:sock_file unlink;
  allow paolo_t var_run_t:dir { add_name remove_name write };
  allow paolo_t var_run_t:sock_file create;

The lvm_var_run_t and var_run_t entries are due to the daemon's socket, which is
/var/run/qemu/qemu-pr-helper.sock.

Any qemu_t should be able to connect to this socket, because all operations that the daemon does are on file descriptors that QEMU already has. If that's not possible, it's okay to hide it behind a boolean that RHV can enable.