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
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 format,
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
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.
It should
On 8 July 2011 14:02, Jes Sorensen jes.soren...@redhat.com 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
On 07/08/11 16:43, Peter Maydell wrote:
On 8 July 2011 14:02, Jes Sorensenjes.soren...@redhat.com 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
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
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
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
Anthony Liguori anth...@codemonkey.ws 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
On 07.07.2011, at 11:23, Markus Armbruster wrote:
Anthony Liguori anth...@codemonkey.ws 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
On 07/07/2011 04:23 AM, Markus Armbruster wrote:
Anthony Liguorianth...@codemonkey.ws 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
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_state
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
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.
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
Anthony Liguori anth...@codemonkey.ws writes:
On 07/07/2011 04:23 AM, Markus Armbruster wrote:
Anthony Liguorianth...@codemonkey.ws 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.
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.
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
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
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
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 before do
22 matches
Mail list logo
