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 <aderum...@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@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
