enable check if host support all cpu flags configured for the guests
this avoid some bad setup like Opteron vcpu on a intel host for example,
and avoid some bad live migrations
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This reduce guest cpu speed if dirtied bytes is 50% more than the approx.amount of bytes that just got transferred since the last time we were in this routine.
qemu commit :
http://git.qemu.org/?p=qemu.git;a=commit;h=bde1e2ec2176c363c1783bf8887b6b1beb08dfee
tested with "stress -m 2 -c 2" under debian
without autoconvergence : downtime 12s - duration 12min
with autoconvergence : downtime 2s - duration 4min
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
add qxl2 (2monitors),qxl3 (3monitors),qxl4 (4monitors) vga type.
For linux, we only need 1 qxl card with more memory
For windows, we need 1 qxl card by monitor
Original Information from spice-mailing
"
You need to specify multiple devices for Windows VMs. This is what
libvirt gives me (via 'virsh domxml-to-native qemu argv DOMAIN_XML'):
<...> -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 -device qxl,id=video1,ram_size=67108864,vram_size=33554432 -device qxl,id=video2,ram_size=67108864,vram_size=33554432 -device qxl,id=video3,ram_size=67108864,vram_size=33554432
For Linux VM, just one qxl device is OK but then it's advisable to
increase the available RAM:
<...> -vga qxl -global qxl-vga.ram_size=134217728 -global qxl-vga.vram_size=33554432
If you don't turn off surfaces, then you should increase vram size to
say 64 MB from current default of 32 MB.
"
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This patch adds support for unsecure migration using a direct tcp connection
KVM <=> KVM instead of an extra SSH tunnel. Without ssh the limit is just the
bandwith and no longer the CPU / one single core.
You can enable this by adding:
migration_unsecure: 1
to datacenter.cfg
Examples using qemu 1.4 as migration with qemu 1.3 still does not work for me:
current default with SSH Tunnel VM uses 2GB mem:
Dec 27 21:10:32 starting migration of VM 105 to node 'cloud1-1202' (10.255.0.20)
Dec 27 21:10:32 copying disk images
Dec 27 21:10:32 starting VM 105 on remote node 'cloud1-1202'
Dec 27 21:10:35 starting ssh migration tunnel
Dec 27 21:10:36 starting online/live migration on localhost:60000
Dec 27 21:10:36 migrate_set_speed: 8589934592
Dec 27 21:10:36 migrate_set_downtime: 1
Dec 27 21:10:38 migration status: active (transferred 152481002, remaining 1938546688), total 2156396544) , expected downtime 0
Dec 27 21:10:40 migration status: active (transferred 279836995, remaining 1811140608), total 2156396544) , expected downtime 0
Dec 27 21:10:42 migration status: active (transferred 421265271, remaining 1669840896), total 2156396544) , expected downtime 0
Dec 27 21:10:44 migration status: active (transferred 570987974, remaining 1520152576), total 2156396544) , expected downtime 0
Dec 27 21:10:46 migration status: active (transferred 721469404, remaining 1369939968), total 2156396544) , expected downtime 0
Dec 27 21:10:48 migration status: active (transferred 875595258, remaining 1216057344), total 2156396544) , expected downtime 0
Dec 27 21:10:50 migration status: active (transferred 1034654822, remaining 1056931840), total 2156396544) , expected downtime 0
Dec 27 21:10:54 migration status: active (transferred 1176288424, remaining 915369984), total 2156396544) , expected downtime 0
Dec 27 21:10:56 migration status: active (transferred 1339734759, remaining 752050176), total 2156396544) , expected downtime 0
Dec 27 21:10:58 migration status: active (transferred 1503743261, remaining 588206080), total 2156396544) , expected downtime 0
Dec 27 21:11:02 migration status: active (transferred 1645097827, remaining 446906368), total 2156396544) , expected downtime 0
Dec 27 21:11:04 migration status: active (transferred 1810562934, remaining 281751552), total 2156396544) , expected downtime 0
Dec 27 21:11:06 migration status: active (transferred 1964377505, remaining 126033920), total 2156396544) , expected downtime 0
Dec 27 21:11:08 migration status: active (transferred 2077930417, remaining 0), total 2156396544) , expected downtime 0
Dec 27 21:11:09 migration speed: 62.06 MB/s - downtime 37 ms
Dec 27 21:11:09 migration status: completed
Dec 27 21:11:13 migration finished successfuly (duration 00:00:41)
TASK OK
with unsecure migration without SSH Tunnel:
Dec 27 22:43:14 starting migration of VM 105 to node 'cloud1-1203' (10.255.0.22)
Dec 27 22:43:14 copying disk images
Dec 27 22:43:14 starting VM 105 on remote node 'cloud1-1203'
Dec 27 22:43:17 starting online/live migration on 10.255.0.22:60000
Dec 27 22:43:17 migrate_set_speed: 8589934592
Dec 27 22:43:17 migrate_set_downtime: 1
Dec 27 22:43:19 migration speed: 1024.00 MB/s - downtime 1100 ms
Dec 27 22:43:19 migration status: completed
Dec 27 22:43:22 migration finished successfuly (duration 00:00:09)
TASK OK
That way we do not need to run qmp command to get the port.
Set spice ticket expire time to 30 (5 seconds seems a bit too short).
Coding style cleanups.
This add special hyper-v cpu flags for windows guests.
This improve performance and avoid some bsod related to timer.
(I currently disable the hv_vapic flag because I can't get it working).
I have tested all theses flags with: win2003, win2008R2, winxp, linux debian 64bit, on intel and amd physicals processor
It doesn't break live migration, because new cpu flags are not see by guests until a vm reset.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Need for win8 boot.
This flag was missing from rhel < 6.4 host kernel. It's ok now.
But it's also missing from kvm64 model. (It's exist in other cpu models, amd or intel).
So it's pretty safe to enable it.
If the host kernel is older, qemu filter the flag.
This also improve performance of winxp && win7 32 bits guests.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This reduce context switch with multicore guests.
Even if the host cpu don't have x2apic, it's working because qemu have an virtual x2apic implementation for guest.
We need in-kernel irqchip support for this, which is enable for kvm guest since qemu 1.3.
(I don't enable it if nokvm param is set)
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This is experimental code, spice connections are not encryped and thus insecure.
We use ticket passwords for spice auth, and do direct spice connections to
the nodes instead of using a tunnel.
fix : Use of uninitialized value $bridgeid in numeric lt (<) at /usr/share/perl5/PVE/QemuServer.pm line 2774.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Seem that something have change in qemu.
iscsi qemu block driver need to use raw, or we get a segfault. (like rbd).
sheepdog works also with .raw, so we don't need anymore specific storage format, we can use raw.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
A restored VM is never a template. Else we would need to create
base images after the restore, and not all storages supports base
images. Anyways, the user can easily convert the restored VM into a
template later.
If drive have bad sectors, the block job die.
we need to die if stats are empty to avoid this:
transferred: 21440086016 bytes remaining: 34668544 bytes total: 21474754560 bytes progression: 99.84 %
Use of uninitialized value $transferred in subtraction (-) at /usr/share/perl5/PVE/QemuServer.pm line 4611.
Use of uninitialized value $total in subtraction (-) at /usr/share/perl5/PVE/QemuServer.pm line 4611.
Use of uninitialized value $transferred in multiplication (*) at /usr/share/perl5/PVE/QemuServer.pm line 4612.
Use of uninitialized value $total in division (/) at /usr/share/perl5/PVE/QemuServer.pm line 4612.
clone failed: mirroring error: Illegal division by zero at /usr/share/perl5/PVE/QemuServer.pm line 4612.
Maybe it should be improved by catching qmp events, but doesn't seem to work for now
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
we need to remove drive after device has correctly by remove.
With this patch:
Windows : if drive is locked/"mounted", the hot-unplug fail and disk is accessible (100% safe)
Linux: without hotplug module : the hot-unplug fail and disk is accessible (100% safe)
Linux : with hotplug module : the hot-unplug work, but no verification is done is the drive is mounted
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Currently we delete netdev before acpi hot-unplug.
if guest don't support hotplug, this break network.
We need to remove netdev after the device had be correctly unplug.(we check that device has been correctly removed)
So, If guest don't support hotplug, It's simply thrown a unplug error message without breaking the network
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
- usb-tablet on ehci is buggy
- convert to -device syntax
info usb before
----------------
Device 0.2, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet
info usb after
--------------
Device 0.2, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
we need an id to allow hotplug
info pci before
---------------
Bus 0, device 1, function 2:
USB controller: PCI device 8086:7020
IRQ 11.
BAR4: I/O at 0xc040 [0xc05f].
id ""
info pci after
--------------
Bus 0, device 1, function 2:
USB controller: PCI device 8086:7020
IRQ 11.
BAR4: I/O at 0xc040 [0xc05f].
id "uhci"
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
if files (raw,qcow2) are a template, we forbid vm_start.
note : the readonly protection do already the job, but we need a clear message for users
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
if a qcow2 current is a template, we can't rollback to a previous snapshot.
(note that file readonly protection do already the job, but we need a clear error message for user)
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
return 1 if vm is a full template (all disks are base image)
return 2 if vm is a semi-tempalte (mix of base and non-base image)
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
qm template <vmid> [-disk virtio0]
convert a full vm to a template (or only a disk if specify)
we orignal disk to /base (file) or base- (lvm,rbd,sheepdog,nexenta)
we create a snapshot @base if storage need it for clone
we protect the volume or snapshot
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
We don't need to set balloon value and polling interval when a vm is coming from a livemigrate.
(Values are keep in guest memory)
So with autoballooning, this avoid to set the ballon size at ballon_min value when the vm is migrated
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
loop over each disk of the vm config file to find if feature is available.
If one of the disk doesn't have the feature, we return undef, else return 1
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
We can still restore old tar files. But new backups always use new vma
format.
Also moved rescan code from qm into PVE::Qemuserver
bump version to 2.3-1
We need to split the delvm monitor command, like savevm, to delete snapshot onlinefor each volume (qcow2,sheepdog,rbd)
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
this add chardev and virtio-serial devices for communication with guest agent.
vmconfig option :
qga: 1
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This help migrate for vm with of lot of memory access (like database)
live migration tests working:
kvm 1.2 -> kvm 1.2 (xbzrle set on both side)
kvm 1.1 -> kvm 1.2 (xbzrle on target)
kvm 1.1 -> kvm 1.1 (xbzrle not set, qmp command try to set xbzrle but fail)
failing migration
kvm 1.2 -> kvm 1.1 fail, but this is expected.
I tested with a memory benchmark running on the vm with 4GB ram
without xbzrle : migration take 10min, with many network hang
with xbzrle : migration take 1min, no hang
I display xbzrle counters for debug purpose, we can remove them later
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
It could be useful for windows7 and windows2008 , as they are no more classic lsi driver for these platform
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
to be sure that kvm process is killed (but it should kill itself),
and deactivate volumes
I slightly modified this patch (orig. from Alexandre) so that it apply cleanly.
