Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

[Sylvain Petreolle]

----- Message d'origine ----

> De : Anthony Liguori <anthony@codemonkey.ws>
> À : Ian Kirk <blob@blob.co.uk>
> Cc : qemu-devel@nongnu.org
> Envoyé le : Lundi, 25 Août 2008, 2h23mn 59s
> Objet : Re: [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.
> 
> Ian Kirk wrote:
> > Anthony Liguori wrote:
> >
> >  
> >> Ian Kirk wrote:
> >>    
> >>> Hi,
> >>>
> >>> This is my first time sending a patch, so apologies for any errors.
> >>>
> >>> Patch makes vmport optionally initiated.
> >>>
> >>>      
> >> Why should it be optional?
> >>    
> >
> > I believe that VMware ESXi (and perhaps other hypervisors/emulators/etc)
> > doesn't work when it thinks it is running within virtual enviroment, as it
> > talks to vmport when booting (and fails in the current implemtnation -
> > perhaps it only works under itself?)
> >  
> 
> That's most likely because the vmport emulation isn't complete enough.
> 
> > If I comment init_vmport() out, it definately progresses further along the
> > boot sequence.
> >
> > Also, I guess, it gives you the option to better emulate a real PC (which
> > I assume doesn't have vmport).
> >  
> 
> I don't think that's very valuable in and of itself.  Moreover, there 
> are probably a lot more issues with respect to getting ESXi to run under 
> QEMU.  Adding another command line option to support something that we 
> don't know will ever work worries me.  It's just another knob for 
> someone to accidentally tweak.
> 
> Regards,
> 
> Anthony Liguori

Apart ESXi, there are software that behave differently if they detect a virtual environment.
Some of them completely refuse to work.


Regards,

Sylvain Petreolle

Re: Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

[Anthony Liguori]

Sylvain Petreolle wrote:
> ----- Message d'origine ----
>   
> Apart ESXi, there are software that behave differently if they detect a virtual environment.
> Some of them completely refuse to work.
>   

What software detects the VMware backdoor and refuses to work?  It's 
silly to argue anything but specifics.  It's sufficient easy to detect 
that guest software is running under QEMU as it is regardless of vmport.

Regards,

Anthony Liguori

> Regards,
>
> Sylvain Petreolle
>
>
>
>   

Re: Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

[Ian Kirk]

Anthony Liguori wrote:

> Sylvain Petreolle wrote:
> > ----- Message d'origine ----
> >   Apart ESXi, there are software that behave differently if they detect a
> > virtual environment.
> > Some of them completely refuse to work.
> >
>
> What software detects the VMware backdoor and refuses to work?  It's silly to
> argue anything but specifics.  It's sufficient easy to detect that guest
> software is running under QEMU as it is regardless of vmport.

So I guess that a toggle for vmport, in any method of implementation, is
not wanted then?

Re: Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

[Anthony Liguori]

Ian Kirk wrote:
> Anthony Liguori wrote:
>
>   
>> Sylvain Petreolle wrote:
>>     
>>> ----- Message d'origine ----
>>>   Apart ESXi, there are software that behave differently if they detect a
>>> virtual environment.
>>> Some of them completely refuse to work.
>>>
>>>       
>> What software detects the VMware backdoor and refuses to work?  It's silly to
>> argue anything but specifics.  It's sufficient easy to detect that guest
>> software is running under QEMU as it is regardless of vmport.
>>     
>
> So I guess that a toggle for vmport, in any method of implementation, is
> not wanted then?
>   

Not in the absence of an actually use-case.

Options for the sake of options are never a good thing.

Regards,

Anthony Liguori

Re: Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

[Ian Kirk]

Anthony Liguori wrote:

> Not in the absence of an actually use-case.

You mean apart from my use-case of wanting to emulate a PC to install any
of the Vmware ESX/ESXi Products (specifically PXE booting ESXi) ?

(I appreciate that this fails further the down the boot due to some other
incompleteness in IA32 PC emulation of QEMU)

How many use-cases are needed ?

Re: Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

[Anthony Liguori]

Ian Kirk wrote:
> Anthony Liguori wrote:
>
>   
>> Not in the absence of an actually use-case.
>>     
>
> You mean apart from my use-case of wanting to emulate a PC to install any
> of the Vmware ESX/ESXi Products (specifically PXE booting ESXi) ?
>
> (I appreciate that this fails further the down the boot due to some other
> incompleteness in IA32 PC emulation of QEMU)
>
> How many use-cases are needed ?
>   

When you actually get ESX working in QEMU, then we can revisit whether 
this is really necessary or not.  At this point in time, you don't know 
for sure whether disabling vmport really makes things better or not.  
All you know, is that it fails with a different type of error.  You may 
discover down the road that the only way to get ESX working under QEMU 
is to add something to vmport as opposed to disabling it altogether.

Regards,

Anthony Liguori

Re: Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

[Ian Kirk]

Anthony Liguori wrote:

> You may discover down the road that the only way to get ESX working
> under QEMU is to add something to vmport as opposed to disabling it
> altogether.

I think that's highly unlikely unless all real PC BIOSes support vmport?

Re: Re : [Qemu-devel] [PATCH 1/1] Make vmport an optional feature at run time.

[Anthony Liguori]

Ian Kirk wrote:
> Anthony Liguori wrote:
>
>   
>> You may discover down the road that the only way to get ESX working
>> under QEMU is to add something to vmport as opposed to disabling it
>> altogether.
>>     
>
> I think that's highly unlikely unless all real PC BIOSes support vmport?
>   

ESX explicitly supports running under workstation.  It's likely using 
vmport to probe the fact that it is running under workstation.  
Presumably, it may be a bit less picky about what it's running on if it 
thinks it's running under workstation.

So this is why I don't think this is highly unlikely.

Regards,

Anthony Liguori