qmp response could me more than 1 json.
we can have 1 json with event info, and 1 json with return infos.
We die if we receive an error message in response.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
for the moment we check only if the real path exist on the host.
This doesn't work for "virtual" device that host doesn't see.(like rbd, virtio-scsi,...).
This add a check if the volid exist in the storage.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
this add qmp socket to kvm process
and anew sub copied from vm_monitor_command:
vm_qmp_command ($vmid, $cmdstr, $nocheck)
$cmdstr could be a simple command to be executed, without argument
vm_qmp_command($vmid,"stop");
or a complex hash with arguments
$cmdstr->{execute}="eject";
$cmdstr->{arguments}->{device}="ide1-cd0";
vm_qmp_command($vmid,$cmdstr);
documentation about qmp commands is here
http://git.qemu.org/?p=qemu.git;a=blob;f=qmp-commands.hx;h=db980fa811325aeca8ad43472ba468702d4a25a2;hb=HEAD
Code must be polish a little more, but it's a start.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
replace the warn by a die.
Currently, if we vdisk_free a disk and something goes wrong (network
storage problem by example), the drive is removed from config and we
cannot retry to remove it later.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This add disk io limit to drive options.
I also add the qemu monitor command, but I din't have added yet to Qemu.pm
>From qemu mailing:
Some available features follow as below:
(1) global bps limit.
-drive bps=xxx in bytes/s
(2) only read bps limit
-drive bps_rd=xxx in bytes/s
(3) only write bps limit
-drive bps_wr=xxx in bytes/s
(4) global iops limit
-drive iops=xxx in ios/s
(5) only read iops limit
-drive iops_rd=xxx in ios/s
(6) only write iops limit
-drive iops_wr=xxx in ios/s
(7) the combination of some limits.
-drive bps=xxx,iops=xxx
Known Limitations:
(1) #1 can not coexist with #2, #3
(2) #4 can not coexist with #5, #6
(3) When bps/iops limits are specified to a small value such as 511 bytes/s,
this VM will hang up. We are considering how to handle this senario.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
