clone: use a fullclone hash instead of $drive->{full}
'full' is not a valid drive property which are now being
checked in print_property_string. Since it's only a
temporary value and passed to clone_disk as parameter it
can be stored separately.
They seem to have a little race (bench show >0s < 1s) between the vm conf file move on source node and replication to,
and resume on target node.
I don't known why this is only with HA, maybe this occur will standard migration too.
Anyway, we don't need to read the vm config file to resume the vm on target host,
as we are sure that the vm is migrated, and config file move action is correct in the cluster.
to change to boot order it is needed to assign a user the
VM.Config.Disk privilege set with the add/modify/delete disk
permissions -> now the patch allows the boot order to be (re)defined
with the VM.Config.Options set - the modify any other VM configuration
Thomas Lamprecht [Thu, 27 Aug 2015 12:56:36 +0000 (14:56 +0200)]
fix 'uninitialized value in concat' due to unnamed VM
This is an minor fix which let's you start the spice console on an
unnamed VM without getting the 'Use of uninitialized value in
concatenation' error.
Also changes the trailing comma from the $conf definition lineto an
semicolon.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The -force flag didn't have any effect since the pending
changes didn't carry over the the flag.
Now forced deletes have an exclamation mark prepended to the
option name.
Note that currently linux guest don't support unplug of dimm when it'sused by kernel memory.
They are some tunning to do with memory zone movable.
http://events.linuxfoundation.org/sites/events/files/lcjp13_chen.pdf
Currently enforce with cpumodel=host on amd cpus don't work,
because amd cpus have unsupported flags in qemu.
This is a protection, and this is good.
but cpumodel host should be never use by users for production (only for testing).
For production and stability, users need to choose a true cpu model which filter
the supported cpuflags by qemu.
So I think we can remove the enforce for host model as for testing it's ok.
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 0]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 1]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 2]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 3]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 4]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 5]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 6]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 7]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 8]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 9]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 12]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 13]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 14]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 15]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 16]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 17]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 23]
warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 24] Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
rdtscp is not supported by qemu and with enforce it's not starting
warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27]
from to qemu wiki
http://wiki.qemu.org/Features/CPUModels#Disabling_features_that_were_always_disabled_on_KVM
"Fact: currently libvirt runs CPU models having rdtscp without the "enforce" flag, and rdtscp is silently disabled
Consequence: libvirt SHOULD use something like "-cpu Opteron_G5,-rdtscp",
especially when it starts using (or emulating) enforce mode
This will require a solution on libvirt side. QEMU will just provide the mechanisms to report CPU model information
and check what the host and QEMU supports, but the decision to disable rdtscp to be able
to run Opteron_G[2345] needs to be taken by libvirt."
Only non-cdrom drives default to cache=none, so the check
for whether to default to aio=native needs to take the same
condition into account.
I combined them close together to make their relation more
visible.
drive-mirror is doing lseek on source image before starting, and this can take a lot of time for big nfs volume
during this time, qmp socket is hanging
http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg01838.html
so we need to setup a big timeout
Since qemu 2.2, a new "ready" flag has been added to blockjob
http://git.qemu.org/?p=qemu.git;a=commit;h=ef6dbf1e46ebd1d41ab669df5bba0bbdec6bd374
to known if we can complete it.
we can't use len==offset to known if all block are mirrored, because behaviour will change soon in qemu 2.3
Instead of taking the total length of the block device as the block
job's length, use the number of dirty sectors. The progress is now the
number of sectors mirrored to the target block device. Note that this
may result in the job's length increasing during operation, which is
however in fact desirable.
"
netcat6 supports both ipv4 and ipv6, contrary to netcat-traditional.
Additionally rather than using the alternatives-managed /bin/nc path,
/bin/nc6 is now used which always points to the netcat6 implementation,
allowing us to drop the netcat-openbsd conflict entry.