since it can cause I/O errors and data corruption in low
memory or highly fragmented memory situations since Qemu 2.7
use scsi-hd by default instead
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
As Fabian as required,
add an extra flag "with-local-disks" to enable live storage migration with localdisk.
default target storage is same sid than source, this can be overrided with
"targetstorage" option.
I will try improve this later, with optionnal mapping, disk by disk.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
if qga is enabled, we try to freeze the fs before cancelling block job.
if not , we pause the vm.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This allow to migrate disks on local storage to a remote node storage.
When the target node start, a new volumes are created and exposed through qemu embedded nbd server.
qemu drive-mirror is launch on source vm for each disk with nbd server as target.
when drive-mirror reach 100% of 1 disk, we don't complete the block jobs and begin mirror of next disk.
(mirroring are parralel, but we try to mirroring them 1 by 1 to avoid storage && network overload)
Then we live migrate the vm to destination node. (drive-mirror still occur at the same time).
We the vm is livemigrate (source vm paused, target vm pause), we complete the block jobs mirror.
When is done we stop the source vm and resume the target vm
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This will create a new drive for each local drive found,
and start the vm with this new drives.
if targetstorage == 1, we use same sid than original vm disk
a nbd server is started in qemu and expose local volumes to network port
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
we can use multiple drive_mirror in parralel.
block-job-complete can be skipped, if we want to add more mirror job later.
also add support for nbd uri to qemu_drive_mirror
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
otherwise we end up with undeletable VM configs in case
vdisk_free fails (which could happen because of cluster-wide
lock contention, storage problems, ..).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Output before this patch
INFO: include disk 'scsi0' 'file=pve4tank:vm-402-disk-1'
Output after this patch:
INFO: include disk 'scsi0' 'file=pve4tank:vm-402-disk-1' 64G
we're mainly intersted by the volume size here, it was requested in #351
we can migrate local snapshots when on zfs or dir storage with qcow2,
but the check was incorrect
we checked for if (zfs && !qcow2) instead of if (zfs || qcow2)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
When trying to migrate a VM from a node with qemu server <= 4.0-92 to
a node with qemu server >= 4.0-93 we failed as the remote qemu-server
got no explicit migration_type' from the older qemu server on the
source.
Check if migration_type is defined on a incoming migration start, if
not set it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The qmp command 'guest-fsfreeze-freeze' issues in linux a FIFREEZE
ioctl call on all mounted guest FS.
This ioctl call locks the filesystem and gets it into an consistent
state. For this all caches must be synced after blocking new writes
to the FS, which may need a relative long time, especially under high
IO load on the backing storage.
In windows a VSS (Volume Shadow Copy Service) request_freeze will
issued. As of the closed Windows nature the exact mechanisms cannot
be checked but some microsoft blog posts and other forum post suggest
that it should return fast but certain workloads can still trigger a
long delay resulting an similar problems.
Thus try to minimize the error probability and increase the timeout
significantly.
We use 60 minutes as timeout as this seems a limit which should not
get trespassed in a somewhat healthy system.
See:
https://forum.proxmox.com/threads/22192/
see the 'freeze_super' and 'thaw_super' function in fs/super.c from
the linux kernel tree for more details on the freeze behavior in
Linux guests.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
All special flags for Windows 8 and Windows 2012 (win8 type)
are kept the same , since we set flags based on checking if
/^win(\d+)$/ is greater than 6 or 7
because these allow adding arbitrary devices to VMs (and
other potentially dangerous things).
whitelist 'info *' and 'help' as usable with just
VM.Monitor, if more are desired and requested they can be
added later.
