Hi,
Well, in case of usb hid devices breaking the guest isn't that a big
issue for at least some guests because they manage to reset the device
and continue nevertheless ...
In a situation like this, I think our responsibility is to let the user
know that there could be a problem, and provid
On 07/11/2011 05:32 PM, Kevin Wolf wrote:
I'd guess the best would be to have a special VMSTATE that means
"broken old version doesn't send a section" which we can set for
special -M?
No, the best would be to have a serious migration format, based for
example on ASN.1 which Michael Tsirkin
Am 07.07.2011 17:23, schrieb Paolo Bonzini:
> On 07/07/2011 01:02 PM, Alexander Graf wrote:
>> I'd guess the best would be to have a special VMSTATE that means
>> "broken old version doesn't send a section" which we can set for
>> special -M?
>
> No, the best would be to have a serious migration f
On 07/08/11 16:43, Peter Maydell wrote:
On 8 July 2011 14:02, Jes Sorensen wrote:
It seems reasonable to me to introduce a situation where devices have to
explicitly marked as migration compatible and fail if there are devices
in the system which are not.
To ask a dumb question: does "migrati
On 8 July 2011 14:02, Jes Sorensen wrote:
> It seems reasonable to me to introduce a situation where devices have to
> explicitly marked as migration compatible and fail if there are devices
> in the system which are not.
To ask a dumb question: does "migration" here mean only "migration"
or also
On 07/07/11 09:30, Avi Kivity wrote:
> On 07/07/2011 10:14 AM, Gerd Hoffmann wrote:
>>> Can't we just implicitly fail migration whenever there's a device in
>>> the tree that doesn't have VMSTATE?
>>
>>
>> There are cases where the device doesn't need to save state, so that
>> alone doesn't cut it.
Anthony Liguori writes:
> On 07/07/2011 04:23 AM, Markus Armbruster wrote:
>> Anthony Liguori writes:
>>
>>> On 07/06/2011 11:04 AM, Gerd Hoffmann wrote:
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used
On 07/07/2011 02:19 AM, Gerd Hoffmann wrote:
On 07/06/11 19:13, Anthony Liguori wrote:
On 07/06/2011 11:04 AM, Gerd Hoffmann wrote:
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used to not save state before do
now.
We al
On 07/06/2011 06:32 PM, Alexander Graf wrote:
On 06.07.2011, at 22:01, Anthony Liguori wrote:
On 07/06/2011 12:28 PM, Avi Kivity wrote:
On 07/06/2011 07:04 PM, Gerd Hoffmann wrote:
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. device
On 07/07/2011 01:02 PM, Alexander Graf wrote:
I'd guess the best would be to have a special VMSTATE that means
"broken old version doesn't send a section" which we can set for
special -M?
No, the best would be to have a serious migration format, based for
example on ASN.1 which Michael Tsirkin
Hi,
Not so fast :)
I agree that throwing away unrecognized migration data is unsafe, and
should not be done. Now let me present my little problem.
I'm working on making migration preserve "tray status": open/closed,
locked/unlocked.
For ide-cd, I can stick a subsection "ide_drive/tray_stat
On 07/07/2011 04:23 AM, Markus Armbruster wrote:
Anthony Liguori writes:
On 07/06/2011 11:04 AM, Gerd Hoffmann wrote:
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used to not save state before do now.
We already have o
On 07.07.2011, at 11:23, Markus Armbruster wrote:
> Anthony Liguori writes:
>
>> On 07/06/2011 11:04 AM, Gerd Hoffmann wrote:
>>> Hi folks,
>>>
>>> We'll need to figure a sane way to handle migration to older versions
>>> with new sections, i.e. devices which used to not save state before do n
Anthony Liguori writes:
> On 07/06/2011 11:04 AM, Gerd Hoffmann wrote:
>> Hi folks,
>>
>> We'll need to figure a sane way to handle migration to older versions
>> with new sections, i.e. devices which used to not save state before do now.
>>
>> We already have one case in tree: usb. qemu 0.14 sav
On 07/07/2011 10:14 AM, Gerd Hoffmann wrote:
Can't we just implicitly fail migration whenever there's a device in
the tree that doesn't have VMSTATE?
There are cases where the device doesn't need to save state, so that
alone doesn't cut it.
It should then say so by having an empty VMSTATE d
On 07/06/11 19:13, Anthony Liguori wrote:
On 07/06/2011 11:04 AM, Gerd Hoffmann wrote:
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used to not save state before do
now.
We already have one case in tree: usb. qemu 0.14 sa
Hi,
We don't have a hard policy about not merging devices that don't
support migration.
Since migration must be supported forever, I'd rather see a device
get some solid testing before it starts doing live migration. That
said, we should probably do this consciously by explicitly marking
the
On 06.07.2011, at 22:01, Anthony Liguori wrote:
> On 07/06/2011 12:28 PM, Avi Kivity wrote:
>> On 07/06/2011 07:04 PM, Gerd Hoffmann wrote:
>>> Hi folks,
>>>
>>> We'll need to figure a sane way to handle migration to older versions
>>> with new sections, i.e. devices which used to not save state
On 07/06/2011 12:28 PM, Avi Kivity wrote:
On 07/06/2011 07:04 PM, Gerd Hoffmann wrote:
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used to not save state before do
now.
We already have one case in tree: usb. qemu 0.14 sa
On 07/06/2011 07:04 PM, Gerd Hoffmann wrote:
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used to not save state before do
now.
We already have one case in tree: usb. qemu 0.14 saves state for
usb-hid devices and th
On 07/06/2011 11:04 AM, Gerd Hoffmann wrote:
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used to not save state before do now.
We already have one case in tree: usb. qemu 0.14 saves state for usb-hid
devices and the usb-h
Hi folks,
We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used to not save state before do now.
We already have one case in tree: usb. qemu 0.14 saves state for
usb-hid devices and the usb-hub, whereas qemu 0.13 and older don't.
22 matches
Mail list logo
