[et-mgmt-tools] Virtinst and blktap

[Michael DeHaan]

Cole Robinson wrote:
> Michael DeHaan wrote:
>   
>> Chris Lalancette wrote:
>>     
>>> Michael DeHaan wrote:
>>>   
>>>       
>>>> I had a user question about how they can specify blktap for Xen in 
>>>> Cobbler instead of the file driver (for performance reasons) ... well, 
>>>> it turns out they can't (yet).
>>>>
>>>> Under what conditions can we use blktap, and is that advisable?   (I had 
>>>> thought this might work like virtio, in which case, passing in the os 
>>>> version uses a table, but it seems this may only actually depend on the 
>>>> host and has no guest limitations?)
>>>>     
>>>>         
>>> That's exactly right.  It's a property of how the host OS accesses the disk on
>>> behalf of the domain, not of how the disk is presented to the domain.  In fact,
>>> for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct
>>> file: access can corrupt your guest domains on host crash.  The situation with
>>> FV domains is more complicated, but there, you can use file:, since it properly
>>> does flushing.
>>>
>>>   
>>>       
>>     
>>>> It looks like from the virtinst code I could just call 
>>>> utils.is_blktap_capable() from my libvirt-using application and if so, 
>>>> then pass the driver=DRIVER_TAP options to virstinst.
>>>>
>>>> Good idea?  Bad idea?
>>>>     
>>>>         
>>> The only reasonable default for Xen PV domains, in my opinion.
>>>
>>>   
>>>       
>> Thanks.
>>
>> FWIW the default behavior of python-virtinst seems to be to /not/ use 
>> blktap, and should probably be fixed then if there's a potential 
>> corruption problem.
>>
>> I haven't tested command line virt-install to see what it does.
>>
>>     
>
> That default is actually set in virt-install and virt-manager, but
> probably should have been moved into the virtinst library a long time ago.
>
> - COle
>   

Yeah, I can't keep up very well when stuff doesn't happen there :)

Should I make the fix in koan also or do you want to move it?

--Michael