Re: [libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
On 5 Oct 2014, at 08:00, Paolo Bonzini pbonz...@redhat.com wrote: Il 29/09/2014 09:02, Markus Armbruster ha scritto: If you were just objecting to the fact that pc-1.0 was made to be an alias of either one or the other at compile time, simply drop the second patch of the v2 patchset. I was objecting to making pc-1.0 special. There's nothing special in pc-1.0, other machine types also had differences between qemu-kvm and qemu. And I do not think that upstream has any reason to make pc-1.0 special. OK, so in v5, pc-1.0 is unchanged, and not made special. A new machine type is added which allows import from something (unfortunately) called pc-1.0 in something in qemu's past, as well as some distributions. So, if Ubuntu is okay with breaking pc-1.0 migration from 14.04-old to 14.04-new, the right thing to do is simply that Ubuntu makes its pc-1.0 machine type the qemu-kvm one. No new machine types, no aliases, no anything. That would not allow Ubuntu (or Suse - similarly affected I think) to import pc-1.0 VMs from things actually running pc-1.0, and would mean that newly created pc-1.0 VMs would be 'wrong', perpetuating the problem. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
Michael,
I'm about to post a nice simple v5 of this, but there are a couple of
your comments I am NOT addressing:
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index b72b34e..3c9da23 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -200,12 +200,26 @@ static const VMStateDescription vmstate_pci_status = {
}
};
+static const VMStateDescription vmstate_acpi_compat;
+
don't forward declare things, put them right here.
This is not addressable in v5; in v5 this is a forward declaration of
vmstate_acpi (not _compat). vmstate_acpi references acpi_load_old,
and acpi_load_old references vmstate_acpi, so we need a forward
reference for one of them in any case.
+qemu_opt_get_bool(qemu_get_machine_opts(), qemu-kvm-migration,
+ DEFAULT_QEMU_KVM_MIGRATION)) {
+return vmstate_load_state(f, vmstate_acpi_compat,
+ opaque, version_id);
+}
else if version_id == 2 return -EINVAL?
This is incorrect I think. A version_id of 2 with qemu-kvm_migration
off is permissible, and indicates an inbound migration from qemu-git
1.2, i.e. the old manual loading should be run.
/* qemu-kvm 1.2 uses version 3 but advertised as 2
- * To support incoming qemu-kvm 1.2 migration, change version_id
- * and minimum_version_id to 2 below (which breaks migration from
+ * To support incoming qemu-kvm 1.2 migration, we support
+ * via a command line option a change to minimum_version_id
+ * of 2 in a _compat structure (which breaks migration from
* qemu 1.2).
Actually it's version 3 that breaks migration right?
Pls say this explicitly: s/which/version 3 breaks migration from qemu 1.2/
It's changing the minimum version ID to 2 (from 3) which would break
migration from qemu (git) 1.2, because that uses a version ID of 2,
and we want the old loader to run in that case. I've made this clearer.
--
Alex Bligh
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Sorry that was v5 - git send-email fumble fingers as git-publish
doesn't seem to work well with single patches.
Alex
On 4 Oct 2014, at 17:37, Alex Bligh a...@alex.org.uk wrote:
Add a machine type pc-1.0-qemu-kvm for live migrate compatibility
with qemu-kvm version 1.0.
This patch adds inbound migrate capability from qemu-kvm version
1.0. The main ideas are those set out in Cole Robinson's patch here:
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
however, rather than patching statically (and breaking inbound
migration on existing machine types), I have added a new machine
type (pc-1.0-qemu-kvm) without affecting any other machine types.
The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git,
with pc-1.0 becoming an alias for one or another, as selected
by a configure option (defaulting to pc-1.0-qemu-git, IE no
change).
Two aproaches are taken:
* In hw/timer/i8254_common.c, the VMSTATE_UINT32_TEST macro
is used to test the version for the irq_disable flags,
allowing version 3 or more, or version 2 for an inbound
migrate from qemu-kvm (only).
* In hw/acpi/piix4.c, qemu-kvm incorrectly uses version 2 for
a version 3 structure, causing acpi_load_old to be used.
acpi_load_old detects this situation based on the machine type
and restarts the attempt to load the vmstate using a
customised VMStateDescription. The above cleaner approach is
unavailable here.
I developed this on qemu 2.0 but have forward ported it (trivially)
to master. My testing has been on a VM live-migrated-to-file from
Ubuntu Precise qemu-kvm 1.0.
I have given this a moderate degree of testing but it could do
with more.
Note that certain hardware devices (including QXL) will not
migrate properly due to a fundamental difference in their internal
state between versions.
Also note that (as expected) migration from qemu-2.x to qemu-1.0
will not work, even if the machine types are the same.
Changes from v4
* Revert to using a machine type, but do not add alias machine types,
configure options, or (potentially) change the meaning of
pc-1.0 - leave this for distributions to ponder
* Add compat_props for qemu-kvm-migration to the PIIX4_PM driver
and the i8259 pit-common driver.
Signed-off-by: Alex Bligh a...@alex.org.uk
---
hw/acpi/piix4.c | 26 +++---
hw/i386/pc_piix.c | 27 +++
hw/timer/i8254_common.c | 18 +-
include/hw/i386/pc.h |8
include/hw/timer/i8254_internal.h |1 +
5 files changed, 76 insertions(+), 4 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index b72b34e..5c68d69 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -86,6 +86,8 @@ typedef struct PIIX4PMState {
Notifier cpu_added_notifier;
MemHotplugState acpi_memory_hotplug;
+
+bool qemu_kvm_migration;
} PIIX4PMState;
#define TYPE_PIIX4_PM PIIX4_PM
@@ -200,12 +202,26 @@ static const VMStateDescription vmstate_pci_status = {
}
};
+static const VMStateDescription vmstate_acpi;
+
static int acpi_load_old(QEMUFile *f, void *opaque, int version_id)
{
PIIX4PMState *s = opaque;
int ret, i;
uint16_t temp;
+/* If we are expecting the inbound migration to come from
+ * qemu-kvm 1.0, it will have a version_id of 2 but really
+ * be version 3, so call back the original vmstate_load_state
+ * with a different more tolerant vmstate descriptor
+ */
+if (version_id == 2 s-qemu_kvm_migration) {
+VMStateDescription vmstate_acpi_compat = vmstate_acpi;
+vmstate_acpi_compat.minimum_version_id = 2;
+return vmstate_load_state(f, vmstate_acpi_compat,
+ opaque, version_id);
+}
+
ret = pci_device_load(PCI_DEVICE(s), f);
if (ret 0) {
return ret;
@@ -267,9 +283,11 @@ static const VMStateDescription vmstate_memhp_state = {
};
/* qemu-kvm 1.2 uses version 3 but advertised as 2
- * To support incoming qemu-kvm 1.2 migration, change version_id
- * and minimum_version_id to 2 below (which breaks migration from
- * qemu 1.2).
+ * To support incoming qemu-kvm 1.2 migration, we support
+ * via a command line option a change to minimum_version_id
+ * of 2 in a _compat structure; we can't do this all the time
+ * as using a minimum_version_id of 2 (rather than 3) would
+ * break migration from qemu-git 1.2.
*
*/
static const VMStateDescription vmstate_acpi = {
@@ -589,6 +607,8 @@ static Property piix4_pm_properties[] = {
use_acpi_pci_hotplug, true),
DEFINE_PROP_BOOL(memory-hotplug-support, PIIX4PMState,
acpi_memory_hotplug.is_enabled, true),
+DEFINE_PROP_BOOL(qemu-kvm-migration, PIIX4PMState,
+ qemu_kvm_migration, false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/i386
[libvirt] [PATCH] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Add a machine type pc-1.0-qemu-kvm for live migrate compatibility
with qemu-kvm version 1.0.
This patch adds inbound migrate capability from qemu-kvm version
1.0. The main ideas are those set out in Cole Robinson's patch here:
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
however, rather than patching statically (and breaking inbound
migration on existing machine types), I have added a new machine
type (pc-1.0-qemu-kvm) without affecting any other machine types.
The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git,
with pc-1.0 becoming an alias for one or another, as selected
by a configure option (defaulting to pc-1.0-qemu-git, IE no
change).
Two aproaches are taken:
* In hw/timer/i8254_common.c, the VMSTATE_UINT32_TEST macro
is used to test the version for the irq_disable flags,
allowing version 3 or more, or version 2 for an inbound
migrate from qemu-kvm (only).
* In hw/acpi/piix4.c, qemu-kvm incorrectly uses version 2 for
a version 3 structure, causing acpi_load_old to be used.
acpi_load_old detects this situation based on the machine type
and restarts the attempt to load the vmstate using a
customised VMStateDescription. The above cleaner approach is
unavailable here.
I developed this on qemu 2.0 but have forward ported it (trivially)
to master. My testing has been on a VM live-migrated-to-file from
Ubuntu Precise qemu-kvm 1.0.
I have given this a moderate degree of testing but it could do
with more.
Note that certain hardware devices (including QXL) will not
migrate properly due to a fundamental difference in their internal
state between versions.
Also note that (as expected) migration from qemu-2.x to qemu-1.0
will not work, even if the machine types are the same.
Changes from v4
* Revert to using a machine type, but do not add alias machine types,
configure options, or (potentially) change the meaning of
pc-1.0 - leave this for distributions to ponder
* Add compat_props for qemu-kvm-migration to the PIIX4_PM driver
and the i8259 pit-common driver.
Signed-off-by: Alex Bligh a...@alex.org.uk
---
hw/acpi/piix4.c | 26 +++---
hw/i386/pc_piix.c | 27 +++
hw/timer/i8254_common.c | 18 +-
include/hw/i386/pc.h |8
include/hw/timer/i8254_internal.h |1 +
5 files changed, 76 insertions(+), 4 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index b72b34e..5c68d69 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -86,6 +86,8 @@ typedef struct PIIX4PMState {
Notifier cpu_added_notifier;
MemHotplugState acpi_memory_hotplug;
+
+bool qemu_kvm_migration;
} PIIX4PMState;
#define TYPE_PIIX4_PM PIIX4_PM
@@ -200,12 +202,26 @@ static const VMStateDescription vmstate_pci_status = {
}
};
+static const VMStateDescription vmstate_acpi;
+
static int acpi_load_old(QEMUFile *f, void *opaque, int version_id)
{
PIIX4PMState *s = opaque;
int ret, i;
uint16_t temp;
+/* If we are expecting the inbound migration to come from
+ * qemu-kvm 1.0, it will have a version_id of 2 but really
+ * be version 3, so call back the original vmstate_load_state
+ * with a different more tolerant vmstate descriptor
+ */
+if (version_id == 2 s-qemu_kvm_migration) {
+VMStateDescription vmstate_acpi_compat = vmstate_acpi;
+vmstate_acpi_compat.minimum_version_id = 2;
+return vmstate_load_state(f, vmstate_acpi_compat,
+ opaque, version_id);
+}
+
ret = pci_device_load(PCI_DEVICE(s), f);
if (ret 0) {
return ret;
@@ -267,9 +283,11 @@ static const VMStateDescription vmstate_memhp_state = {
};
/* qemu-kvm 1.2 uses version 3 but advertised as 2
- * To support incoming qemu-kvm 1.2 migration, change version_id
- * and minimum_version_id to 2 below (which breaks migration from
- * qemu 1.2).
+ * To support incoming qemu-kvm 1.2 migration, we support
+ * via a command line option a change to minimum_version_id
+ * of 2 in a _compat structure; we can't do this all the time
+ * as using a minimum_version_id of 2 (rather than 3) would
+ * break migration from qemu-git 1.2.
*
*/
static const VMStateDescription vmstate_acpi = {
@@ -589,6 +607,8 @@ static Property piix4_pm_properties[] = {
use_acpi_pci_hotplug, true),
DEFINE_PROP_BOOL(memory-hotplug-support, PIIX4PMState,
acpi_memory_hotplug.is_enabled, true),
+DEFINE_PROP_BOOL(qemu-kvm-migration, PIIX4PMState,
+ qemu_kvm_migration, false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7081c08..56555c1 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -644,6 +644,32 @@ static QEMUMachine pc_machine_v1_0 = {
.hw_version = 1.0,
};
+#define PC_COMPAT_1_0_QEMU_KVM \
+PC_COMPAT_1_0
Re: [libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
On 29 Sep 2014, at 11:08, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Sep 28, 2014 at 09:33:08PM +0100, Alex Bligh wrote: Hang on a second! v2 of this patch DID use a new virtual machine, called exactly that. I thought you were objecting to that and wanting a machine parameter instead! It's far easier with a new machine type, and I'd far prefer a new machine type. If you were just objecting to the fact that pc-1.0 was made to be an alias of either one or the other at compile time, simply drop the second patch of the v2 patchset. I think same applies to v3 that I reviewed right? Absolutely, I'm fine with just a new machine type. This means that management tools will need to learn to add -qemu-kvm suffix to the machine name if user requested compatibility with qemu-kvm. I think there were some implementation issues with patch 1/2 though. If we have a new machine type, I don't /think/ I need the early_init thing at all (I may be wrong about that). Good. OK, I will respin this when I get a chance with the new machine type back and hopefully address some of the other issues you brought up. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
Michael,
+static const VMStateDescription vmstate_acpi_compat = {
+.name = piix4_pm,
+.version_id = 3,
+.minimum_version_id = 2,
+.minimum_version_id_old = 1,
+.load_state_old = NULL, /* to avoid recursion */
+.post_load = vmstate_acpi_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.evt.sts, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.evt.en, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.cnt.cnt, PIIX4PMState),
+VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState),
+VMSTATE_TIMER(ar.tmr.timer, PIIX4PMState),
+VMSTATE_INT64(ar.tmr.overflow_time, PIIX4PMState),
+VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe, ACPIGPE),
+VMSTATE_STRUCT_TEST(
+acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT],
+PIIX4PMState,
+vmstate_test_no_use_acpi_pci_hotplug,
+2, vmstate_pci_status,
+struct AcpiPciHpPciStatus),
+VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState,
+vmstate_test_use_acpi_pci_hotplug),
+VMSTATE_END_OF_LIST()
+}
+};
+
Please don't duplicate code like this.
What is the difference here? Is it just .minimum_version_id?
Why not just update it in vmstate_acpi?
That and the change to load_state_old.
I thought I had tried that, but that it got memcpy'd somewhere deep
in QOM I think (as part of the inheritance). If the structure
never gets used again (for e.g. export?) I suppose I could
patch it live in acpi_load_old - is that what you meant?
I'd also have to remove the 'const' tag, which I seem to remember
was non-trivial.
Perhaps I could make a copy and change the fields.
+/* NB cirrus-vga default value is 8MB anyway, save if we
+ * monkey patch it to change the default when the qemu-kvm-migration
+ * machine parameter is selected
+ */
+
This is too hacky for my taste.
How about creating a new machine e.g. pc-qemu-kvm-1.0 and in
pc_early_init_pci_1_0, changing compat_props for pc-1.0 to point to the
compat_props of pc-qemu-kvm-1.0?
Hang on a second! v2 of this patch DID use a new virtual machine,
called exactly that. I thought you were objecting to that and
wanting a machine parameter instead! It's far easier with a new
machine type, and I'd far prefer a new machine type.
If you were just objecting to the fact that pc-1.0 was made to
be an alias of either one or the other at compile time, simply
drop the second patch of the v2 patchset.
If we have a new machine type, I don't /think/ I need the early_init
thing at all (I may be wrong about that).
--
Alex Bligh
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
Markus, On 24 Sep 2014, at 09:05, Markus Armbruster arm...@redhat.com wrote: Alex Bligh a...@alex.org.uk writes: This patch series adds inbound migrate capability from qemu-kvm version 1.0. The main ideas are those set out in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20 however, rather than patching statically (and breaking inbound migration on existing machine types), I have added a new machine parameter (qemu-kvm-migration) which when turned on affects the pc-1.0 machine type. Usage: -machine pc-1.0,qemu-kvm-migration=on Forgive me if this has been discussed already: why not simply a separate machine type pc-1.0-qemu-kvm? That's what v2 of the patch set does (and I prefer v2). However, mst wanted it done this way. Three aproaches are taken: * cirrus-vga.vgamem_mb defaults to 16 rather than 8. In order to keep -global cirrus-vga.vgamem_mb working even with qemu-kvm-migration=on, this is monkey-patchedinto the default valueof the MachineState structure's compat_props list. This part fires only for pc-1.0, because it's in pc_early_init_pci_1_0(). Yes, intentional. I should have noted that. That's because qemu-kvm-migration=on the VRAM change was designed to work only with pc-1.0. I haven't looked at trying to make other (older) qemu-kvm machine migrations work, but (with the stuff below), I would guess it would work with the appropriate command line options for VRAM size. Obviously I could put early init elsewhere. * In hw/timer/i8254_common.c, the VMSTATE_UINT32_TEST macro is used to test the version for the irq_disable flags, allowing version 3 or more, or version 2 for an inbound migrate from qemu-kvm (only). * In hw/acpi/piix4.c, qemu-kvm incorrectly uses version 2 for a version 3 structure, causing acpi_load_old to be used. acpi_load_old detects this situation based on the machine type and restarts the attempt to load the vmstate using a customised VMStateDescription. The above cleaner approach is unavailable here. These parts apply to all machine types, don't they? They apply only when qemu-kvm-migration=on is selected, but to any machine type; however machine types newer than pc-1.0 will be exporting v3 I think anyway. Changes since v1: * Do not use a machine type, use a machine parameter. Okay, it has been discussed already. I'd appreciate a brief recap all the same. See above. I preferred the machine type. But I got to learn more about QOM on the way :-) -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm
On 22 Sep 2014, at 12:36, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Sep 21, 2014 at 03:38:59PM +0100, Alex Bligh wrote: Add a configure option --enable-pc-1-0-qemu-kvm and the corresponding --disable-pc-1-0-qemu-kvm, defaulting to disabled. Rename machine type pc-1.0 to pc-1.0-qemu-git. Make pc-1.0 machine type an alias of either pc-1.0-qemu-kvm or pc-1.0-qemu-git depending on the value of the config option. Signed-off-by: Alex Bligh a...@alex.org.uk I have to say, this one bothers me. We end up not being able to predict what does pc-1.0 reference. The whole point is to make it easy for distributions to make pc-1.0 do an appropriate thing for them, an appropriate thing being what their previous release(s) meant by pc-1.0. Sadly, pc-1.0 means more than one thing - on Ubuntu it really means qemu-kvm's pc-1.0 and on other systems (and upstream) it means qemu-git's pc-1.0. This is horrible, but it's not the fault of this patch, is simply current reality. Right now, you can't tell what pc-1.0 does anyway, as it does a different thing on Ubuntu Precise to Ubuntu Trusty (for instance). If we're going to provide compatibility to the machine type name level (which is the purpose here) then sadly we need something like this. As for 'not being able to predict', actually post this patch the situation is far clearer, as '-M ?' tells you exactly what pc-1.0 will do, by showing what it's an alias for. Users also don't get qemu from git so I don't see why does git make sense in the name? Agree with that, but I couldn't think of anything better. 'qemu-upstream'? 'qemu'? Legacy management applications invoked qemu as qemu-kvm - how about detecting that name and switching the machine types? It might make sense to also set -enable-kvm a Sadly that is not true. For instance on Ubuntu Precise it's invoked as qemu-system-x86_64 by at least one management application known to me. I'm not quite sure why you say legacy management applications. This applies to /any/ management application. Unless we're going to burden every management application with this problem, we need to fix it. Just as a reminder, the ./configure value defaults to off, which means there is no change in current behaviour. Only if the ./configure value is changed does it result in the behaviour of pc-1.0 changing, and that is evident from the help line. And it's possible to specify a specific variant of 1.0 (irrespective of the default) from the command line. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v3 1/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Michael,
(Reordering)
On 22 Sep 2014, at 12:50, Michael S. Tsirkin m...@redhat.com wrote:
@@ -257,6 +259,11 @@ static int pit_dispatch_post_load(void *opaque, int
version_id)
return 0;
}
+static bool has_irq_disabled(void *opaque, int version_id)
+{
+return (version_id = 3) || ((version_id == 2) qemu_kvm_1_0_compat);
+}
+
Can you add a device property like we do for
other compat behaviours?
That's better than a global variable.
Same for other devices.
I can see 'opaque' points to PIIX4PMState or PITCommonState. Do you mean
to put them in there? Could you point to an example to copy.
--
Alex Bligh
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm
Sadly that is not true. For instance on Ubuntu Precise it's invoked as qemu-system-x86_64 by at least one management application known to me. Well change it to call qemu-kvm then :) Also what happens if you install qemu as well? Does it conflict? I'm not an Ubuntu maintainer but AFAIK qemu-kvm is deprecated. It may only be there to support upgrades. We still need to support migration from qemu running on Precise to qemu running on Trusty. The trusty instance may not have qemu-kvm installed. If we were looking at argv[0], we'd really want to look at it on the /sending/ machine. Forcing qemu to be involved as qemu-kvm solely on the basis some users might want to migrate a VM in from a previous version does not sound practical. I'm not quite sure why you say legacy management applications. Because any non legacy one can be patched. Well this is where we diverge. I think the distro needs a way to change the default behaviour, i.e. so the existing command line will do something different. This applies to /any/ management application. Unless we're going to burden every management application with this problem, we need to fix it. Just as a reminder, the ./configure value defaults to off, which means there is no change in current behaviour. Yes but this still perpetuates the mess. If you prefer using -M pc-1.0, add a new property and teach management to set it. But no silent compile-time behind the scenes changes please. OK, how about we keep the aliases, and make pc-1.0 default to the pc-1.0-qemu-git. We then add a command line option to make pc-1.0 mean pc-1.0-qemu-kvm, with that obviously defaulting to off. Then distros can then put the option in /etc/qemu/target-x86_64.conf or whatever. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm
On 22 Sep 2014, at 16:45, Andreas Färber afaer...@suse.de wrote: What about adding a bool property qemu-kvm-compat to the MachineClass? Then a qemu-kvm shell script (like SUSE uses) can pass -global machine.qemu-kvm-compat=on whereas qemu-system-x86_64 would run in the default non-qemu-kvm mode (config on disk would affect both). It would also allow running -machine pc-0.15,qemu-kvm-compat=on, ditching lots of new machine names and avoiding the name bikeshedding. I'd be happy with that. Presumably downstream can then patch things so qemu-kvm-compat defaults in the way they want (if we don't like the configure option). However, that's not compatible with using PC_COMPAT as far as I know (unless there is some cunning way you can make a machine parameter change compat_props things). -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm
On 22 Sep 2014, at 16:44, Paolo Bonzini pbonz...@redhat.com wrote: time, RHEL7 did it. Ubuntu didn't, and probably neither did Debian. This patch singles out pc-1.0 just because it used to be the default in Ubuntu 12.04. So basically it's making upstream carry the burden of a decision of the Ubuntu folks. It's understandable that Alex disagrees with the decision, but nevertheless it's not something that upstream should agree with. Also, another horse that has left the barn: it's already too late to apply this patch to upstream Ubuntu. If you do that, any machine created with 12.04 and reused with 14.04 will fail to migrate to another 14.04 machine that includes this patch, as I understand it. So as things stand, I don't see a reason to apply this patch upstream. Well, Ubuntu (Serge I think) said in the Ubuntu bug report he'd be quite willing to break migration of pc-1.0 machine types from 14.04 to 14.04 because that machine type isn't the default anyway on 14.04. But that isn't the point, as the patch (as a whole) doesn't break anything - it merely gives the possibility to import pc-1.0 machines from qemu-kvm. That's useful even if you build qemu from source every time. Or were you just arguing against the ./configure option? -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
Add a machine parameter qemu-kvm-migration for live migrate compatibility
with qemu-kvm version 1.0. Usage:
-machine pc-1.0,qemu-kvm-migration=on
This has three effects:
1. cirrus-vga.vgamem_mb defaults to 16 rather than 8
2. A type 2 piix4_pm record is interpreted as being type 3
3. A type 2 i8254 PIT common state is interpreted as being type 3
Signed-off-by: Alex Bligh a...@alex.org.uk
---
hw/acpi/piix4.c | 47 +--
hw/core/machine.c | 16
hw/i386/pc.c|1 +
hw/i386/pc_piix.c | 25 +
hw/timer/i8254_common.c | 11 ++-
include/hw/boards.h |7 +++
vl.c|7 +++
7 files changed, 111 insertions(+), 3 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index b72b34e..3c9da23 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -200,12 +200,26 @@ static const VMStateDescription vmstate_pci_status = {
}
};
+static const VMStateDescription vmstate_acpi_compat;
+
static int acpi_load_old(QEMUFile *f, void *opaque, int version_id)
{
PIIX4PMState *s = opaque;
int ret, i;
uint16_t temp;
+/* If we are expecting the inbound migration to come from
+ * qemu-kvm 1.0, it will have a version_id of 2 but really
+ * be version 3, so call back the original vmstate_load_state
+ * with a different more tolerant vmstate descriptor
+ */
+if ((version_id == 2)
+qemu_opt_get_bool(qemu_get_machine_opts(), qemu-kvm-migration,
+ DEFAULT_QEMU_KVM_MIGRATION)) {
+return vmstate_load_state(f, vmstate_acpi_compat,
+ opaque, version_id);
+}
+
ret = pci_device_load(PCI_DEVICE(s), f);
if (ret 0) {
return ret;
@@ -267,8 +281,9 @@ static const VMStateDescription vmstate_memhp_state = {
};
/* qemu-kvm 1.2 uses version 3 but advertised as 2
- * To support incoming qemu-kvm 1.2 migration, change version_id
- * and minimum_version_id to 2 below (which breaks migration from
+ * To support incoming qemu-kvm 1.2 migration, we support
+ * via a command line option a change to minimum_version_id
+ * of 2 in a _compat structure (which breaks migration from
* qemu 1.2).
*
*/
@@ -307,6 +322,34 @@ static const VMStateDescription vmstate_acpi = {
}
};
+static const VMStateDescription vmstate_acpi_compat = {
+.name = piix4_pm,
+.version_id = 3,
+.minimum_version_id = 2,
+.minimum_version_id_old = 1,
+.load_state_old = NULL, /* to avoid recursion */
+.post_load = vmstate_acpi_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.evt.sts, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.evt.en, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.cnt.cnt, PIIX4PMState),
+VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState),
+VMSTATE_TIMER(ar.tmr.timer, PIIX4PMState),
+VMSTATE_INT64(ar.tmr.overflow_time, PIIX4PMState),
+VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe, ACPIGPE),
+VMSTATE_STRUCT_TEST(
+acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT],
+PIIX4PMState,
+vmstate_test_no_use_acpi_pci_hotplug,
+2, vmstate_pci_status,
+struct AcpiPciHpPciStatus),
+VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState,
+vmstate_test_use_acpi_pci_hotplug),
+VMSTATE_END_OF_LIST()
+}
+};
+
static void piix4_reset(void *opaque)
{
PIIX4PMState *s = opaque;
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 7a66c57..bbccba9 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -235,6 +235,20 @@ static void machine_set_firmware(Object *obj, const char
*value, Error **errp)
ms-firmware = g_strdup(value);
}
+static bool machine_get_qemu_kvm_migration(Object *obj, Error **errp)
+{
+MachineState *ms = MACHINE(obj);
+
+return ms-qemu_kvm_migration;
+}
+
+static void machine_set_qemu_kvm_migration(Object *obj, bool value, Error
**errp)
+{
+MachineState *ms = MACHINE(obj);
+
+ms-qemu_kvm_migration = value;
+}
+
static void machine_initfn(Object *obj)
{
object_property_add_str(obj, accel,
@@ -274,6 +288,8 @@ static void machine_initfn(Object *obj)
object_property_add_bool(obj, usb, machine_get_usb, machine_set_usb,
NULL);
object_property_add_str(obj, firmware,
machine_get_firmware, machine_set_firmware, NULL);
+object_property_add_bool(obj, qemu-kvm-migration,
+ machine_get_qemu_kvm_migration,
machine_set_qemu_kvm_migration, NULL);
}
static void machine_finalize(Object *obj)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2cf22b1..c74f2f9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1516,6 +1516,7 @@ static void pc_generic_machine_class_init
[libvirt] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
This patch series adds inbound migrate capability from qemu-kvm version 1.0. The main ideas are those set out in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20 however, rather than patching statically (and breaking inbound migration on existing machine types), I have added a new machine parameter (qemu-kvm-migration) which when turned on affects the pc-1.0 machine type. Usage: -machine pc-1.0,qemu-kvm-migration=on Three aproaches are taken: * cirrus-vga.vgamem_mb defaults to 16 rather than 8. In order to keep -global cirrus-vga.vgamem_mb working even with qemu-kvm-migration=on, this is monkey-patched into the default value of the MachineState structure's compat_props list. * In hw/timer/i8254_common.c, the VMSTATE_UINT32_TEST macro is used to test the version for the irq_disable flags, allowing version 3 or more, or version 2 for an inbound migrate from qemu-kvm (only). * In hw/acpi/piix4.c, qemu-kvm incorrectly uses version 2 for a version 3 structure, causing acpi_load_old to be used. acpi_load_old detects this situation based on the machine type and restarts the attempt to load the vmstate using a customised VMStateDescription. The above cleaner approach is unavailable here. The above monkey-patching must be done between the selection of the MachineClass and the processing of the machine parameters (on the one hand) and the processing of the compat_props list and the globals on the command line. To do this I have added an earlyinit function to MachineState and QEMUMachine. I developed this on qemu 2.0 but have forward ported it (trivially) to master. My testing has been on a VM live-migrated-to-file from Ubuntu Precise qemu-kvm 1.0. I have given this a moderate degree of testing but it could do with more. Note that certain hardware devices (including QXL) will not migrate properly due to a fundamental difference in their internal state between versions. Also note that (as expected) migration from qemu-2.x to qemu-1.0 will not work, even if the machine types are the same. Changes since v1: * Do not use a machine type, use a machine parameter. Alex Bligh (1): Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm hw/acpi/piix4.c | 47 +-- hw/core/machine.c | 16 hw/i386/pc.c|1 + hw/i386/pc_piix.c | 25 + hw/timer/i8254_common.c | 11 ++- include/hw/boards.h |7 +++ vl.c|7 +++ 7 files changed, 111 insertions(+), 3 deletions(-) -- 1.7.9.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm
On 22 Sep 2014, at 20:10, Paolo Bonzini pbonz...@redhat.com wrote: I'm arguing against special-casing pc-1.0. Just apply the patch to Ubuntu downstream and call it a day. It's perfectly normal for machine types to be part of the downstream (not so secret) sauce. Well, I've just sent through a version that works as a machine parameter instead. If upstream doesn't like this, I'd prefer downstream took v2 of the patch (which makes -M pc-1.0 work) instead. That's also what Serge tested. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
This patch series adds inbound migrate capability from qemu-kvm version 1.0. The main ideas are those set out in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20 however, rather than patching statically (and breaking inbound migration on existing machine types), I have added a new machine type (pc-1.0-qemu-kvm) without affecting any other machine types. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change). Two aproaches are taken: * In hw/timer/i8254_common.c, the VMSTATE_UINT32_TEST macro is used to test the version for the irq_disable flags, allowing version 3 or more, or version 2 for an inbound migrate from qemu-kvm (only). * In hw/acpi/piix4.c, qemu-kvm incorrectly uses version 2 for a version 3 structure, causing acpi_load_old to be used. acpi_load_old detects this situation based on the machine type and restarts the attempt to load the vmstate using a customised VMStateDescription. The above cleaner approach is unavailable here. I developed this on qemu 2.0 but have forward ported it (trivially) to master. My testing has been on a VM live-migrated-to-file from Ubuntu Precise qemu-kvm 1.0. I have given this a moderate degree of testing but it could do with more. Note that certain hardware devices (including QXL) will not migrate properly due to a fundamental difference in their internal state between versions. Also note that (as expected) migration from qemu-2.x to qemu-1.0 will not work, even if the machine types are the same. Alex Bligh (2): Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm Add configure option --enable-pc-1-0-qemu-kvm configure | 12 hw/acpi/piix4.c | 47 +-- hw/i386/pc_piix.c | 38 +- hw/timer/i8254_common.c | 10 +- 4 files changed, 103 insertions(+), 4 deletions(-) -- 1.7.9.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3 1/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Add a machine type pc-1.0-qemu-kvm for live migrate compatibility
with qemu-kvm version 1.0.
Signed-off-by: Alex Bligh a...@alex.org.uk
---
hw/acpi/piix4.c | 47 +--
hw/i386/pc_piix.c | 30 ++
hw/timer/i8254_common.c | 10 +-
3 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index b72b34e..e016005 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -37,6 +37,8 @@
#include hw/acpi/memory_hotplug.h
#include hw/acpi/acpi_dev_interface.h
+extern int qemu_kvm_1_0_compat;
+
//#define DEBUG
#ifdef DEBUG
@@ -200,12 +202,24 @@ static const VMStateDescription vmstate_pci_status = {
}
};
+static const VMStateDescription vmstate_acpi_compat;
+
static int acpi_load_old(QEMUFile *f, void *opaque, int version_id)
{
PIIX4PMState *s = opaque;
int ret, i;
uint16_t temp;
+/* If we are expecting the inbound migration to come from
+ * qemu-kvm 1.0, it will have a version_id of 2 but really
+ * be version 3, so call back the original vmstate_load_state
+ * with a different more tolerant vmstate descriptor
+ */
+if ((version_id == 2) (qemu_kvm_1_0_compat)) {
+return vmstate_load_state(f, vmstate_acpi_compat,
+ opaque, version_id);
+}
+
ret = pci_device_load(PCI_DEVICE(s), f);
if (ret 0) {
return ret;
@@ -267,8 +281,9 @@ static const VMStateDescription vmstate_memhp_state = {
};
/* qemu-kvm 1.2 uses version 3 but advertised as 2
- * To support incoming qemu-kvm 1.2 migration, change version_id
- * and minimum_version_id to 2 below (which breaks migration from
+ * To support incoming qemu-kvm 1.2 migration, we support
+ * via a command line option a change to minimum_version_id
+ * of 2 in a _compat structure (which breaks migration from
* qemu 1.2).
*
*/
@@ -307,6 +322,34 @@ static const VMStateDescription vmstate_acpi = {
}
};
+static const VMStateDescription vmstate_acpi_compat = {
+.name = piix4_pm,
+.version_id = 3,
+.minimum_version_id = 2,
+.minimum_version_id_old = 1,
+.load_state_old = NULL, /* to avoid recursion */
+.post_load = vmstate_acpi_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.evt.sts, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.evt.en, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.cnt.cnt, PIIX4PMState),
+VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState),
+VMSTATE_TIMER(ar.tmr.timer, PIIX4PMState),
+VMSTATE_INT64(ar.tmr.overflow_time, PIIX4PMState),
+VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe, ACPIGPE),
+VMSTATE_STRUCT_TEST(
+acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT],
+PIIX4PMState,
+vmstate_test_no_use_acpi_pci_hotplug,
+2, vmstate_pci_status,
+struct AcpiPciHpPciStatus),
+VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState,
+vmstate_test_use_acpi_pci_hotplug),
+VMSTATE_END_OF_LIST()
+}
+};
+
static void piix4_reset(void *opaque)
{
PIIX4PMState *s = opaque;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7081c08..48a4942 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -70,6 +70,8 @@ static bool smbios_legacy_mode;
static bool gigabyte_align = true;
static bool has_reserved_memory = true;
+int qemu_kvm_1_0_compat;
+
/* PC hardware initialisation */
static void pc_init1(MachineState *machine,
int pci_enabled,
@@ -386,6 +388,14 @@ static void pc_init_pci_1_2(MachineState *machine)
pc_init_pci(machine);
}
+/* PC machine init function for qemu-kvm 1.0 */
+static void pc_init_pci_1_2_qemu_kvm(MachineState *machine)
+{
+qemu_kvm_1_0_compat = 1;
+pc_compat_1_2(machine);
+pc_init_pci(machine);
+}
+
/* PC init function for pc-0.10 to pc-0.13 */
static void pc_init_pci_no_kvmclock(MachineState *machine)
{
@@ -644,6 +654,25 @@ static QEMUMachine pc_machine_v1_0 = {
.hw_version = 1.0,
};
+#define PC_COMPAT_1_0_QEMU_KVM \
+PC_COMPAT_1_0,\
+{\
+.driver = cirrus-vga,\
+.property = vgamem_mb,\
+.value= stringify(16),\
+}
+
+static QEMUMachine pc_machine_v1_0_qemu_kvm = {
+PC_I440FX_1_2_MACHINE_OPTIONS,
+.name = pc-1.0-qemu-kvm,
+.init = pc_init_pci_1_2_qemu_kvm,
+.compat_props = (GlobalProperty[]) {
+PC_COMPAT_1_0_QEMU_KVM,
+{ /* end of list */ }
+},
+.hw_version = 1.0,
+};
+
#define PC_COMPAT_0_15 \
PC_COMPAT_1_0
@@ -886,6 +915,7 @@ static void pc_machine_init(void)
qemu_register_pc_machine(pc_machine_v1_2);
qemu_register_pc_machine(pc_machine_v1_1);
qemu_register_pc_machine(pc_machine_v1_0);
+qemu_register_pc_machine
[libvirt] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm
Add a configure option --enable-pc-1-0-qemu-kvm and the
corresponding --disable-pc-1-0-qemu-kvm, defaulting
to disabled.
Rename machine type pc-1.0 to pc-1.0-qemu-git.
Make pc-1.0 machine type an alias of either pc-1.0-qemu-kvm
or pc-1.0-qemu-git depending on the value of the config
option.
Signed-off-by: Alex Bligh a...@alex.org.uk
---
configure | 12
hw/i386/pc_piix.c |8 +++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index f7685b5..b143302 100755
--- a/configure
+++ b/configure
@@ -335,6 +335,7 @@ libssh2=
vhdx=
quorum=
numa=
+pc_1_0_qemu_kvm=no
# parse CC options first
for opt do
@@ -1125,6 +1126,10 @@ for opt do
;;
--enable-numa) numa=yes
;;
+ --disable-pc-1-0-qemu-kvm) pc_1_0_qemu_kvm=no
+ ;;
+ --enable-pc-1-0-qemu-kvm) pc_1_0_qemu_kvm=yes
+ ;;
*)
echo ERROR: unknown option $opt
echo Try '$0 --help' for more information
@@ -1394,6 +1399,8 @@ Advanced options (experts only):
--enable-quorum enable quorum block filter support
--disable-numa disable libnuma support
--enable-numaenable libnuma support
+ --disable-pc-1-0-qemu-kvm disable pc-1.0 machine type reflecting qemu-kvm
+ --enable-pc-1-0-qemu-kvm enable pc-1.0 machine type reflecting qemu-kvm
NOTE: The object files are built at the place where configure is launched
EOF
@@ -4262,6 +4269,7 @@ echo Quorum$quorum
echo lzo support $lzo
echo snappy support$snappy
echo NUMA host support $numa
+echo pc-1.0 qemu-kvm $pc_1_0_qemu_kvm
if test $sdl_too_old = yes; then
echo - Your SDL version is too old - please upgrade to have SDL support
@@ -5241,6 +5249,10 @@ if test $numa = yes; then
echo CONFIG_NUMA=y $config_host_mak
fi
+if test $pc_1_0_qemu_kvm = yes; then
+ echo CONFIG_PC_1_0_QEMU_KVM=y $config_host_mak
+fi
+
# build tree in object directory in case the source is not in the current
directory
DIRS=tests tests/tcg tests/tcg/cris tests/tcg/lm32 tests/libqos
tests/qapi-schema tests/tcg/xtensa tests/qemu-iotests
DIRS=$DIRS fsdev
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 48a4942..b7a4af0 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -646,7 +646,10 @@ static QEMUMachine pc_machine_v1_1 = {
static QEMUMachine pc_machine_v1_0 = {
PC_I440FX_1_2_MACHINE_OPTIONS,
-.name = pc-1.0,
+.name = pc-1.0-qemu-git,
+#ifndef CONFIG_PC_1_0_QEMU_KVM
+.alias = pc-1.0,
+#endif
.compat_props = (GlobalProperty[]) {
PC_COMPAT_1_0,
{ /* end of list */ }
@@ -665,6 +668,9 @@ static QEMUMachine pc_machine_v1_0 = {
static QEMUMachine pc_machine_v1_0_qemu_kvm = {
PC_I440FX_1_2_MACHINE_OPTIONS,
.name = pc-1.0-qemu-kvm,
+#ifdef CONFIG_PC_1_0_QEMU_KVM
+.alias = pc-1.0,
+#endif
.init = pc_init_pci_1_2_qemu_kvm,
.compat_props = (GlobalProperty[]) {
PC_COMPAT_1_0_QEMU_KVM,
--
1.7.9.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 7 Aug 2014, at 20:26, Serge E. Hallyn se...@hallyn.com wrote: A-ha, acpi wasn't a problem. I actually had a general migration problem even when coming from other utopic hosts. With that fixed, I've got successful migration from qemu-kvm 1.0 in precise to a utopic host. That's good news. You might try the 2 patches here: https://github.com/abligh/qemu/tree/livemigrate-qemu-kvm-to-qemu-2.0.0-test-2 and see if you can get Precise to Trusty migration working (as well as Precise to Utopic) -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Serge, On 7 Aug 2014, at 03:50, Serge Hallyn serge.hal...@ubuntu.com wrote: This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a boolean in /etc/libvirt/qemu.conf) Qemu starts with decent looking args, but for some reason the the migration is failing - still looking through the logfile to figure out why. Are you using exactly the same arguments by hand and with libvirt? Also, on reflection, given one of the changes between 1.0 and 2.0 is ACPI, I should probably have done some testing with an ACPI enabled image, rather than just cirros (which not ACPI enabled); any chance this is ACPI related? Now sadly my tests are being further slowed down by qcow corruption on my host, but I don't think that was the cause of my failure. Whilst getting the patch right in the first place I tend to cp from a known good image. Obviously once it works, qcow2 corruption should not happen. But failed migrations (with or without my patch) do appear to cause this relatively frequently. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 4 Aug 2014, at 14:31, Michael S. Tsirkin m...@redhat.com wrote: On Fri, Aug 01, 2014 at 08:12:11PM +0100, Alex Bligh wrote: This patch series adds inbound migrate capability from qemu-kvm version 1.0. The main ideas are those set out in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20 however, rather than patching statically (and breaking inbound migration on existing machine types), I have added a new machine type (pc-1.0-qemu-kvm) without affecting any other machine types. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change). This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained. Ow come on. Just add a flag and select the appropriate format based on it, using field_exists. I don't think it is that simple. All those things are initialised well before the command line is parsed. Unless I'm missing what you are saying? -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 4 Aug 2014, at 16:38, Serge Hallyn serge.hal...@ubuntu.com wrote: If you really want it to be called pc-1.0, you can make it a machine property instead. E.g. qemu-kvm-compatibility. Teach management to set it if remote is qemu-kvm: -machine pc-1.0,qemu-kvm-compatibility=on That sounds nice - Alex, what do you think? Not having used the machine property stuff before, or played with libvirt much, I'm not sure how this helps libvirt. I thought the issue here was that migrating from 1.0-qemu-kvm to 2.x OR 1.0-qemu-git to 2.x, libvirt is going to to supply the same command line. As libvirt doesn't know what the sender is (and it's not possible to detect this automatically - at least not without a far more intrusive patch), one has to make a choice at build time as to what 'pc-1.0' represents. This is what patch #2 does. I fully agree it is not pretty. So I am not sure why -machine pc-1.0,qemu-kvm-compatibility=on is any easier for libvirt than -machine pc-1.0-qemu-kvm IE what does using a machine property rather than a machine type buy us? -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Michael, On 4 Aug 2014, at 15:26, Michael S. Tsirkin m...@redhat.com wrote: Unless I'm missing what you are saying? I think you are: check how vmstate_test_use_acpi_pci_hotplug and vmstate_test_no_use_acpi_pci_hotplug are used in vmstate_acpi. I /think/ you are talking about using the VMSTATE_FOO_TEST macros. These are capable of modifying fields within the VMStateDescription of the relevant object. However, the PIIX4 change modifies the minimum_version_id (outside fields); I don't quite see how that would work. Can you help here? The i8254 change modifies a field which is marked with a minimum version to be a field with no versioning; I guess the route there would be a test function that (somehow) accesses the version of the inbound migration inside it, does the comparison manually, and returns 1 if EITHER the inbound version =3 or the compatibility thing is set. Is that what you meant? I'm rather new to this so you may have to lead me a little - apologies. I was trying to produce code which would be 'obviously correct' in the sense of not breaking the existing pc-1.0 migrations; if playing around with the existing vmstate fields is permissible then clearly I have a few more degrees of freedom. I did try modifying the objects live after the command line has been parsed; this doesn't work because the QOM inheritance memcpy's the structs for classes derived from i8254 etc. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Michael,
On 4 Aug 2014, at 17:22, Michael S. Tsirkin m...@redhat.com wrote:
These are capable of modifying fields within the
VMStateDescription of the relevant object.
However, the PIIX4 change modifies the minimum_version_id
(outside fields); I don't quite see how that would work.
Can you help here?
If you want to support lower version IDs,
you can just decrease minimum_version_id.
field_exists gets the version ID so you can
parse different fields depending on the
version.
The issue is that qemu-kvm 1.0 used version ID 2
but is actually sending a version 3 structure.
I don't think I can just reduce the minimum version
ID. As per the comment in the original patch from
Cole Robinson:
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -289,7 +289,13 @@ static int acpi_load_old(QEMUFile *f, void *opaque, int
version_id)
static const VMStateDescription vmstate_acpi = {
.name = piix4_pm,
.version_id = 3,
-.minimum_version_id = 3,
+/*
+ * qemu-kvm 1.2 uses qemu.git version 3 format, but advertised as 2.
+ * This allows incoming migration from qemu-kvm, but breaks incoming
+ * migration from qemu 1.3.
+ */
+//minimum_version_id = 3,
+.minimum_version_id = 2,
.minimum_version_id_old = 1,
.load_state_old = acpi_load_old,
.post_load = vmstate_acpi_post_load,
An inbound migration from qemu-1.0-git, qemu-1.1 or
qemu-1.2 will have version ID 2 and actually mean version
2; currently (i.e. with minimum_version_id = 3), these
use the minimum_version_id_old field (1) and
acpi_load_old routine.
If I decrease minimum_version_id to 2, as far as I can
tell this will break inbound migration from the 'good'
earlier versions, whilst fixing qemu-1.0-kvm (which uses
version 2 to mean version 3).
So as far as I can tell, the minimum version ID needs
to be dependent upon inbound machine type (or machine
parameters). By the time the command line is parsed,
these structures have already been built. That's why
I took the approach I did, but again I'm new to this
so may be missing something.
Or were you suggesting I introduced a
test_force_use_new_load_vm_state
type field into VMStateDescription so it can dynamically
choose not to use the load_state_old but rather to
use the new method, irrespective of the minimum version
mismatch?
--
Alex Bligh
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 4 Aug 2014, at 17:59, Michael S. Tsirkin m...@redhat.com wrote: I was merely suggesting changing acpi_load_old to detect the new flag and parse the qemu-kvm format. Oh OK - far simpler. If the machine is subsequently migrated to another qemu-2.x device, I take it that will still write out a proper version 3 object? -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 2/2] Add configure option --enable-pc-1-0-qemu-kvm
Add a configure option --enable-pc-1-0-qemu-kvm and the
corresponding --disable-pc-1-0-qemu-kvm, defaulting
to disabled.
Rename machine type pc-1.0 to pc-1.0-qemu-git.
Make pc-1.0 machine type an alias of either pc-1.0-qemu-kvm
or pc-1.0-qemu-git depending on the value of the config
option.
Signed-off-by: Alex Bligh a...@alex.org.uk
---
configure | 12
hw/i386/pc_piix.c |8 +++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index f7685b5..b143302 100755
--- a/configure
+++ b/configure
@@ -335,6 +335,7 @@ libssh2=
vhdx=
quorum=
numa=
+pc_1_0_qemu_kvm=no
# parse CC options first
for opt do
@@ -1125,6 +1126,10 @@ for opt do
;;
--enable-numa) numa=yes
;;
+ --disable-pc-1-0-qemu-kvm) pc_1_0_qemu_kvm=no
+ ;;
+ --enable-pc-1-0-qemu-kvm) pc_1_0_qemu_kvm=yes
+ ;;
*)
echo ERROR: unknown option $opt
echo Try '$0 --help' for more information
@@ -1394,6 +1399,8 @@ Advanced options (experts only):
--enable-quorum enable quorum block filter support
--disable-numa disable libnuma support
--enable-numaenable libnuma support
+ --disable-pc-1-0-qemu-kvm disable pc-1.0 machine type reflecting qemu-kvm
+ --enable-pc-1-0-qemu-kvm enable pc-1.0 machine type reflecting qemu-kvm
NOTE: The object files are built at the place where configure is launched
EOF
@@ -4262,6 +4269,7 @@ echo Quorum$quorum
echo lzo support $lzo
echo snappy support$snappy
echo NUMA host support $numa
+echo pc-1.0 qemu-kvm $pc_1_0_qemu_kvm
if test $sdl_too_old = yes; then
echo - Your SDL version is too old - please upgrade to have SDL support
@@ -5241,6 +5249,10 @@ if test $numa = yes; then
echo CONFIG_NUMA=y $config_host_mak
fi
+if test $pc_1_0_qemu_kvm = yes; then
+ echo CONFIG_PC_1_0_QEMU_KVM=y $config_host_mak
+fi
+
# build tree in object directory in case the source is not in the current
directory
DIRS=tests tests/tcg tests/tcg/cris tests/tcg/lm32 tests/libqos
tests/qapi-schema tests/tcg/xtensa tests/qemu-iotests
DIRS=$DIRS fsdev
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index e400ea6..7a3db34 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -647,7 +647,10 @@ static QEMUMachine pc_machine_v1_1 = {
static QEMUMachine pc_machine_v1_0 = {
PC_I440FX_1_2_MACHINE_OPTIONS,
-.name = pc-1.0,
+.name = pc-1.0-qemu-git,
+#ifndef CONFIG_PC_1_0_QEMU_KVM
+.alias = pc-1.0,
+#endif
.compat_props = (GlobalProperty[]) {
PC_COMPAT_1_0,
{ /* end of list */ }
@@ -666,6 +669,9 @@ static QEMUMachine pc_machine_v1_0 = {
static QEMUMachine pc_machine_v1_0_qemu_kvm = {
PC_I440FX_1_2_MACHINE_OPTIONS,
.name = pc-1.0-qemu-kvm,
+#ifdef CONFIG_PC_1_0_QEMU_KVM
+.alias = pc-1.0,
+#endif
.init = pc_init_pci_1_2_qemu_kvm,
.compat_props = (GlobalProperty[]) {
PC_COMPAT_1_0_QEMU_KVM,
--
1.7.9.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
This patch series adds inbound migrate capability from qemu-kvm version 1.0. The main ideas are those set out in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20 however, rather than patching statically (and breaking inbound migration on existing machine types), I have added a new machine type (pc-1.0-qemu-kvm) without affecting any other machine types. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change). This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained. I developed this on qemu 2.0 but have forward ported it (trivially) to master. My testing has been on a VM live-migrated-to-file from Ubuntu Precise qemu-kvm 1.0. I have given this a moderate degree of testing but it could do with more. Note that certain hardware devices (including QXL) will not migrate properly due to a fundamental difference in their internal state between versions. Also note that (as expected) migratino from qemu-2.x to qemu-1.0 will not work, even if the machine types are the same. Alex Bligh (2): Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm Add configure option --enable-pc-1-0-qemu-kvm configure| 12 hw/acpi/piix4.c | 49 -- hw/i386/pc_piix.c| 39 +++- hw/timer/i8254_common.c | 41 ++ include/hw/acpi/piix4.h |1 + include/hw/timer/i8254.h |2 ++ 6 files changed, 141 insertions(+), 3 deletions(-) -- 1.7.9.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 1/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Add a machine type pc-1.0-qemu-kvm for live migrate compatibility
with qemu-kvm version 1.0.
Signed-off-by: Alex Bligh a...@alex.org.uk
---
hw/acpi/piix4.c | 49 --
hw/i386/pc_piix.c| 31 +
hw/timer/i8254_common.c | 41 ++
include/hw/acpi/piix4.h |1 +
include/hw/timer/i8254.h |2 ++
5 files changed, 122 insertions(+), 2 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index b72b34e..708db79 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -267,8 +267,9 @@ static const VMStateDescription vmstate_memhp_state = {
};
/* qemu-kvm 1.2 uses version 3 but advertised as 2
- * To support incoming qemu-kvm 1.2 migration, change version_id
- * and minimum_version_id to 2 below (which breaks migration from
+ * To support incoming qemu-kvm 1.2 migration, we support
+ * via a command line option a change to minimum_version_id
+ * of 2 in a _compat structure (which breaks migration from
* qemu 1.2).
*
*/
@@ -307,6 +308,34 @@ static const VMStateDescription vmstate_acpi = {
}
};
+static const VMStateDescription vmstate_acpi_compat = {
+.name = piix4_pm,
+.version_id = 3,
+.minimum_version_id = 2,
+.minimum_version_id_old = 1,
+.load_state_old = acpi_load_old,
+.post_load = vmstate_acpi_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.evt.sts, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.evt.en, PIIX4PMState),
+VMSTATE_UINT16(ar.pm1.cnt.cnt, PIIX4PMState),
+VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState),
+VMSTATE_TIMER(ar.tmr.timer, PIIX4PMState),
+VMSTATE_INT64(ar.tmr.overflow_time, PIIX4PMState),
+VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe, ACPIGPE),
+VMSTATE_STRUCT_TEST(
+acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT],
+PIIX4PMState,
+vmstate_test_no_use_acpi_pci_hotplug,
+2, vmstate_pci_status,
+struct AcpiPciHpPciStatus),
+VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState,
+vmstate_test_use_acpi_pci_hotplug),
+VMSTATE_END_OF_LIST()
+}
+};
+
static void piix4_reset(void *opaque)
{
PIIX4PMState *s = opaque;
@@ -619,6 +648,22 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
adevc-ospm_status = piix4_ospm_status;
}
+void piix4_pm_class_fix_compat(void)
+{
+GSList *el, *devices = object_class_get_list(TYPE_DEVICE, false);
+/*
+ * Change the vmstate field in this class and any derived classes
+ * if not overriden. As no other classes should be using this
+ * vmstate, we can simply iterate the class list
+ */
+for (el = devices; el; el = el-next) {
+DeviceClass *dc = el-data;
+if (dc-vmsd == vmstate_acpi) {
+dc-vmsd = vmstate_acpi_compat;
+}
+}
+}
+
static const TypeInfo piix4_pm_info = {
.name = TYPE_PIIX4_PM,
.parent= TYPE_PCI_DEVICE,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7081c08..e400ea6 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -49,6 +49,8 @@
#include hw/acpi/acpi.h
#include cpu.h
#include qemu/error-report.h
+#include hw/acpi/piix4.h
+#include hw/timer/i8254.h
#ifdef CONFIG_XEN
# include xen/hvm/hvm_info_table.h
#endif
@@ -386,6 +388,15 @@ static void pc_init_pci_1_2(MachineState *machine)
pc_init_pci(machine);
}
+/* PC machine init function for qemu-kvm 1.0 */
+static void pc_init_pci_1_2_qemu_kvm(MachineState *machine)
+{
+piix4_pm_class_fix_compat();
+pit_common_class_fix_compat();
+pc_compat_1_2(machine);
+pc_init_pci(machine);
+}
+
/* PC init function for pc-0.10 to pc-0.13 */
static void pc_init_pci_no_kvmclock(MachineState *machine)
{
@@ -644,6 +655,25 @@ static QEMUMachine pc_machine_v1_0 = {
.hw_version = 1.0,
};
+#define PC_COMPAT_1_0_QEMU_KVM \
+PC_COMPAT_1_0,\
+{\
+.driver = cirrus-vga,\
+.property = vgamem_mb,\
+.value= stringify(16),\
+}
+
+static QEMUMachine pc_machine_v1_0_qemu_kvm = {
+PC_I440FX_1_2_MACHINE_OPTIONS,
+.name = pc-1.0-qemu-kvm,
+.init = pc_init_pci_1_2_qemu_kvm,
+.compat_props = (GlobalProperty[]) {
+PC_COMPAT_1_0_QEMU_KVM,
+{ /* end of list */ }
+},
+.hw_version = 1.0,
+};
+
#define PC_COMPAT_0_15 \
PC_COMPAT_1_0
@@ -886,6 +916,7 @@ static void pc_machine_init(void)
qemu_register_pc_machine(pc_machine_v1_2);
qemu_register_pc_machine(pc_machine_v1_1);
qemu_register_pc_machine(pc_machine_v1_0);
+qemu_register_pc_machine(pc_machine_v1_0_qemu_kvm);
qemu_register_pc_machine(pc_machine_v0_15);
qemu_register_pc_machine(pc_machine_v0_14);
qemu_register_pc_machine
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Serge, I don't think that is in any way a problem. Is migrating to older versions ever actually expected to work? In either case I don't think for this particular case it's a problem. Good; no; and good - respectively. (The how to handle this in libvirt question is more interesting) I've been giving this some thought. However rococo we make this, I think the caller is often going to need to modify the command line anyway, i.e. is going to need to be aware of the migration problem. For instance, taking Ubuntu as an example, 12.04 shipped with qemu-kvm-1.0, and a pxe-virtio.rom of just under 64k, giving a 64k ROM slot. 14.04 ships with qemu-2.0 and a pxe-virtio.rom of over 80k, giving a 128k ROM slot. So however we fix the machine types, when migrating in a 12.04 initiated VM, qemu will need -global virtio-net-pci.romfile=/path/to/pxe-virtio.rom.12.04 on the command line (or, if you don't much care about PXE working on a soft reboot, a blank file of the same size), whereas when migrating in a 14.04 initiated VM, that must not be on the command line. Fixing this properly would entail requiring that the ROMs are (effectively) distributed with qemu or at least that all ROM sizes become part of the machine type standard. This would have the advantage that loading a larger ROM than the machine type specifies would fail unless the ROM size was explicitly configured on the command line. But this is a subject wider than this patch. So the long and the short of it is that libvirt (sadly) like anything else starting qemu machines needs to know a bit about different versions of qemu, and be able to replace a machine type option with a machine type option and more on the command line. My previous suggestion doesn't help much because qemu will still need to be passed something on the command line. I think the best way to go with this patch would be something like: * Add pc-1.0-qemu-kvm as a machine type (done) * Rename pc-1.0 to pc-1.0-qemu-git * Add an alias for pc-1.0 to either pc-1.0-qemu-git or pc-1.0-qemu-kvm, configurable at build time with a ./configure option. The distro can then set this appropriately. This would default to pc-1.0-qemu-git (i.e. the current behaviour). On distros that only every used one of the above, ./configure will sort things out, +/- self-inflicted injuries relating to ROM size changes. If life is more complicated, libvirt (and other callers) will need to be aware. pc-1.0-qemu-git and pc-1.0-qemu-kvm can be used to unambiguously mean the relevant machine type, which will fix things going forward for that machine type. WDYT? -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 29 Jul 2014, at 14:03, Serge E. Hallyn se...@hallyn.com wrote: That sounds good. And from there I think the thing to do will be to introduce a transient alternate package that has the pc-1.0 alias pointing ot pc-1.0-qemu-kvm and depends on the legacy pxe rom. And maybe users can then choose that package for migration purposes if needed, without having to make any changes to libvirt at all, while others are completely unaffected. OK, I'll do that the next time I roll the patch. I'd like to hear from some others first and am mindful of Paolo's comment re waiting for the release to ship. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 29 Jul 2014, at 14:21, Paolo Bonzini pbonz...@redhat.com wrote: If you can make the pxe-virtio.rom file 64k or less, then that would be a good idea for 14.04 in general. Newer machine types use efi-virtio.rom, so you won't break -M pc migration. Without further, won't that break migration from 14.04 *with* the big ROM? -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 29 Jul 2014, at 14:35, Paolo Bonzini pbonz...@redhat.com wrote: I'm not sure either. You could simply package the 12.04 ipxe ROMs into 14.04, and add a note about getting the sources for GPL friendliness. This would be my preference (or in Ubuntu's case, add it to the ipxe-qemu package) but I think it should only be used when the legacy machine type is used or it will break inbound migrations from other 14.04 machines started with 128k ROMs (AIUI). -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 29 Jul 2014, at 14:42, Paolo Bonzini pbonz...@redhat.com wrote: Il 29/07/2014 15:39, Alex Bligh ha scritto: I'm not sure either. You could simply package the 12.04 ipxe ROMs into 14.04, and add a note about getting the sources for GPL friendliness. This would be my preference (or in Ubuntu's case, add it to the ipxe-qemu package) but I think it should only be used when the legacy machine type is used or it will break inbound migrations from other 14.04 machines started with 128k ROMs (AIUI). -M pc and its alias -M pc-i440fx-2.0 doesn't use pxe-virtio.rom at all (at least upstream). Really? How does it pxeboot on virtio then (it definitely does pxeboot on virtio)? Does Ubuntu 14.04 have efi-virtio.rom? Yes. After 2 layers of symlinks you get to. ubuntu@trustytest:~$ ls -la /usr/lib/ipxe/qemu/efi-virtio.rom -rw-r--r-- 1 root root 220672 Jan 6 2014 /usr/lib/ipxe/qemu/efi-virtio.rom It would break -M pc-1.0 started on older 14.04, but I think that's acceptable. I was more worried about any previous versions of Ubuntu (newer than 12.04) which might also be using the larger rom size. But then I haven't investigated at what stage the rom size grew. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 29 Jul 2014, at 15:00, Paolo Bonzini pbonz...@redhat.com wrote: efi-virtio.rom contains both BIOS and UEFI ROMs. You learn a new thing every day. You're right, but in Serge's shoes I wouldn't bother about anything except LTS. Certainly this would be the most convenient path for me (with my 'LTS user' hat on), i.e. make it 'just work' out the box. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
On 22 Jul 2014, at 19:43, Alex Bligh a...@alex.org.uk wrote: Testing has been light to date (i.e. can I migrate it inbound with -S without anything complaining). I've given this quite a bit more testing today. It works fine qemu-kvm 1.0 - qemu-2.0+patch (cirrus vga) It works fine qemu-2.0+patch - qemu-2.0+patch (cirrus vga) It doesn't (yet) work qemu-2.0+patch - qemu-kvm 1.0 (cirrus vga). The reason for this is (at least) that I need to emulate the broken versioning of the mc146818rtc timer section, as writing it correctly confuses qemu-kvm 1.0. Therefore please don't bother testing migration back to 1.0 yet. -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Andreas, On 27 Jul 2014, at 15:10, Andreas Färber afaer...@suse.de wrote: Hi Alex, + quintela, mst, libvirt Thanks for your comments! This sounds like a really cool feature that SUSE would probably be interested in extending back to 0.14 and 0.15, but I see a fundamental flaw: libvirt on those old source systems does not know it should use a different machine name on the destination side and would still use pc-1.0, wouldn't it? After all, it needs to be able to migrate to other old qemu-kvm machines, so it can't just be updated to use the new name. Right. I'm not using libvirt but face a similar problem. The destination libvirt (or equivalent) now has two 'pc-1.0' machine types. One (allegedly) use by qemu-git 1.0, and one used by qemu-kvm 1.0. The name 'pc-1.0' needs to refer to exactly one of these (obviously), and it currently refers to qemu-git 1.0, so I've left it that way. In a distribution environment where qemu-1.0 was never used, one might want to make my new machine type called 'pc-1.0' and the existing qemu.git pc-1.0 called 'pc-1.0-qemu-git' or similar. Why don't I just change it? Well, imagine someone running Ubuntu 13.04 (say) which shipped with an early post merge qemu made a machine with machine type pc-1.0. Despite the fact that Ubuntu 12.04 was shipped with qemu-kvm (and hence -m pc-1.0 there meant qemu-kvm's pc-1.0), on 13.04, this would mean qemu-git's pc-1.0, and changing the name would break the migration of an Ubuntu 13.04 pc-1.0 machine, whilst fixing migration of a 12.04 pc-1.0 machine. Let no one say this isn't a mess. So, I'm expect whatever generates the qemu command line to know (from the other end) whether to use the different version. Perhaps a slightly nicer fix, if somewhat rococo, would be: * Use pc-1.0-qemu-kvm as one machine name * Use pc-1.0-qemu-git as another machine name * Make pc-1.0 an alias of either one or the other, configurable at the command line, and subject to a build-time default. This would let distributions / users simply decide which kind of pc-1.0 migration they'd like by working by default, and which they'd like broken; the broken one is a second class citizen which can only handle migration by changing the qemu command line appropriately. This would perhaps make things more transparent by default. BTW I would agree this is a significant issue, having spent quite a lot of today playing with stuff that (mis)parses qemu -version Also BTW, I did wonder whether I could autodetect this from the stream. However, as it has to be read serially, by the time you know it's wrong, you are too late AFAICT. Useful suggestion in case of future accidental breakage: put the qemu version in a section right up top. Minor bikeshedding: I would ask to keep the package name in front of the machine version, e.g. qemu-kvm-pc-1.0. Or just kvm-pc-1.0 since this is a QEMU parameter anyway. Obviously not a matter of great import, but per the list below, the standard appears to be 'pc-(arch)?-version' and I'd taken this as a subversion. # qemu-system-x86_64 -machine '?' Supported machines are: pc-0.13 Standard PC (i440FX + PIIX, 1996) pc-i440fx-2.0Standard PC (i440FX + PIIX, 1996) pc-1.0 Standard PC (i440FX + PIIX, 1996) pc-q35-1.7 Standard PC (Q35 + ICH9, 2009) pc-1.1 Standard PC (i440FX + PIIX, 1996) q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.0) pc-q35-2.0 Standard PC (Q35 + ICH9, 2009) pc-i440fx-1.4Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.5Standard PC (i440FX + PIIX, 1996) pc-0.14 Standard PC (i440FX + PIIX, 1996) pc-0.15 Standard PC (i440FX + PIIX, 1996) xenfvXen Fully-virtualized PC pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) isapcISA-only PC pc-0.10 Standard PC (i440FX + PIIX, 1996) pc Ubuntu 14.04 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-trusty) pc-i440fx-trusty Ubuntu 14.04 PC (i440FX + PIIX, 1996) (default) pc-1.2 Standard PC (i440FX + PIIX, 1996) pc-0.11 Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.7Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.6Standard PC (i440FX + PIIX, 1996) none empty machine xenpvXen Para-virtualized PC pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) pc-1.0-qemu-kvm Standard PC (i440FX + PIIX, 1996) pc-q35-1.6 Standard PC (Q35 + ICH9, 2009) pc-0.12 Standard PC (i440FX + PIIX, 1996) pc-1.3 Standard PC (i440FX + PIIX, 1996) -- Alex Bligh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
