5:43 p.m.
I posted this on the test list since it is ff13, but perhaps
there might be more insight on the virt list:
I just tried running my Windows XP KVM on fedora 13
(I installed the KVM under fedora 12). It seemed to work
well, but I'm using the redhat virtio drivers for
network and disk, and Windows insisted on re-installing
the drivers (claiming "new hardware") the first time
I booted under fedora 13 libvirtd.
Strangely, when I booted the same KVM after going back
to fedora 12 on the host, it didn't insist on
re-installing the drivers yet again.
None of this triggered any Windows activation nonsense
(which is why it is only annoying).
I guess I should poke around in the windows hardware
manager for the details of what changed, but it would
sure be nice if things wouldn't change at all :-).
3:05 a.m.
On 03/31/10 00:43, Tom Horsley wrote:
I posted this on the test list since it is ff13, but perhaps
there might be more insight on the virt list:
I just tried running my Windows XP KVM on fedora 13
(I installed the KVM under fedora 12). It seemed to work
well, but I'm using the redhat virtio drivers for
network and disk, and Windows insisted on re-installing
the drivers (claiming "new hardware") the first time
I booted under fedora 13 libvirtd.
Strangely, when I booted the same KVM after going back
to fedora 12 on the host, it didn't insist on
re-installing the drivers yet again.
None of this triggered any Windows activation nonsense
(which is why it is only annoying).
I guess I should poke around in the windows hardware
manager for the details of what changed, but it would
sure be nice if things wouldn't change at all :-).
The BIOS changed between F12 and F13 and probably the layout of
how the device is presented to the guest. Plus a couple of other
things. Windows has the broken idea that it wants to reinstall
things whenever it sees the same thing in a new place - try
plugging a USB device into different ports .... really not much
we can do about it.
When it installed the drivers under F13 it didn't remove them
for the previous install, which is why you didn't see it when
rebooting under F12.
You're welcome to file a bug with M$ about this though :)
Cheers,
Jes
5:06 a.m.
On 03/31/2010 11:05 AM, Jes Sorensen wrote:
On 03/31/10 00:43, Tom Horsley wrote:
> I posted this on the test list since it is ff13, but perhaps
> there might be more insight on the virt list:
>
> I just tried running my Windows XP KVM on fedora 13
> (I installed the KVM under fedora 12). It seemed to work
> well, but I'm using the redhat virtio drivers for
> network and disk, and Windows insisted on re-installing
> the drivers (claiming "new hardware") the first time
> I booted under fedora 13 libvirtd.
>
> Strangely, when I booted the same KVM after going back
> to fedora 12 on the host, it didn't insist on
> re-installing the drivers yet again.
>
> None of this triggered any Windows activation nonsense
> (which is why it is only annoying).
>
> I guess I should poke around in the windows hardware
> manager for the details of what changed, but it would
> sure be nice if things wouldn't change at all :-).
>
The BIOS changed between F12 and F13 and probably the layout of
how the device is presented to the guest. Plus a couple of other
things. Windows has the broken idea that it wants to reinstall
things whenever it sees the same thing in a new place - try
plugging a USB device into different ports .... really not much
we can do about it.
I thought F12 and F13 were supposed to keep the same pci slot layout.
--
error compiling committee.c: too many arguments to function
5:09 a.m.
On 04/01/10 12:06, Avi Kivity wrote:
On 03/31/2010 11:05 AM, Jes Sorensen wrote:
>> I guess I should poke around in the windows hardware
>> manager for the details of what changed, but it would
>> sure be nice if things wouldn't change at all :-).
> The BIOS changed between F12 and F13 and probably the layout of
> how the device is presented to the guest. Plus a couple of other
> things. Windows has the broken idea that it wants to reinstall
> things whenever it sees the same thing in a new place - try
> plugging a USB device into different ports .... really not much
> we can do about it.
>
I thought F12 and F13 were supposed to keep the same pci slot layout.
I believe F12 was BOCHS, F13 is Seabios, even if it's the same layout
something almost certainly moved things or flipped a flag of some sort.
Jes
6:19 a.m.
On 04/01/2010 01:09 PM, Jes Sorensen wrote:
On 04/01/10 12:06, Avi Kivity wrote:
> On 03/31/2010 11:05 AM, Jes Sorensen wrote:
>>> I guess I should poke around in the windows hardware
>>> manager for the details of what changed, but it would
>>> sure be nice if things wouldn't change at all :-).
>> The BIOS changed between F12 and F13 and probably the layout of
>> how the device is presented to the guest. Plus a couple of other
>> things. Windows has the broken idea that it wants to reinstall
>> things whenever it sees the same thing in a new place - try
>> plugging a USB device into different ports .... really not much
>> we can do about it.
>>
> I thought F12 and F13 were supposed to keep the same pci slot layout.
I believe F12 was BOCHS, F13 is Seabios,
That's unrelated.
even if it's the same layout
something almost certainly moved things or flipped a flag of some sort.
Well, what? it's a bug.
--
error compiling committee.c: too many arguments to function
6:32 a.m.
> even if it's the same layout
> something almost certainly moved things or flipped a flag of some sort.
Well, what? it's a bug.
It certainly seemed a bit like a bug to me, but I also can't imagine
how it could keep things absolutely identical unless it did something
like save the details of the pci slots, interrupt assignments, etc.
in the .xml files it dumps, so when you reload the xml in a new
distro, it can replicate the details.
I've seen the dumped xml - it ain't got that stuff in there :-).
It isn't so bad when I'm just trying to boot the machine on a new
distro, but I thought live migration was part of the feature set.
This seems like an attempt to migrate from f12 to f13 would move
the hardware out from under me, something I doubt even a linux
KVM could survive :-).
6:40 a.m.
On Thu, Apr 01, 2010 at 07:32:52AM -0400, Tom Horsley wrote:
> > even if it's the same layout
> > something almost certainly moved things or flipped a flag of some sort.
>
> Well, what? it's a bug.
It certainly seemed a bit like a bug to me, but I also can't imagine
how it could keep things absolutely identical unless it did something
like save the details of the pci slots, interrupt assignments, etc.
in the .xml files it dumps, so when you reload the xml in a new
distro, it can replicate the details.
As of Fedora 13 we *will* be saving the PCI slots - you'll see in the XML for
any new guest you define, it will have loads of PCI info there. We also now
have ability to specify an exact CPU model, so we no longer susceptible to
changes in host CPU flags.
In Fedora 12 we merely save the machine type eg you'll see the machine type
in the XML be changed from 'pc' to a specific version like 'pc-0.11'.
This
is enough to keep some OS happy some of the time, but PCI slots is what we
really need for the full job.
I've seen the dumped xml - it ain't got that stuff in there :-).
It isn't so bad when I'm just trying to boot the machine on a new
distro, but I thought live migration was part of the feature set.
This seems like an attempt to migrate from f12 to f13 would move
the hardware out from under me, something I doubt even a linux
KVM could survive :-).
When we have PCI slot persistence you should be able to live migrate between
different versions of Fedora and have everything just work.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
6:51 a.m.
On 04/01/2010 02:40 PM, Daniel P. Berrange wrote:
On Thu, Apr 01, 2010 at 07:32:52AM -0400, Tom Horsley wrote:
>>> even if it's the same layout
>>> something almost certainly moved things or flipped a flag of some sort.
>>
>> Well, what? it's a bug.
>
> It certainly seemed a bit like a bug to me, but I also can't imagine
> how it could keep things absolutely identical unless it did something
> like save the details of the pci slots, interrupt assignments, etc.
> in the .xml files it dumps, so when you reload the xml in a new
> distro, it can replicate the details.
As of Fedora 13 we *will* be saving the PCI slots - you'll see in the XML for
any new guest you define, it will have loads of PCI info there. We also now
have ability to specify an exact CPU model, so we no longer susceptible to
changes in host CPU flags.
In Fedora 12 we merely save the machine type eg you'll see the machine type
in the XML be changed from 'pc' to a specific version like 'pc-0.11'.
This
is enough to keep some OS happy some of the time, but PCI slots is what we
really need for the full job.
>
> I've seen the dumped xml - it ain't got that stuff in there :-).
>
> It isn't so bad when I'm just trying to boot the machine on a new
> distro, but I thought live migration was part of the feature set.
> This seems like an attempt to migrate from f12 to f13 would move
> the hardware out from under me, something I doubt even a linux
> KVM could survive :-).
When we have PCI slot persistence you should be able to live migrate between
different versions of Fedora and have everything just work.
You're talking about migration between f12 -> f13, not live migration
which is more complex and needs 2 hosts.
Daniel
7:06 a.m.
On Thu, 1 Apr 2010 12:40:06 +0100
Daniel P. Berrange wrote:
When we have PCI slot persistence you should be able to live migrate
between
different versions of Fedora and have everything just work.
Good to know! So from f13 onward I shouldn't see any more "new hardware
found" messages (at least until the inevitable linux developer OCD kicks
in and someone decides they just *have* to change everything or they'll
burst :-).
Thanks for the info.
10:16 a.m.
On 04/01/2010 02:40 PM, Daniel P. Berrange wrote:
> It isn't so bad when I'm just trying to boot the machine on a new
> distro, but I thought live migration was part of the feature set.
> This seems like an attempt to migrate from f12 to f13 would move
> the hardware out from under me, something I doubt even a linux
> KVM could survive :-).
>
When we have PCI slot persistence you should be able to live migrate between
different versions of Fedora and have everything just work.
I thought that was one of the F12 features (stable guest ABI), but that
bit is only in F13?
--
error compiling committee.c: too many arguments to function
10:23 a.m.
On Thu, Apr 01, 2010 at 06:16:56PM +0300, Avi Kivity wrote:
On 04/01/2010 02:40 PM, Daniel P. Berrange wrote:
>
>>It isn't so bad when I'm just trying to boot the machine on a new
>>distro, but I thought live migration was part of the feature set.
>>This seems like an attempt to migrate from f12 to f13 would move
>>the hardware out from under me, something I doubt even a linux
>>KVM could survive :-).
>>
>When we have PCI slot persistence you should be able to live migrate
>between
>different versions of Fedora and have everything just work.
>
I thought that was one of the F12 features (stable guest ABI), but that
bit is only in F13?
F12 got the stable machine type bits.
F13 got the stable PCI slot addressing bits
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:26 a.m.
On 04/01/2010 06:23 PM, Daniel P. Berrange wrote:
> I thought that was one of the F12 features (stable guest ABI), but that
> bit is only in F13?
>
F12 got the stable machine type bits.
F13 got the stable PCI slot addressing bits
Thanks for clearing this up.
--
error compiling committee.c: too many arguments to function
7:24 p.m.
2010/4/1 Daniel P. Berrange <berrange(a)redhat.com>:
On Thu, Apr 01, 2010 at 06:16:56PM +0300, Avi Kivity wrote:
> On 04/01/2010 02:40 PM, Daniel P. Berrange wrote:
> >
> >>It isn't so bad when I'm just trying to boot the machine on a new
> >>distro, but I thought live migration was part of the feature set.
> >>This seems like an attempt to migrate from f12 to f13 would move
> >>the hardware out from under me, something I doubt even a linux
> >>KVM could survive :-).
> >>
> >When we have PCI slot persistence you should be able to live migrate
> >between
> >different versions of Fedora and have everything just work.
> >
>
> I thought that was one of the F12 features (stable guest ABI), but that
> bit is only in F13?
F12 got the stable machine type bits.
F13 got the stable PCI slot addressing bits
Hi Daniel
Do you know how this is in RHEL 5.4/5.5/6.0? Is the machine type bits
and PCI slot addressing bits stable in 5.x/6.x?
Thanks
Kenni
7:06 a.m.
On 04/01/10 13:19, Avi Kivity wrote:
On 04/01/2010 01:09 PM, Jes Sorensen wrote:
>> I thought F12 and F13 were supposed to keep the same pci slot layout.
>
> I believe F12 was BOCHS, F13 is Seabios,
That's unrelated.
Depends whether we want to move things in Seabios to show up exactly
like they do in BOCHS or not.
> even if it's the same layout
> something almost certainly moved things or flipped a flag of some sort.
Well, what? it's a bug.
The problem is that Windows has the idea that the same device showing up
somewhere else requires a driver reinstall. If anything here is a bug,
then it's Windows' behavior on this front.
Cheers,
Jes
7:10 a.m.
On 04/01/2010 03:06 PM, Jes Sorensen wrote:
On 04/01/10 13:19, Avi Kivity wrote:
> On 04/01/2010 01:09 PM, Jes Sorensen wrote:
>>> I thought F12 and F13 were supposed to keep the same pci slot layout.
>>
>> I believe F12 was BOCHS, F13 is Seabios,
>
> That's unrelated.
Depends whether we want to move things in Seabios to show up exactly
like they do in BOCHS or not.
SeaBIOS has no influence on the hardware, only qemu does. It can't move
cards in their slots or jumper irqs.
>> even if it's the same layout
>> something almost certainly moved things or flipped a flag of some sort.
>
> Well, what? it's a bug.
The problem is that Windows has the idea that the same device showing up
somewhere else requires a driver reinstall. If anything here is a bug,
then it's Windows' behavior on this front.
No, the bug is that something moved around. It's the host's
responsibility not to change things. Qemu/libvirt are supposed to keep
everything in its original slot across upgrades. While blaming Windows
is a common pastime it is not very constructive.
--
error compiling committee.c: too many arguments to function
5138
days inactive
5141
days old
14 comments
6 participants
participants (6)
-
Avi Kivity -
Daniel P. Berrange -
Dor Laor -
Jes Sorensen -
Kenni Lund -
Tom Horsley