qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dor Laor
Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted
Date: Fri, 09 Jan 2009 01:14:33 +0200
User-agent: Thunderbird 2.0.0.18 (X11/20081119)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]