Hi Jiri,
Sorry about the late response, only now I managed to push iSER into QEMU.
Because ISER is registered as a different protocol than iSCSI with the prefix of iser:// I want to add support for it in libvirt.
Libvirt code is pretty new for me, wondered if adding VIR_STORAGE_NET_PROTOCOL_ISER as another virStorageNetProtocol should be enough?
Of course I added ISER in all necessary switch-case in code also.
Thanks,
Roy
On Tue, Mar 22, 2016 at 2:56 PM, Jiri Denemark <jdenemar@xxxxxxxxxx> wrote:
On Tue, Mar 22, 2016 at 14:21:52 +0200, Roy Shterman wrote:
> Correct me if I'm wrong but locked option is pinning all VM memory in host
> RAM,
>
> for example if I have a VM with 4G memory, and I want to run some QEMU code
> which needs to pin 500M,
>
> I will need to lock all 4G in host memory instead of locking only 500M.
So the question is which code wants to lock part of the memory, why, and
if it's something that can be influenced by user.
For example, we know that if you ask for all memory to by locked, we
need to set the limit. The same applies when RDMA migration is started.
On PPC we know some amount of memory will always need to be locked, we
compute the amount and set the limit accordingly. We can't really expect
user to have deep knowledge of QEMU and know what limit needs to be set
when they use a specific device, QMP command, or whatever. So if the
limit is something predictable and deterministic, we can automatically
compute the amount of memory and use it when starting QEMU. Forcing
users to set the limit when all memory needs to be locked is already bad
enough that I don't think we should add a new option to explicitly set
arbitrary lock limit.
Jirka
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list