On Mon, Dec 21, 2009 at 12:45:26PM +0100, Alexander Graf wrote: > > On 21.12.2009, at 12:38, Michael S. Tsirkin wrote: > > > On Mon, Dec 21, 2009 at 12:22:53PM +0100, Alexander Graf wrote: > >> > >> On 21.12.2009, at 12:18, Michael S. Tsirkin wrote: > >> > >>> On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi Kivity wrote: > >>>> On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote: > >>>>> > >>>>>>> Hmm, then, shouldn't either kvm or qemu mask features that we do not > >>>>>>> emulate well enough to make windows not crash? > >>>>>>> > >>>>>> -cpu host does that already, no? > >>>>>> > >>>>>> Alex > >>>>>> > >>>>> I expected so, but Avi here seems to say windows will crash if you > >>>>> use a new CPU with it ... > >>>>> > >>>> > >>>> No, Windows tries to detect changes in your hardware and assumes that if > >>>> > >>>> too many things change, you might be a pirate and requires you to phone > >>>> their offices to re-authenticate. > >>> > >>> How often does a casual user upgrade his host CPU? > >> > >> I tend to have my VM images on an NFS share and expect them to work > >> properly on all PCs I work on. > >> So I guess the answer is "often"? > >> > >> Alex > > > > Yes but you are not a casual user, are you? > > Well, we have two groups: > > 1) Casual user w/o management app > 2) Enterprise user w/ management app > > So I clearly belong to the first group.
No, you are in 3) virtualization hacker without management app :) > > Consider a 64 bit guest to > > see why moving a VM across machines needs some planning. > > -ENOPARSE > > We're still talking about bootup on different machines, not migration / > loadvm. > > Alex Translation: your requirement "work on all PCs I work on" might only be satisfied by specifying the set of PCs you work on. Bootup on different machines has some of the same issues as migration. Consider a 64 bit guest as an example, I think it can not boot on a 32 bit host OS with kvm. I think you can use tcg, but it will be slower. Same thing applies to other CPU features. Many guests reconfigure themselves when you swap harware under them. This makes it easier to move such guests between machines, or change qemu configuration and still reuse guest image. Others might record hardware state on setup (64 bit above is one such example) making such changes more painful. I do think it would be good for us to supply management with utilities that analyse system hardware features relevant to qemu in a portable way. Could be some qemu monitor command, even. Management would be able to decide between using least common denominator and not supporting some hosts. -- MST
