[pve-devel] [PATCH] enable drive-mirror with iothread for qemu 2.7

[Alexandre DERUMIER]

>>for iothread, I think query-machines will do the job. 
>>We don't care about machine version, only the running qemu binary version is needed. 

I mean qmp "query-version" not "query-machines"


----- Mail original -----
De: "aderumier" <aderumier at odiso.com>
À: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Lundi 17 Octobre 2016 11:33:44
Objet: Re: [pve-devel] [PATCH] enable drive-mirror with iothread for qemu 2.7

>>But we actually have 3 states here: kvm binary version (not interesting 
>>when hotpluggin), machine version (only interesting when migrating), 
>>running qemu version (probably the most important). 

>>The machine part (query-machines) would give us the qemu version the 
>>VM was originally started with before migrations happened, but do all 3 
>>patches/series depend on this version (ie. the pc-i440fx machine 
>>version), or the actually running qemu? I'm pretty sure iothread issues 
>>are gone with an updated qemu regardless of the machine or what qemu we 
>>currently have in /bin if it's not the running one (kvm_user_version()). 
>>The latter is only ever interesting when starting a new VM as far as I 
>>can tell, whereas for hotplugging and migration the machine and 
>>running-version matter. (The latter probably much more than the former). 

yes, I thinked about that too this weekend. 

for iothread, I think query-machines will do the job. 
We don't care about machine version, only the running qemu binary version is needed. 


For cpu hotplug, only machine version is needed.(I think I can remove the extra kvm_version() call) 


I'll update my patches 



----- Mail original ----- 
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com> 
À: "aderumier" <aderumier at odiso.com> 
Cc: "pve-devel" <pve-devel at pve.proxmox.com> 
Envoyé: Lundi 17 Octobre 2016 11:21:10 
Objet: Re: [pve-devel] [PATCH] enable drive-mirror with iothread for qemu 2.7 

On Mon, Oct 17, 2016 at 10:47:56AM +0200, Wolfgang Bumiller wrote: 
> On Thu, Oct 13, 2016 at 12:00:42PM +0200, Alexandre Derumier wrote: 
> > Signed-off-by: Alexandre Derumier <aderumier at odiso.com> 
> > --- 
> > PVE/QemuServer.pm | 7 +++++-- 
> > 1 file changed, 5 insertions(+), 2 deletions(-) 
> > 
> > diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm 
> > index 05edd7a..ec8df94 100644 
> > --- a/PVE/QemuServer.pm 
> > +++ b/PVE/QemuServer.pm 
> > @@ -5933,8 +5933,11 @@ sub clone_disk { 
> > if (!$running || $snapname) { 
> > qemu_img_convert($drive->{file}, $newvolid, $size, $snapname, $sparseinit); 
> > } else { 
> > - #qemu 2.6 
> > - die "drive-mirror is not working currently when iothread is enabled" if $drive->{iothread}; 
> > + 
> > + my $kvmver = kvm_user_version(); 
> > + if (!qemu_machine_feature_enabled (undef, $kvmver, 2, 7)) { 
> 
> Considering this is in the path where $running is true, I think this 
> should include the get_current_qemu_machine() parameter? 

Actually, the same for the cpu hotplug and virtio-scsi iothread patches. 
In the cpuhotplug v1 series you said: 
> qemu_machine_feature_enabled() return current qemu process or if machine version is forced (live migration for example), 
> it's return the machine version. 

But we actually have 3 states here: kvm binary version (not interesting 
when hotpluggin), machine version (only interesting when migrating), 
running qemu version (probably the most important). 

The machine part (query-machines) would give us the qemu version the 
VM was originally started with before migrations happened, but do all 3 
patches/series depend on this version (ie. the pc-i440fx machine 
version), or the actually running qemu? I'm pretty sure iothread issues 
are gone with an updated qemu regardless of the machine or what qemu we 
currently have in /bin if it's not the running one (kvm_user_version()). 
The latter is only ever interesting when starting a new VM as far as I 
can tell, whereas for hotplugging and migration the machine and 
running-version matter. (The latter probably much more than the former). 

_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel