Re: [Qemu-devel] [PATCH] mark nic as trusted

[Dor Laor <dlaor@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
>> Are we going to have a standard way of doing this in Linux distros such 
>> that these nics are treated differently from other nics?  Have we gotten 
>> the appropriate distro folks to agree to this?
>>     
>
> That wouldn't work for older distros and Windows anyway.  But you
> might reasonably want to run apps doing guest-host communication on
> older guest distros too, simply as an app, not requiring guest
> customisation.
>   
We can make fedora, rhel and libvirt support it. It might be a bit 
painful but since
a network device was chosen for this propose then that's the right way 
to go.
Others can either use 3rd agents to cancel firewalls like we plan to do 
for windows,
or as was suggested, change the pci device id and load a bit different 
driver.

You suggestion is good also since it will be good for personal usages where
the guest can easily reach the host network and the user can easily 
cancel firewalls.

> Is there some way to mark a PCI device so it will be ignored at boot
> time generically?  Changing the PCI ID will do that for all guests,
> but is it then feasible for the vmchannel guest admin software to bind
> a NIC driver to a non-standard PCI ID, on the major OSes?
>   
Alternatively one can hot plug the vmchanneled nic, right after boot.
IMHO I rather stick with guest mgmt agent take care of the accesses to 
the nic.
> Suppose you start a guest with two "trusted" nics, because you want to
> run two unrelated vmchannel-using admin apps.  How does each app know
> which nic to use - or do they share it?
>
>   

Each vmchannel is bond on the host to a separate pair of qemu_chr_device and
a matching ip:port listening. So if there are n agents in the guest, 
each should
connect to his ip:port without being aware to the others.
> As the guest OS's TCP is being used, what do you do about IP address
> space conflicts?
>
> I.e. if NIC #1 is the guest's LAN, and NIC #2 is the vmchannel, how is
> the vmchannel NIC going to be configured in a way that's guaranteed to
> avoid breaking the LAN networking, which could be assigned any legal
> subnet (especially when bridging is used), and on some networks
> changes from time to time?
>
> Perhaps vmchannel will only use IPv6, so it can confidently pick a
> unique link-local address?
>
>   
We plan to pick link local subnets for ipv4.
It solved all the above questions. It should be connected to slirp 
without passing through
the host stack/bridges (although it can be open too).
> -- Jamie
>
>
>   

w.r.t the option of using virtio nic, there is advantage of using any 
other nic since this way
there is no requirement to install virtio driver on windows or on other 
older Linux/other OSs.

[-- Attachment #2: Type: text/html, Size: 3588 bytes --]