Hi,
I was trying to migrate a VM(CentOS7) which started with 4G memory and hot
plugged 5 memslots with 1G each. So the VM has total of 9G memory and
trying to migrate fails in vhost_dev_init() on destination host
if (used_memslots >
hdev->vhost_ops->vhost_backend_memslots_limit(hdev)) {
Hi,
I was trying to migrate a VM(CentOS7) which started with 4G memory and hot
plugged 5 memslots with 1G each. So the VM has total of 9G memory and
trying to migrate fails in vhost_dev_init() on destination host
if (used_memslots >
hdev->vhost_ops->vhost_backend_memslots_limit(hdev)) {
On Fri, Jan 18, 2019 at 10:25 AM Paolo Bonzini wrote:
> On 18/01/19 14:41, Mark Mielke wrote:
> > It is useful to understand the risk. However, this is the same risk we
> > have been successfully living with for several years now, and it seems
> > abrupt to declare 3.1 and 3.2 as the Qemu version
On 2019/1/18 14:18, Christian Ehrhardt wrote:
On Fri, Jan 18, 2019 at 7:33 AM Mark Mielke wrote:
Thank you for the work on nested virtualization. Having had live migrations
fail in the past when nested virtualization has been active, it is great to
see that clever people have been working on t
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 18/01/19 14:41, Mark Mielke wrote:
> > It is useful to understand the risk. However, this is the same risk we
> > have been successfully living with for several years now, and it seems
> > abrupt to declare 3.1 and 3.2 as the Qemu version beyond whi
On 18/01/19 14:41, Mark Mielke wrote:
> It is useful to understand the risk. However, this is the same risk we
> have been successfully living with for several years now, and it seems
> abrupt to declare 3.1 and 3.2 as the Qemu version beyond which migration
> requires a whole cluster restart wheth
On Fri, Jan 18, 2019 at 09:09:31AM -0500, Mark Mielke wrote:
> On Fri, Jan 18, 2019 at 8:44 AM Daniel P. Berrangé
> wrote:
>
> > On Fri, Jan 18, 2019 at 01:57:31PM +0100, Paolo Bonzini wrote:
> > > On 18/01/19 11:21, Daniel P. Berrangé wrote:
> > > > Yes, this is exactly why I said we should make
On Fri, Jan 18, 2019 at 8:44 AM Daniel P. Berrangé
wrote:
> On Fri, Jan 18, 2019 at 01:57:31PM +0100, Paolo Bonzini wrote:
> > On 18/01/19 11:21, Daniel P. Berrangé wrote:
> > > Yes, this is exactly why I said we should make the migration blocker
> > > be conditional on any L2 guest having been s
On Fri, Jan 18, 2019 at 01:57:31PM +0100, Paolo Bonzini wrote:
> On 18/01/19 11:21, Daniel P. Berrangé wrote:
> > On Fri, Jan 18, 2019 at 10:16:34AM +, Dr. David Alan Gilbert wrote:
> >> * Paolo Bonzini (pbonz...@redhat.com) wrote:
> >>> On 18/01/19 11:02, Dr. David Alan Gilbert wrote:
> >
On Fri, Jan 18, 2019 at 7:57 AM Paolo Bonzini wrote:
> On 18/01/19 11:21, Daniel P. Berrangé wrote:
> > On Fri, Jan 18, 2019 at 10:16:34AM +, Dr. David Alan Gilbert wrote:
> >> * Paolo Bonzini (pbonz...@redhat.com) wrote:
> >>> The solution is to restart the VM using "-cpu host,-vmx".
> >> Th
On 18/01/19 11:21, Daniel P. Berrangé wrote:
> On Fri, Jan 18, 2019 at 10:16:34AM +, Dr. David Alan Gilbert wrote:
>> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>>> On 18/01/19 11:02, Dr. David Alan Gilbert wrote:
>
> It fails if the flag is set, rather than if any nested virtualizati
On Fri, Jan 18, 2019 at 10:16:34AM +, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
> > On 18/01/19 11:02, Dr. David Alan Gilbert wrote:
> > >>
> > >> It fails if the flag is set, rather than if any nested virtualization has
> > >> been used before.
> > >>
> > >>
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 18/01/19 11:02, Dr. David Alan Gilbert wrote:
> >>
> >> It fails if the flag is set, rather than if any nested virtualization has
> >> been used before.
> >>
> >> I'm concerned I will end up with a requirement for *all* guests to be
> >> restarted i
On 18/01/19 11:02, Dr. David Alan Gilbert wrote:
>>
>> It fails if the flag is set, rather than if any nested virtualization has
>> been used before.
>>
>> I'm concerned I will end up with a requirement for *all* guests to be
>> restarted in order to migrate them to the new hosts, rather than just
* Mark Mielke (mark.mie...@gmail.com) wrote:
> Thank you for the work on nested virtualization. Having had live migrations
> fail in the past when nested virtualization has been active, it is great to
> see that clever people have been working on this problem!
>
> My question is about whether a mi
On Fri, Jan 18, 2019 at 7:33 AM Mark Mielke wrote:
>
> Thank you for the work on nested virtualization. Having had live migrations
> fail in the past when nested virtualization has been active, it is great to
> see that clever people have been working on this problem!
>
> My question is about whet
Thank you for the work on nested virtualization. Having had live migrations
fail in the past when nested virtualization has been active, it is great to
see that clever people have been working on this problem!
My question is about whether a migration path has been considered to allow
live migratio
* ? ? (zach_tur...@outlook.com) wrote:
>
> Hello, I have a question I would like to ask.
> If I add the -incoming parameter when starting the qemu virtual machine, the
> virtual machine will block all the time, waiting for the migration connection
> request to arrive.
> I want to modify the time
Hello, I have a question I would like to ask.
If I add the -incoming parameter when starting the qemu virtual machine, the
virtual machine will block all the time, waiting for the migration connection
request to arrive.
I want to modify the time of this blocking wait, how should I modify the so
Live Migration between machines with different processorIds
VM Migration between machines with different processorId values throws an error
in qemu/kvm. Though this check is appropriate but is overkill in cases where the
two machines are of same SoC/arch family and have exactly similar core/gic bu
On Tue, 10 Jan 2017 14:28:19 +0800
Bob Chen wrote:
> Answer my own question:
>
> The corresponding cmd-line parameter for memory hot-add by QEMU monitor is,
> -object memory-backend-ram,id=mem0,size=1024M -device
> pc-dimm,id=dimm0,memdev=mem0
pc-dimm should have additional property
-device pc
Answer my own question:
The corresponding cmd-line parameter for memory hot-add by QEMU monitor is,
-object memory-backend-ram,id=mem0,size=1024M -device
pc-dimm,id=dimm0,memdev=mem0
2017-01-05 18:12 GMT+08:00 Daniel P. Berrange :
> On Thu, Jan 05, 2017 at 04:27:26PM +0800, Bob Chen wrote:
> > H
On Thu, Jan 05, 2017 at 04:27:26PM +0800, Bob Chen wrote:
> Hi,
>
> According to the docs, the destination Qemu must have the exactly same
> parameters as the source one. So if the source has just finished cpu or
> memory hotplug, what would the dest's parameters be like?
>
> Does DIMM device, or
Hi,
According to the docs, the destination Qemu must have the exactly same
parameters as the source one. So if the source has just finished cpu or
memory hotplug, what would the dest's parameters be like?
Does DIMM device, or logically QOM object, have to be reflected on the new
command-line para
On Tue, Sep 27, 2016 at 10:48:48AM +0100, Daniel P. Berrange wrote:
> On Mon, Aug 29, 2016 at 11:06:48AM -0400, Stefan Hajnoczi wrote:
> > At KVM Forum an interesting idea was proposed to avoid
> > bdrv_drain_all() during live migration. Mike Cui and Felipe Franciosi
> > mentioned running at queue
> On 28 Sep 2016, at 10:03, Juan Quintela wrote:
>
> "Dr. David Alan Gilbert" wrote:
>> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
>>> On Mon, Aug 29, 2016 at 06:56:42PM +, Felipe Franciosi wrote:
Heya!
> On 29 Aug 2016, at 08:06, Stefan Hajnoczi wrote:
>
> At KV
On Wed, Sep 28, 2016 at 11:03:15AM +0200, Juan Quintela wrote:
> "Dr. David Alan Gilbert" wrote:
> > * Stefan Hajnoczi (stefa...@gmail.com) wrote:
> >> On Mon, Aug 29, 2016 at 06:56:42PM +, Felipe Franciosi wrote:
> >> > Heya!
> >> >
> >> > > On 29 Aug 2016, at 08:06, Stefan Hajnoczi wrote:
"Dr. David Alan Gilbert" wrote:
> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
>> On Mon, Aug 29, 2016 at 06:56:42PM +, Felipe Franciosi wrote:
>> > Heya!
>> >
>> > > On 29 Aug 2016, at 08:06, Stefan Hajnoczi wrote:
>> > >
>> > > At KVM Forum an interesting idea was proposed to avoid
>> >
On Tue, Sep 27, 2016 at 10:27:12AM +0100, Stefan Hajnoczi wrote:
> On Mon, Aug 29, 2016 at 06:56:42PM +, Felipe Franciosi wrote:
> > Heya!
> >
> > > On 29 Aug 2016, at 08:06, Stefan Hajnoczi wrote:
> > >
> > > At KVM Forum an interesting idea was proposed to avoid
> > > bdrv_drain_all() duri
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Mon, Aug 29, 2016 at 06:56:42PM +, Felipe Franciosi wrote:
> > Heya!
> >
> > > On 29 Aug 2016, at 08:06, Stefan Hajnoczi wrote:
> > >
> > > At KVM Forum an interesting idea was proposed to avoid
> > > bdrv_drain_all() during live migration.
On Mon, Aug 29, 2016 at 11:06:48AM -0400, Stefan Hajnoczi wrote:
> At KVM Forum an interesting idea was proposed to avoid
> bdrv_drain_all() during live migration. Mike Cui and Felipe Franciosi
> mentioned running at queue depth 1. It needs more thought to make it
> workable but I want to capture
On Mon, Aug 29, 2016 at 06:56:42PM +, Felipe Franciosi wrote:
> Heya!
>
> > On 29 Aug 2016, at 08:06, Stefan Hajnoczi wrote:
> >
> > At KVM Forum an interesting idea was proposed to avoid
> > bdrv_drain_all() during live migration. Mike Cui and Felipe Franciosi
> > mentioned running at queu
Heya!
> On 29 Aug 2016, at 08:06, Stefan Hajnoczi wrote:
>
> At KVM Forum an interesting idea was proposed to avoid
> bdrv_drain_all() during live migration. Mike Cui and Felipe Franciosi
> mentioned running at queue depth 1. It needs more thought to make it
> workable but I want to capture it
At KVM Forum an interesting idea was proposed to avoid
bdrv_drain_all() during live migration. Mike Cui and Felipe Franciosi
mentioned running at queue depth 1. It needs more thought to make it
workable but I want to capture it here for discussion and to archive
it.
bdrv_drain_all() is synchrono
Hello.
On 2016-01-21 14:49, Dr. David Alan Gilbert wrote:
* Alexey (aluka...@alukardd.org) wrote:
Hello,
On 2016-01-16 02:24, Eric Blake wrote:
>On 01/12/2016 05:11 AM, Dr. David Alan Gilbert wrote:
>
>>>Tell me please right way to append zeros to "BIOS (ia32) ROM Ext.
>>>(137*512)"
>>>file?
>
* Alexey (aluka...@alukardd.org) wrote:
> Hello,
>
> On 2016-01-16 02:24, Eric Blake wrote:
> >On 01/12/2016 05:11 AM, Dr. David Alan Gilbert wrote:
> >
> >>>Tell me please right way to append zeros to "BIOS (ia32) ROM Ext.
> >>>(137*512)"
> >>>file?
> >>
> >>I'd use dd; something like:
> >> dd i
Hello,
On 2016-01-16 02:24, Eric Blake wrote:
On 01/12/2016 05:11 AM, Dr. David Alan Gilbert wrote:
Tell me please right way to append zeros to "BIOS (ia32) ROM Ext.
(137*512)"
file?
I'd use dd; something like:
dd if=/dev/zero bs=1 count=18944 >> theromfile
I think that should do it (2032
On 01/12/2016 05:11 AM, Dr. David Alan Gilbert wrote:
>> Tell me please right way to append zeros to "BIOS (ia32) ROM Ext. (137*512)"
>> file?
>
> I'd use dd; something like:
> dd if=/dev/zero bs=1 count=18944 >> theromfile
> I think that should do it (203264-184320=18944)
Or simpler:
truncat
* Alexey (aluka...@alukardd.org) wrote:
>
>
> On 2016-01-12 13:04, Dr. David Alan Gilbert wrote:
> >* Alexey (aluka...@alukardd.org) wrote:
> >>Hello,
> >>
> >>On 2016-01-12 12:19, Dr. David Alan Gilbert wrote:
> >>>* Alexey (aluka...@alukardd.org) wrote:
> Hi David.
>
> On 2016-01-1
Hi,
> In my libvirt domain I have option .
Why?
cheers,
Gerd
On 2016-01-12 13:04, Dr. David Alan Gilbert wrote:
* Alexey (aluka...@alukardd.org) wrote:
Hello,
On 2016-01-12 12:19, Dr. David Alan Gilbert wrote:
>* Alexey (aluka...@alukardd.org) wrote:
>>Hi David.
>>
>>On 2016-01-11 22:51, Dr. David Alan Gilbert wrote:
>>>* Alexey (aluka...@alukardd.org)
* Alexey (aluka...@alukardd.org) wrote:
> Hello,
>
> On 2016-01-12 12:19, Dr. David Alan Gilbert wrote:
> >* Alexey (aluka...@alukardd.org) wrote:
> >>Hi David.
> >>
> >>On 2016-01-11 22:51, Dr. David Alan Gilbert wrote:
> >>>* Alexey (aluka...@alukardd.org) wrote:
> Hello.
> >>>
> >>>Hi,
> >>
Hello,
On 2016-01-12 12:19, Dr. David Alan Gilbert wrote:
* Alexey (aluka...@alukardd.org) wrote:
Hi David.
On 2016-01-11 22:51, Dr. David Alan Gilbert wrote:
>* Alexey (aluka...@alukardd.org) wrote:
>>Hello.
>
>Hi,
>
>>I have two servers between which I need have live migration.
>>
>>First se
* Alexey (aluka...@alukardd.org) wrote:
> Hi David.
>
> On 2016-01-11 22:51, Dr. David Alan Gilbert wrote:
> >* Alexey (aluka...@alukardd.org) wrote:
> >>Hello.
> >
> >Hi,
> >
> >>I have two servers between which I need have live migration.
> >>
> >>First server have QEMU emulator version 2.3.0
>
Hi David.
On 2016-01-11 22:51, Dr. David Alan Gilbert wrote:
* Alexey (aluka...@alukardd.org) wrote:
Hello.
Hi,
I have two servers between which I need have live migration.
First server have QEMU emulator version 2.3.0
Second server have QEMU emulator version 2.5.0
Migration command look
* Alexey (aluka...@alukardd.org) wrote:
> Hello.
Hi,
> I have two servers between which I need have live migration.
>
> First server have QEMU emulator version 2.3.0
> Second server have QEMU emulator version 2.5.0
>
> Migration command look like this:
> /usr/bin/virsh migrate --live DOMAIN_NAM
Hello.
I have two servers between which I need have live migration.
First server have QEMU emulator version 2.3.0
Second server have QEMU emulator version 2.5.0
Migration command look like this:
/usr/bin/virsh migrate --live DOMAIN_NAME --migrateuri
tcp://second.server qemu+ssh://second.server
On 2015年12月30日 00:46, Michael S. Tsirkin wrote:
> Interesting. So you sare saying merely ifdown/ifup is 100ms?
> This does not sound reasonable.
> Is there a chance you are e.g. getting IP from dhcp?
>
> If so that is wrong - clearly should reconfigure the old IP
> back without playing with dhcp.
On Tue, Dec 29, 2015 at 9:15 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 29, 2015 at 09:04:51AM -0800, Alexander Duyck wrote:
>> On Tue, Dec 29, 2015 at 8:46 AM, Michael S. Tsirkin wrote:
>> > On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote:
>> >>
>> >>
>> >> On 12/25/2015 8:11 PM, Mi
On Tue, Dec 29, 2015 at 09:04:51AM -0800, Alexander Duyck wrote:
> On Tue, Dec 29, 2015 at 8:46 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote:
> >>
> >>
> >> On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote:
> >> >As long as you keep up this vague tal
On Tue, Dec 29, 2015 at 8:46 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote:
>>
>>
>> On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote:
>> >As long as you keep up this vague talk about performance during
>> >migration, without even bothering with any mea
On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote:
>
>
> On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote:
> >As long as you keep up this vague talk about performance during
> >migration, without even bothering with any measurements, this patchset
> >will keep going nowhere.
> >
>
> I m
On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote:
As long as you keep up this vague talk about performance during
migration, without even bothering with any measurements, this patchset
will keep going nowhere.
I measured network service downtime for "keep device alive"(RFC patch V1
presented
On Mon, Dec 28, 2015 at 11:52:43AM +0300, Pavel Fedin wrote:
> Hello!
>
> > A dedicated IRQ per device for something that is a system wide event
> > sounds like a waste. I don't understand why a spec change is strictly
> > required, we only need to support this with the specific virtual bridge
>
On Mon, Dec 28, 2015 at 03:20:10AM +, Dong, Eddie wrote:
> > >
> > > Even if the device driver doesn't support migration, you still want to
> > > migrate VM? That maybe risk and we should add the "bad path" for the
> > > driver at least.
> >
> > At a minimum we should have support for hot-plug
Hello!
> A dedicated IRQ per device for something that is a system wide event
> sounds like a waste. I don't understand why a spec change is strictly
> required, we only need to support this with the specific virtual bridge
> used by QEMU, so I think that a vendor specific capability will do.
>
On Sun, Dec 27, 2015 at 01:45:15PM -0800, Alexander Duyck wrote:
> On Sun, Dec 27, 2015 at 1:21 AM, Michael S. Tsirkin wrote:
> > On Fri, Dec 25, 2015 at 02:31:14PM -0800, Alexander Duyck wrote:
> >> The PCI hot-plug specification calls out that the OS can optionally
> >> implement a "pause" mecha
On Sun, Dec 27, 2015 at 7:20 PM, Dong, Eddie wrote:
>> >
>> > Even if the device driver doesn't support migration, you still want to
>> > migrate VM? That maybe risk and we should add the "bad path" for the
>> > driver at least.
>>
>> At a minimum we should have support for hot-plug if we are expe
> >
> > Even if the device driver doesn't support migration, you still want to
> > migrate VM? That maybe risk and we should add the "bad path" for the
> > driver at least.
>
> At a minimum we should have support for hot-plug if we are expecting to
> support migration. You would simply have to ho
On Sun, Dec 27, 2015 at 1:21 AM, Michael S. Tsirkin wrote:
> On Fri, Dec 25, 2015 at 02:31:14PM -0800, Alexander Duyck wrote:
>> The PCI hot-plug specification calls out that the OS can optionally
>> implement a "pause" mechanism which is meant to be used for high
>> availability type environments
On Fri, Dec 25, 2015 at 02:31:14PM -0800, Alexander Duyck wrote:
> The PCI hot-plug specification calls out that the OS can optionally
> implement a "pause" mechanism which is meant to be used for high
> availability type environments. What I am proposing is basically
> extending the standard SHPC
On Thu, Dec 24, 2015 at 11:03 PM, Lan Tianyu wrote:
> Merry Christmas.
> Sorry for later response due to personal affair.
>
> On 2015年12月14日 03:30, Alexander Duyck wrote:
>>> > These sounds we need to add a faked bridge for migration and adding a
>>> > driver in the guest for it. It also needs to
On Fri, Dec 25, 2015 at 03:03:47PM +0800, Lan Tianyu wrote:
> Merry Christmas.
> Sorry for later response due to personal affair.
>
> On 2015年12月14日 03:30, Alexander Duyck wrote:
> >> > These sounds we need to add a faked bridge for migration and adding a
> >> > driver in the guest for it. It also
Merry Christmas.
Sorry for later response due to personal affair.
On 2015年12月14日 03:30, Alexander Duyck wrote:
>> > These sounds we need to add a faked bridge for migration and adding a
>> > driver in the guest for it. It also needs to extend PCI bus/hotplug
>> > driver to do pause/resume other de
On Sun, Dec 13, 2015 at 11:47:44PM +0800, Lan, Tianyu wrote:
>
>
> On 12/11/2015 1:16 AM, Alexander Duyck wrote:
> >On Thu, Dec 10, 2015 at 6:38 AM, Lan, Tianyu wrote:
> >>
> >>
> >>On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
>
> Ideally, it is able to leave guest driver unmodi
On Fri, Dec 11, 2015 at 03:32:04PM +0800, Lan, Tianyu wrote:
>
>
> On 12/11/2015 12:11 AM, Michael S. Tsirkin wrote:
> >On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote:
> >>
> >>
> >>On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
> Ideally, it is able to leave guest driver u
On Sun, Dec 13, 2015 at 7:47 AM, Lan, Tianyu wrote:
>
>
> On 12/11/2015 1:16 AM, Alexander Duyck wrote:
>>
>> On Thu, Dec 10, 2015 at 6:38 AM, Lan, Tianyu wrote:
>>>
>>>
>>>
>>> On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
>
>
> Ideally, it is able to leave guest driver unmodi
On 12/11/2015 1:16 AM, Alexander Duyck wrote:
On Thu, Dec 10, 2015 at 6:38 AM, Lan, Tianyu wrote:
On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
Ideally, it is able to leave guest driver unmodified but it requires the
hypervisor or qemu to aware the device which means we may need a
On 12/11/2015 12:11 AM, Michael S. Tsirkin wrote:
On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote:
On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
Ideally, it is able to leave guest driver unmodified but it requires the
hypervisor or qemu to aware the device which means we
On Thu, Dec 10, 2015 at 8:11 AM, Michael S. Tsirkin wrote:
> On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote:
>>
>>
>> On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
>> >>Ideally, it is able to leave guest driver unmodified but it requires the
>> >>>hypervisor or qemu to aware th
On 2015/12/10 19:41, Dr. David Alan Gilbert wrote:
* Yang Zhang (yang.zhang...@gmail.com) wrote:
On 2015/12/10 18:18, Dr. David Alan Gilbert wrote:
* Lan, Tianyu (tianyu@intel.com) wrote:
On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
I thought about what this is doing at the high level
On 2015/12/10 18:18, Dr. David Alan Gilbert wrote:
* Lan, Tianyu (tianyu@intel.com) wrote:
On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
I thought about what this is doing at the high level, and I do have some
value in what you are trying to do, but I also think we need to clarify
the mo
On Thu, Dec 10, 2015 at 6:38 AM, Lan, Tianyu wrote:
>
>
> On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
>>>
>>> Ideally, it is able to leave guest driver unmodified but it requires the
>>> >hypervisor or qemu to aware the device which means we may need a driver
>>> > in
>>> >hypervisor or q
* Lan, Tianyu (tianyu@intel.com) wrote:
>
>
> On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
> >>Ideally, it is able to leave guest driver unmodified but it requires the
> >>>hypervisor or qemu to aware the device which means we may need a driver in
> >>>hypervisor or qemu to handle the
On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote:
>
>
> On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
> >>Ideally, it is able to leave guest driver unmodified but it requires the
> >>>hypervisor or qemu to aware the device which means we may need a driver in
> >>>hypervisor or q
On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote:
Ideally, it is able to leave guest driver unmodified but it requires the
>hypervisor or qemu to aware the device which means we may need a driver in
>hypervisor or qemu to handle the device on behalf of guest driver.
Can you answer the quest
On 12/10/2015 4:38 PM, Michael S. Tsirkin wrote:
Let's assume you do save state and do have a way to detect
whether state matches a given hardware. For example,
driver could store firmware and hardware versions
in the state, and then on destination, retrieve them
and compare. It will be pretty co
* Yang Zhang (yang.zhang...@gmail.com) wrote:
> On 2015/12/10 18:18, Dr. David Alan Gilbert wrote:
> >* Lan, Tianyu (tianyu@intel.com) wrote:
> >>On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
> >>>I thought about what this is doing at the high level, and I do have some
> >>>value in what you
* Lan, Tianyu (tianyu@intel.com) wrote:
> On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
> >I thought about what this is doing at the high level, and I do have some
> >value in what you are trying to do, but I also think we need to clarify
> >the motivation a bit more. What you are saying is
On Thu, Dec 10, 2015 at 11:04:54AM +0800, Lan, Tianyu wrote:
>
> On 12/10/2015 4:07 AM, Michael S. Tsirkin wrote:
> >On Thu, Dec 10, 2015 at 12:26:25AM +0800, Lan, Tianyu wrote:
> >>On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
> >>>I thought about what this is doing at the high level, and I do
On 12/10/2015 1:14 AM, Alexander Duyck wrote:
On Wed, Dec 9, 2015 at 8:26 AM, Lan, Tianyu wrote:
For other kind of devices, it's hard to work.
We are also adding migration support for QAT(QuickAssist Technology) device.
QAT device user case introduction.
Server, networking, big data, and st
On 12/10/2015 4:07 AM, Michael S. Tsirkin wrote:
On Thu, Dec 10, 2015 at 12:26:25AM +0800, Lan, Tianyu wrote:
On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
I thought about what this is doing at the high level, and I do have some
value in what you are trying to do, but I also think we need t
On Thu, Dec 10, 2015 at 12:26:25AM +0800, Lan, Tianyu wrote:
> On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
> >I thought about what this is doing at the high level, and I do have some
> >value in what you are trying to do, but I also think we need to clarify
> >the motivation a bit more. What
On Wed, Dec 9, 2015 at 8:26 AM, Lan, Tianyu wrote:
> For other kind of devices, it's hard to work.
> We are also adding migration support for QAT(QuickAssist Technology) device.
>
> QAT device user case introduction.
> Server, networking, big data, and storage applications use QuickAssist
> Techn
On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote:
I thought about what this is doing at the high level, and I do have some
value in what you are trying to do, but I also think we need to clarify
the motivation a bit more. What you are saying is not really what the
patches are doing.
And with tha
On Tue, Nov 24, 2015 at 09:35:17PM +0800, Lan Tianyu wrote:
> This patchset is to propose a solution of adding live migration
> support for SRIOV NIC.
I thought about what this is doing at the high level, and I do have some
value in what you are trying to do, but I also think we need to clarify
th
* Pavel Fedin (p.fe...@samsung.com) wrote:
> Hello!
>
> > Some thoughts:
> > a) There is a migration state notifier list - see
> > add_migration_state_change_notifier (spice
> > calls it)
> > - but I don't think it's called in the right places for your needs; we
> > could add some m
Hello!
> Some thoughts:
> a) There is a migration state notifier list - see
> add_migration_state_change_notifier (spice
> calls it)
> - but I don't think it's called in the right places for your needs; we
> could add some more places that gets called.
I am now trying to add one m
Hello!
> Our idea at the discussion at Connect was to have an ioctl to request
> a flush, rather than to do it automatically when a CPU is stopped
> (you probably don't want to flush when only one CPU in an SMP system
> is stopped, for instance).
Yes, you're right. Looks like this would be more
On 13 October 2015 at 13:02, Pavel Fedin wrote:
> Hello!
>
>> b) Once you're in the device state saving (a above) you must not change
>> guest RAM,
>> because at that point the migration code won't send any new changes
>> across
>> to the destination. So any sync's you're going to d
Hello!
> b) Once you're in the device state saving (a above) you must not change
> guest RAM,
> because at that point the migration code won't send any new changes
> across
> to the destination. So any sync's you're going to do have to happen
> before/at
> the time we stop the
* Pavel Fedin (p.fe...@samsung.com) wrote:
> Hello!
>
> Sorry for the delayed reply.
> > What's an ITS ?
>
> Interrupt Translation Service. In a short, it's a thing responsible for
> handling PCIe MSI-X
> interrupts on ARM64 architecture.
OK; I asked Peter (cc'd) to explain a bit more about
Hello!
Sorry for the delayed reply.
> What's an ITS ?
Interrupt Translation Service. In a short, it's a thing responsible for
handling PCIe MSI-X
interrupts on ARM64 architecture.
> With a related question, how big are the tables and can it change during the
> iterated part
> of the migrat
* Pavel Fedin (p.fe...@samsung.com) wrote:
> Hello!
>
> I would like to clarify, what is the exact live migration sequence in qemu?
>
> I mean - there are pre_save and post_load callbacks for VMState structures.
> Is there any determined
> order of calling them related to memory contents migr
Hello!
I would like to clarify, what is the exact live migration sequence in qemu?
I mean - there are pre_save and post_load callbacks for VMState structures. Is
there any determined
order of calling them related to memory contents migration? In other words, is
there any guarantee
that pre_s
* Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> On Wed, Jul 29, 2015 at 11=38=44AM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> > > On Wed, Jul 29, 2015 at 10=32=59AM +0100, Dr. David Alan Gilbert wrote:
> > > > * Eduardo Otubo (eduard
On Wed, Jul 29, 2015 at 11=38=44AM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> > On Wed, Jul 29, 2015 at 10=32=59AM +0100, Dr. David Alan Gilbert wrote:
> > > * Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> > > > On Wed, Jul 29, 2015 at
* Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> On Wed, Jul 29, 2015 at 10=32=59AM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> > > On Wed, Jul 29, 2015 at 09=11=21AM +0100, Dr. David Alan Gilbert wrote:
> > > > * Eduardo Otubo (eduard
On Wed, Jul 29, 2015 at 10=32=59AM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> > On Wed, Jul 29, 2015 at 09=11=21AM +0100, Dr. David Alan Gilbert wrote:
> > > * Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> > > > On Tue, Jul 28, 2015 at
* Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> On Wed, Jul 29, 2015 at 09=11=21AM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Otubo (eduardo.ot...@profitbricks.com) wrote:
> > > On Tue, Jul 28, 2015 at 04=19=46PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Eduardo Otubo (eduard
1 - 100 of 206 matches
Mail list logo
