[virt-tools-list] [PATCH v2 3/3] Add support for cpu host-passthrough mode

[Cole Robinson]

On 07/24/2013 06:39 AM, Hu Tao wrote:
> On Wed, Jul 24, 2013 at 08:30:12AM +0200, Jiri Denemark wrote:
>> On Wed, Jul 24, 2013 at 13:48:24 +0800, Hu Tao wrote:
>>> Added: Jiri Denemark <jdenemar at redhat.com>
>>>
>>> On Sun, Apr 14, 2013 at 01:45:35PM -0400, Cole Robinson wrote:
>>>> On 04/12/2013 05:50 AM, Guannan Ren wrote:
>>>>> On 04/11/2013 01:45 PM, Hu Tao wrote:
>>>>>> From: Ken ICHIKAWA <ichikawa.ken at jp.fujitsu.com>
>>>>>>
>>>>>> We couldn't use host-passthrough mode for virtual cpu from
>>>>>> virt-manager so far. This patch enables virt-manager to
>>>>>> configure host-passthrough mode.
>> ...
>>>> So here I'm not sure we even want host-passthrough in the virt-manager UI. I
>>>> know it's valuable and useful, but there's the problem that libvirt 'taints'
>>>> the VM when you set this flag. This doesn't really have any functional effect,
>>>> but it basically means that libvirt devs consider this option to be not all
>>>> that supportable.
>>>
>>> Yes. But what if user knows the risk and just want the option? We can
>>> explicitly state that this option may not be well supported.
>>
>> Yeah, the reason for tainting the domain is that the environment is
>> generally unreproducible on another host and thus it complicates
>> investigation if something breaks. By tainting such domain, libvirt
>> basically says the user is on their own and if it doesn't work and the
>> failure cannot be reproduced without -cpu host, we may refuse to deal
>> with it (depending on the nature of that failure of course).
>>
>>>>                   Exposing it in the UI seems like going against libvirt's wishes.
>>>
>>> libvirt supports it in xml, so I don't think this is a problem.
>>
>> From libvirt's POV I don't see a reason for virt-manager not to allow
>> this configuration if it explicitly states that doing so is fragile, the
>> domain may crash and burn after migration, etc. So it really depends if
>> that is something which fits into virt-manager's goals or not.
>>
>>>> It's also quite hard to explain host-model vs host-passthrough to an end user.
>>>> We could just throw them in a combo box, but I guarantee it will have people
>>>> asking over and over what the difference between host-model and
>>>> host-passthrough is.
>>
>> Which might actually be the real reason for not allowing
>> host-passthrough to be set using virt-manager.
> 
> I don't think this is a strong reason to against host-passthrough in
> virt-manager. What's your opinion, Cole?
> 

As long as libvirt is 'tainting' a VM with host-passthrough, I think that's a
pretty clear indication that it's a bad idea to put it in the UI where a user
who doesn't know what they are doing might turn it on. It's why we don't
expose qemu command line passthrough in UI, and never will.

Isn't the long term plan for host-model to do _everything_ that
host-passthrough does anyways? If so, I'd rather just wait for host-model to
catch up, and expose that. If I'm wrong on that, please correct me.

(this is another example of why we need a simple command line tool for editing
XML. virt-manager shouldn't have to expose _everything_, just the stuff that
makes sense for most end users. It should be as simple as 'virt-xml --connect
URI --domain foo --cpu host-passthrough'. Thankfully much of the work I've
been doing upstream recently will implementing this tool practically trivial.)

- Cole