Re: [Qemu-devel] live migration + licensing issue.
Yeah, but I think if we have to take advantage of live vertical scaling (memory hotplug, memory hotunplug, cpu hotplug) then we need to upgrade to pc model 1.2. pc model 1.0 will be incompatible with qemu 2.0 wrt. LVS feature as the bus architecture and the way how dimms are handled has changed from pc model 1.0 in qemu 1.0 to pc model 2.0 (pc-i440fx-2.1) to qemu 2.0. Yeah, true, if we have to avoid the licensing issue then we have to use same PC model. Anshul Makkar On Fri, Jul 11, 2014 at 1:19 AM, Eric Blake ebl...@redhat.com wrote: On 07/08/2014 03:10 PM, Anshul Makkar wrote: Hi, Yeah, I am aware of this option. But the point where I am concerned is that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows will see this as change in hardware and complain about the license. That's by design. If you were running under qemu 1.0 with pc-model 1.0, then when you upgrade to qemu 2.0, you must STILL use pc-model 1.0 (and not pc-1.2) if you want your guest to see the same hardware as what the older qemu was providing, and therefore avoid a relicensing issue. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] live migration + licensing issue.
Hi Andreas, the point is that the machine version on the destination side needs to match the source side. I hope this is just to avoid the licensing issue. Else, in all other circumstance, we can specify different pc models while migrating from source to destination. Anshul Makkar On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber afaer...@suse.de wrote: Am 09.07.2014 13:09, schrieb Anshul Makkar: Thanks. I got the point. And for the record, the point is that the machine version on the destination side needs to match the source side. So, if the default or pc alias is used in 1.0, which resolves to pc-1.0, then it needs to be pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used then that exact machine must be used on the destination as well. Andreas On Wed, Jul 9, 2014 at 9:36 AM, Markus Armbruster arm...@redhat.com wrote: Anshul Makkar anshul.mak...@profitbricks.com writes: Hi, Yeah, I am aware of this option. But the point where I am concerned is that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows will see this as change in hardware and complain about the license. Works as designed. Sorry, if my understanding is wrong here or i am missing something. Changing the machine type is the virtual equivalent of replacing the motherboard. -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] live migration + licensing issue.
Il 11/07/2014 12:14, Anshul Makkar ha scritto: Hi Andreas, the point is that the machine version on the destination side needs to match the source side. I hope this is just to avoid the licensing issue. Else, in all other circumstance, we can specify different pc models while migrating from source to destination. No, it is always necessary. Think of it like this: you hibernate your workstation, change the motherboard and turn it on. What chances would it have to work? Of course changes in the machine types from one version to the next are _usually_ minor, but sometimes they can completely break the software. For example we've had a couple changes to the memory map over the years. Paolo
Re: [Qemu-devel] live migration + licensing issue.
[Top-quote moved to its rightful place; please do not top quote on technical lists] Anshul Makkar anshul.mak...@profitbricks.com writes: On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber afaer...@suse.de wrote: Am 09.07.2014 13:09, schrieb Anshul Makkar: Thanks. I got the point. And for the record, the point is that the machine version on the destination side needs to match the source side. So, if the default or pc alias is used in 1.0, which resolves to pc-1.0, then it needs to be pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used then that exact machine must be used on the destination as well. Hi Andreas, the point is that the machine version on the destination side needs to match the source side. I hope this is just to avoid the licensing issue. Else, in all other circumstance, we can specify different pc models while migrating from source to destination. You certainly can specify whatever machine type you want, but if you specify different machine types on source and target of a migration, all bets are off. It could succeed if the stars align the right way. It could break obviously and immediately, leaving your machine running on the source. It could migrate your machine to the destination successfully, then blow up there right away, or some time later, taking down your machine. It could migrate successfully, but silently corrupt data. Regardless of how it breaks, you get to keep the pieces.
Re: [Qemu-devel] live migration + licensing issue.
On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster arm...@redhat.com wrote: [Top-quote moved to its rightful place; please do not top quote on technical lists] Anshul Makkar anshul.mak...@profitbricks.com writes: On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber afaer...@suse.de wrote: Am 09.07.2014 13:09, schrieb Anshul Makkar: Thanks. I got the point. And for the record, the point is that the machine version on the destination side needs to match the source side. So, if the default or pc alias is used in 1.0, which resolves to pc-1.0, then it needs to be pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used then that exact machine must be used on the destination as well. Hi Andreas, the point is that the machine version on the destination side needs to match the source side. I hope this is just to avoid the licensing issue. Else, in all other circumstance, we can specify different pc models while migrating from source to destination. You certainly can specify whatever machine type you want, but if you specify different machine types on source and target of a migration, all bets are off. It could succeed if the stars align the right way. It could break obviously and immediately, leaving your machine running on the source. It could migrate your machine to the destination successfully, then blow up there right away, or some time later, taking down your machine. It could migrate successfully, but silently corrupt data. Regardless of how it breaks, you get to keep the pieces. What you're saying is that there's no way to migrate (live or offline) from Qemu 1.0/1.2 to 2.0 in a *safe way* whatever OS I'm running on it? -- Eduardo Otubo ProfitBricks
Re: [Qemu-devel] live migration + licensing issue.
On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster arm...@redhat.com wrote: ly, leaving your machine running on the source. Hmm. Got the point. But as I mentioned above if we have to use live vertical scaling on qemu 2.0, then pc-model 1.0 won't help (as the dimm handling and bus handling has changed in pc-model 2.0 and qemu2.0 uses this changed model). QEMU 2.0 will only go with pc-model 2.0 wrt to LVS. Am I correct here ? Does the only solution is to shutdown the VM, upgrade qemu and then start with new QEMU and new PC model . Anshul Makkar
Re: [Qemu-devel] live migration + licensing issue.
Eduardo Otubo eduardo.ot...@profitbricks.com writes: On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster arm...@redhat.com wrote: [Top-quote moved to its rightful place; please do not top quote on technical lists] Anshul Makkar anshul.mak...@profitbricks.com writes: On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber afaer...@suse.de wrote: Am 09.07.2014 13:09, schrieb Anshul Makkar: Thanks. I got the point. And for the record, the point is that the machine version on the destination side needs to match the source side. So, if the default or pc alias is used in 1.0, which resolves to pc-1.0, then it needs to be pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used then that exact machine must be used on the destination as well. Hi Andreas, the point is that the machine version on the destination side needs to match the source side. I hope this is just to avoid the licensing issue. Else, in all other circumstance, we can specify different pc models while migrating from source to destination. You certainly can specify whatever machine type you want, but if you specify different machine types on source and target of a migration, all bets are off. It could succeed if the stars align the right way. It could break obviously and immediately, leaving your machine running on the source. It could migrate your machine to the destination successfully, then blow up there right away, or some time later, taking down your machine. It could migrate successfully, but silently corrupt data. Regardless of how it breaks, you get to keep the pieces. What you're saying is that there's no way to migrate (live or offline) from Qemu 1.0/1.2 to 2.0 in a *safe way* whatever OS I'm running on it? No, what I'm saying is you need to use the same machine type on source on destination. If you don't specify one, you get the default. If you run different versions of QEMU on source and destination, their default machine type may differ. In that case, find the default machine type on the source (-M help shows it), then start QEMU on the destination with that machine type.
Re: [Qemu-devel] live migration + licensing issue.
Anshul Makkar anshul.mak...@profitbricks.com writes: On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster arm...@redhat.com wrote: ly, leaving your machine running on the source. Hmm. Got the point. But as I mentioned above if we have to use live vertical scaling on qemu 2.0, then pc-model 1.0 won't help (as the dimm handling and bus handling has changed in pc-model 2.0 and qemu2.0 uses this changed model). QEMU 2.0 will only go with pc-model 2.0 wrt to LVS. Am I correct here ? Does the only solution is to shutdown the VM, upgrade qemu and then start with new QEMU and new PC model . Assuming you actually value your data: yes.
Re: [Qemu-devel] live migration + licensing issue.
On Fri, Jul 11, 2014 at 2:19 PM, Markus Armbruster arm...@redhat.com wrote: Eduardo Otubo eduardo.ot...@profitbricks.com writes: On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster arm...@redhat.com wrote: [Top-quote moved to its rightful place; please do not top quote on technical lists] Anshul Makkar anshul.mak...@profitbricks.com writes: On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber afaer...@suse.de wrote: Am 09.07.2014 13:09, schrieb Anshul Makkar: Thanks. I got the point. And for the record, the point is that the machine version on the destination side needs to match the source side. So, if the default or pc alias is used in 1.0, which resolves to pc-1.0, then it needs to be pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used then that exact machine must be used on the destination as well. Hi Andreas, the point is that the machine version on the destination side needs to match the source side. I hope this is just to avoid the licensing issue. Else, in all other circumstance, we can specify different pc models while migrating from source to destination. You certainly can specify whatever machine type you want, but if you specify different machine types on source and target of a migration, all bets are off. It could succeed if the stars align the right way. It could break obviously and immediately, leaving your machine running on the source. It could migrate your machine to the destination successfully, then blow up there right away, or some time later, taking down your machine. It could migrate successfully, but silently corrupt data. Regardless of how it breaks, you get to keep the pieces. What you're saying is that there's no way to migrate (live or offline) from Qemu 1.0/1.2 to 2.0 in a *safe way* whatever OS I'm running on it? No, what I'm saying is you need to use the same machine type on source on destination. If you don't specify one, you get the default. If you run different versions of QEMU on source and destination, their default machine type may differ. In that case, find the default machine type on the source (-M help shows it), then start QEMU on the destination with that machine type. Let me rephrase that: What you're saying is that there's no way to migrate (live or offline) from pc-model 1.0/1.2 to pc-model 2.0 in a *safe way* whatever OS I'm running on it? As Anshul said, we want to migrate clients of our data center from Qemu 1.0/1.2 to Qemu 2.0 to take advantage of live vertical scaling -- which implies in changing pc-model to 2.0. At least offline migration you think it could be OK? Regards, -- Eduardo Otubo ProfitBricks
Re: [Qemu-devel] live migration + licensing issue.
Eduardo Otubo eduardo.ot...@profitbricks.com writes: On Fri, Jul 11, 2014 at 2:19 PM, Markus Armbruster arm...@redhat.com wrote: Eduardo Otubo eduardo.ot...@profitbricks.com writes: On Fri, Jul 11, 2014 at 1:12 PM, Markus Armbruster arm...@redhat.com wrote: [Top-quote moved to its rightful place; please do not top quote on technical lists] Anshul Makkar anshul.mak...@profitbricks.com writes: On Wed, Jul 9, 2014 at 6:25 PM, Andreas Färber afaer...@suse.de wrote: Am 09.07.2014 13:09, schrieb Anshul Makkar: Thanks. I got the point. And for the record, the point is that the machine version on the destination side needs to match the source side. So, if the default or pc alias is used in 1.0, which resolves to pc-1.0, then it needs to be pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used then that exact machine must be used on the destination as well. Hi Andreas, the point is that the machine version on the destination side needs to match the source side. I hope this is just to avoid the licensing issue. Else, in all other circumstance, we can specify different pc models while migrating from source to destination. You certainly can specify whatever machine type you want, but if you specify different machine types on source and target of a migration, all bets are off. It could succeed if the stars align the right way. It could break obviously and immediately, leaving your machine running on the source. It could migrate your machine to the destination successfully, then blow up there right away, or some time later, taking down your machine. It could migrate successfully, but silently corrupt data. Regardless of how it breaks, you get to keep the pieces. What you're saying is that there's no way to migrate (live or offline) from Qemu 1.0/1.2 to 2.0 in a *safe way* whatever OS I'm running on it? No, what I'm saying is you need to use the same machine type on source on destination. If you don't specify one, you get the default. If you run different versions of QEMU on source and destination, their default machine type may differ. In that case, find the default machine type on the source (-M help shows it), then start QEMU on the destination with that machine type. Let me rephrase that: What you're saying is that there's no way to migrate (live or offline) from pc-model 1.0/1.2 to pc-model 2.0 in a *safe way* whatever OS I'm running on it? Yes, where migrate offline is something like savevm / loadvm. The only safe way to upgrade to a newer machine type is shutdown restart with new type. As Anshul said, we want to migrate clients of our data center from Qemu 1.0/1.2 to Qemu 2.0 to take advantage of live vertical scaling -- which implies in changing pc-model to 2.0. At least offline migration you think it could be OK? Changing the machine type is the virtual equivalent of replacing the motherboard. No safe way to pull that off without a reboot, I'm afraid.
Re: [Qemu-devel] live migration + licensing issue.
On 07/08/2014 03:10 PM, Anshul Makkar wrote: Hi, Yeah, I am aware of this option. But the point where I am concerned is that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows will see this as change in hardware and complain about the license. That's by design. If you were running under qemu 1.0 with pc-model 1.0, then when you upgrade to qemu 2.0, you must STILL use pc-model 1.0 (and not pc-1.2) if you want your guest to see the same hardware as what the older qemu was providing, and therefore avoid a relicensing issue. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] live migration + licensing issue.
Anshul Makkar anshul.mak...@profitbricks.com writes: Hi, Yeah, I am aware of this option. But the point where I am concerned is that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows will see this as change in hardware and complain about the license. Works as designed. Sorry, if my understanding is wrong here or i am missing something. Changing the machine type is the virtual equivalent of replacing the motherboard.
Re: [Qemu-devel] live migration + licensing issue.
Am 09.07.2014 13:09, schrieb Anshul Makkar: Thanks. I got the point. And for the record, the point is that the machine version on the destination side needs to match the source side. So, if the default or pc alias is used in 1.0, which resolves to pc-1.0, then it needs to be pc-1.0, not pc-1.2. If an explicit machine name such as pc-0.15 was used then that exact machine must be used on the destination as well. Andreas On Wed, Jul 9, 2014 at 9:36 AM, Markus Armbruster arm...@redhat.com wrote: Anshul Makkar anshul.mak...@profitbricks.com writes: Hi, Yeah, I am aware of this option. But the point where I am concerned is that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows will see this as change in hardware and complain about the license. Works as designed. Sorry, if my understanding is wrong here or i am missing something. Changing the machine type is the virtual equivalent of replacing the motherboard. -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] live migration + licensing issue.
Hi, AFAIK this change has occured between the switch from qemu-kvm to qemu. (qemu 1.3 if I remember) Don't have see license problem after other upgrade (qemu 1.3-1.4-1.5 ...) But It's always better to use volume licenses, no more problem in case of virtual hardware change. - Mail original - De: Anshul Makkar anshul.mak...@profitbricks.com À: Markus Armbruster arm...@redhat.com Cc: Andreas Färber afaer...@suse.de, qemu-devel qemu-devel@nongnu.org Envoyé: Mercredi 9 Juillet 2014 13:09:47 Objet: Re: [Qemu-devel] live migration + licensing issue. Thanks. I got the point. Anshul Makkar On Wed, Jul 9, 2014 at 9:36 AM, Markus Armbruster arm...@redhat.com wrote: Anshul Makkar anshul.mak...@profitbricks.com writes: Hi, Yeah, I am aware of this option. But the point where I am concerned is that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows will see this as change in hardware and complain about the license. Works as designed. Sorry, if my understanding is wrong here or i am missing something. Changing the machine type is the virtual equivalent of replacing the motherboard.
Re: [Qemu-devel] live migration + licensing issue.
Hi, Yeah, I am aware of this option. But the point where I am concerned is that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows will see this as change in hardware and complain about the license. Sorry, if my understanding is wrong here or i am missing something. Anshul Makkar On Tue, Jul 8, 2014 at 6:25 PM, Andreas Färber afaer...@suse.de wrote: Hi, Am 08.07.2014 17:24, schrieb Anshul Makkar: In our data center we are using qemu 1.0/ 1.2 and we need to do a live migration to qemu 2.0. One of the main hindrance that we are facing is that QEMU 1.0 uses old PC model so if a user using Windows on the VM running on QEMU 1.0 does a live migrate to QEMU 2.0 , he will see a licensing issue as after migration Windows will see a new hardware beneath it. Any suggestion as to how to overcome this problem. Please check the documentation. There's the -machine option with parameters such as pc-1.0 and pc-1.2 for that exact purpose. libvirt should supply the corresponding option automatically. More difficult is if you're trying to migrate from qemu-kvm to qemu - code changes to your copy of 2.0 will be necessary then. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] live migration + licensing issue.
Thanks. I got the point. Anshul Makkar On Wed, Jul 9, 2014 at 9:36 AM, Markus Armbruster arm...@redhat.com wrote: Anshul Makkar anshul.mak...@profitbricks.com writes: Hi, Yeah, I am aware of this option. But the point where I am concerned is that if Windows VM is running in QEMU 1.0 with pc-model 1.0 and then I upgrade the QEMU to 2.0 and I specify machine as pc-1.2, then Windows will see this as change in hardware and complain about the license. Works as designed. Sorry, if my understanding is wrong here or i am missing something. Changing the machine type is the virtual equivalent of replacing the motherboard.
Re: [Qemu-devel] live migration + licensing issue.
Hi, Am 08.07.2014 17:24, schrieb Anshul Makkar: In our data center we are using qemu 1.0/ 1.2 and we need to do a live migration to qemu 2.0. One of the main hindrance that we are facing is that QEMU 1.0 uses old PC model so if a user using Windows on the VM running on QEMU 1.0 does a live migrate to QEMU 2.0 , he will see a licensing issue as after migration Windows will see a new hardware beneath it. Any suggestion as to how to overcome this problem. Please check the documentation. There's the -machine option with parameters such as pc-1.0 and pc-1.2 for that exact purpose. libvirt should supply the corresponding option automatically. More difficult is if you're trying to migrate from qemu-kvm to qemu - code changes to your copy of 2.0 will be necessary then. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
