On Fri, Aug 09, 2013 at 11:43:29AM +0200, Paolo Bonzini wrote:
Il 09/08/2013 11:02, Hu Tao ha scritto:
On Fri, Aug 09, 2013 at 04:02:24PM +0800, Hu Tao wrote:
On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
This patch is a workaround to not show pvpanic in UI to avoid the
On Mon, Aug 12, 2013 at 10:23:58AM +0800, Hu Tao wrote:
On Fri, Aug 09, 2013 at 11:43:29AM +0200, Paolo Bonzini wrote:
Il 09/08/2013 11:02, Hu Tao ha scritto:
On Fri, Aug 09, 2013 at 04:02:24PM +0800, Hu Tao wrote:
On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
This
On Fri, Aug 09, 2013 at 04:02:24PM +0800, Hu Tao wrote:
On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
This patch is a workaround to not show pvpanic in UI to avoid the
problem in Windows.
It's not a workaround, it is a proper bugfix.
What versions of
On Mon, 2013-08-05 at 20:24 +0800, Hu Tao wrote:
On Mon, Aug 05, 2013 at 06:13:39AM -0400, Paolo Bonzini wrote:
for example: in Windows(let's say XP) the Device manager will open a
new device wizard and the device will appear as an unrecognized
device. On a cluster with hundreds of
On Tue, Aug 06, 2013 at 02:45:48PM +0200, Andreas Färber wrote:
Am 06.08.2013 14:09, schrieb Michael S. Tsirkin:
On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
FWIW -M q35 does not create all Q35 devices, there's -readconfig
docs/q35-chipset.cfg for the rest. The criteria
On 08/05/2013 09:19 PM, Eric Blake wrote:
On 08/05/2013 01:04 PM, Paolo Bonzini wrote:
Libvirt has no problem enabling -device pvpanic for all guests where
on_crash is set to a non-default value, since the use of on_crash is
a sufficient hint that the user expects the guest to be able to
On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
As you see we do let people change many parameters
that do affect activation.
By editing XML user can shoot himself in the foot, we should not prevent
that.
So that's what I'm saying basically.
At the moment there's
...@redhat.com, Paolo Bonzini pbonz...@redhat.com, Eric Blake
ebl...@redhat.com, Andreas Färber afaer...@suse.de
Sent: Tuesday, August 6, 2013 6:05:27 PM
Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
On Tue, Aug 06, 2013 at 04:03:17AM -0400, Vadim Rozenfeld wrote:
- Original
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that there's
a single mouse there?
This is a PV technology which to me looks like it was
rushed through and not only set on by default, but
without a way to disable it -
...@nongnu.org, Gerd
Hoffmann kra...@redhat.com, Paolo Bonzini pbonz...@redhat.com, Eric
Blake ebl...@redhat.com, Andreas Färber afaer...@suse.de
Sent: Tuesday, August 6, 2013 5:34:06 PM
Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
On Mon, Aug 05, 2013 at 09:32:18PM +0300
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that there's
a single mouse there?
This is a PV technology which to me looks like it was
rushed through
,
seabios@seabios.org, qemu-de...@nongnu.org, Gerd Hoffmann
kra...@redhat.com, Paolo Bonzini pbonz...@redhat.com, Eric Blake
ebl...@redhat.com, Andreas Färber afaer...@suse.de
Sent: Tuesday, August 6, 2013 6:05:27 PM
Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
On Tue
Am 06.08.2013 10:36, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that there's
a single mouse there?
This is a PV technology which to me
...@redhat.com, Eric
Blake ebl...@redhat.com, Andreas Färber afaer...@suse.de
Sent: Tuesday, August 6, 2013 5:34:06 PM
Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
As you see we do let people change many parameters
On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas Färber wrote:
Am 06.08.2013 10:36, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that
On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that there's
a single mouse there?
This
On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas Färber wrote:
Am 06.08.2013 10:36, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that there's
a single mouse there?
This is a PV technology which to me looks like it was
rushed through
On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how likely is it that there's
a single mouse there?
This is a
On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a
On Tue, Aug 06, 2013 at 12:20:27PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas Färber wrote:
Am 06.08.2013 10:36, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb
On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
If you see a mouse in a room, how
On Tue, Aug 06, 2013 at 01:13:17PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM
On Tue, Aug 06, 2013 at 01:14:14PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 01:13:17PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao wrote:
On Tue, Aug 06, 2013 at 11:33:10AM
On Tue, Aug 06, 2013 at 01:23:26PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 01:14:14PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 01:13:17PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at
Am 06.08.2013 11:32, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb
Am 06.08.2013 12:44, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
It's a QEMU issue, devices that are added with -device are
documented in -device help and removed by dropping them from
command line. Devices added by default have no way to
be
On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
Am 06.08.2013 12:44, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
It's a QEMU issue, devices that are added with -device are
documented in -device help and removed by dropping them
Am 06.08.2013 13:00, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
I wonder if IPMI might be such an alternative in the future, in which
case we should come up with some way to fully disable pvpanic device
creation. CC'ing Corey.
IPMI was considered,
Hi,
And what are the rules that govern device exclusion from -nodefaults
list? Why -nodefaults does not create empty machine?
qemu -nodefaults should give you just cpu + northbridge + southbridge.
qemu should give you a usable virtual machine, so qemu adds some
optional devices which are
On Tue, Aug 06, 2013 at 01:23:49PM +0200, Andreas Färber wrote:
Am 06.08.2013 13:00, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
I wonder if IPMI might be such an alternative in the future, in which
case we should come up with some way to fully
On Tue, Aug 06, 2013 at 03:00:06PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 01:23:49PM +0200, Andreas Färber wrote:
Am 06.08.2013 13:00, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
I wonder if IPMI might be such an alternative in the
On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
Am 06.08.2013 12:44, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
It's a QEMU issue, devices that are added with -device are
documented in -device help and removed by dropping them
On Tue, Aug 06, 2013 at 02:00:35PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
Am 06.08.2013 11:32, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb
On Tue, Aug 06, 2013 at 01:54:17PM +0200, Gerd Hoffmann wrote:
Hi,
And what are the rules that govern device exclusion from -nodefaults
list? Why -nodefaults does not create empty machine?
qemu -nodefaults should give you just cpu + northbridge + southbridge.
On modern machine this
On Tue, Aug 06, 2013 at 03:05:52PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 03:00:06PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 01:23:49PM +0200, Andreas Färber wrote:
Am 06.08.2013 13:00, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas
On Tue, Aug 06, 2013 at 03:08:32PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 02:00:35PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
Am 06.08.2013 11:32, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael
Am 06.08.2013 14:09, schrieb Michael S. Tsirkin:
On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote:
FWIW -M q35 does not create all Q35 devices, there's -readconfig
docs/q35-chipset.cfg for the rest. The criteria certainly is not
migratability, since ICH9 AHCI (part of -M q35) is
On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
pvpanic device is an internal default device in qemu. It may cause
problem when upgrading qemu from a version without pvpanic.
for example: in Windows(let's say XP) the Device manager will open a
new device wizard and the device will
On 08/05/13 10:16, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
pvpanic device is an internal default device in qemu. It may cause
problem when upgrading qemu from a version without pvpanic.
On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
pvpanic device is an internal default device in qemu. It may cause
problem when upgrading qemu from a version without pvpanic.
for example: in Windows(let's say XP)
On Mon, Aug 05, 2013 at 11:03:53AM +0200, Gerd Hoffmann wrote:
On 08/05/13 10:16, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
pvpanic device is an internal default device in qemu. It may
On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
pvpanic device is an internal default device in qemu. It may cause
problem when upgrading qemu from a
for example: in Windows(let's say XP) the Device manager will open a
new device wizard and the device will appear as an unrecognized
device. On a cluster with hundreds of such VMs, If that cluster has
a health monitoring service it may show all the VMs in a not healthy
state.
Is this
That's just pushing the problem elsewhere. How management suppose to know
if guest support pvpanic device?
The problem isn't new and management already does that when figuring
whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
ac97 or intel-hda sound,
On Mon, Aug 05, 2013 at 06:13:39AM -0400, Paolo Bonzini wrote:
for example: in Windows(let's say XP) the Device manager will open a
new device wizard and the device will appear as an unrecognized
device. On a cluster with hundreds of such VMs, If that cluster has
a health monitoring
This patch is a workaround to not show pvpanic in UI to avoid the
problem in Windows.
It's not a workaround, it is a proper bugfix.
What versions of Windows did you test it on? Did it hide the New
Hardware wizard properly (I think it appears only on XP/2003)?
Windows XP. I
On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at
On Mon, Aug 05, 2013 at 09:26:32AM -0400, Paolo Bonzini wrote:
This patch is a workaround to not show pvpanic in UI to avoid the
problem in Windows.
It's not a workaround, it is a proper bugfix.
What versions of Windows did you test it on? Did it hide the New
Hardware
On Mon, Aug 05, 2013 at 06:10:47AM -0400, Paolo Bonzini wrote:
That's just pushing the problem elsewhere. How management suppose to know
if guest support pvpanic device?
The problem isn't new and management already does that when figuring
whenever the guest should get
On Mon, Aug 05, 2013 at 06:03:34PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at
That's just pushing the problem elsewhere. How management suppose to
know
if guest support pvpanic device?
The problem isn't new and management already does that when figuring
whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
ac97 or intel-hda sound,
On Mon, Aug 05, 2013 at 12:01:57PM -0400, Paolo Bonzini wrote:
That's just pushing the problem elsewhere. How management suppose to
know
if guest support pvpanic device?
The problem isn't new and management already does that when figuring
whenever the guest should get
On 08/05/2013 06:18 PM, Michael S. Tsirkin wrote:
Depending on the management, management could just be the user.
Most of the time the user simply says to use virtio in the XML.
If it had to be specified manually every time, pvpanic would be
just another knob that nobody uses.
Management
On Mon, Aug 05, 2013 at 06:46:06PM +0200, Paolo Bonzini wrote:
On 08/05/2013 06:18 PM, Michael S. Tsirkin wrote:
Depending on the management, management could just be the user.
Most of the time the user simply says to use virtio in the XML.
If it had to be specified manually every time,
On Mon, Aug 05, 2013 at 07:04:22PM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 06:03:34PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at
Libvirt has no problem enabling -device pvpanic for all guests where
on_crash is set to a non-default value, since the use of on_crash is
a sufficient hint that the user expects the guest to be able to notify
of a crash in the first place. But I definitely agree that it is more
conservative
On 08/05/2013 01:04 PM, Paolo Bonzini wrote:
Libvirt has no problem enabling -device pvpanic for all guests where
on_crash is set to a non-default value, since the use of on_crash is
a sufficient hint that the user expects the guest to be able to notify
of a crash in the first place. But I
On 08/05/2013 12:26 PM, Michael S. Tsirkin wrote:
This is a PV technology which to me looks like it was
rushed through and not only set on by default, but
without a way to disable it - apparently on the assumption
there's 0 chance it can cause any damage. Now that
we do know the chance it's
59 matches
Mail list logo
