|Subject:||Re: [Qemu-devel] [PATCH] mark nic as trusted|
|Date:||Fri, 09 Jan 2009 01:14:33 +0200|
|User-agent:||Thunderbird 126.96.36.199 (X11/20081119)|
Jamie Lokier wrote:
We can make fedora, rhel and libvirt support it. It might be a bit painful but sinceAnthony 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.
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.
Alternatively one can hot plug the vmchanneled nic, right after boot.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?
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.
We plan to pick link local subnets for ipv4.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?
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).
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|