blob: b32c0ab67a4c69e093193ae6dc1237ea9d82e20a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
network: 0.812
socket: 0.755
device: 0.684
mistranslation: 0.673
virtual: 0.535
graphic: 0.502
semantic: 0.455
ppc: 0.356
peripherals: 0.353
performance: 0.319
arm: 0.313
PID: 0.308
boot: 0.300
i386: 0.293
permissions: 0.293
kernel: 0.281
risc-v: 0.258
vnc: 0.242
x86: 0.209
TCG: 0.205
debug: 0.198
register: 0.166
architecture: 0.138
hypervisor: 0.108
VMM: 0.094
files: 0.085
KVM: 0.056
assembly: 0.044
user-level: 0.041
Ability to use -net socket with unix sockets
It would be a nice feature (simplifying access control for example) to be able to do something like:
qemu -net socket,listen=unix:/tmp/qemunet
qemu -net socket,connect=unix:/tmp/qemunet
For now one has to use TCP connections even for guests running on the same host, which involves setting up iptables to restrict access.
Aren't these at different levels of the stack? Network devices deal in packets not connections. It sounds like you want to use something like vsock which provides a virtual socket device to the guest.
This is just about connecting the NIC backends for 2 QEMUs together using a UNIX socket, instead of the current TCP/UDP socket. It should be fairly trivial to support i would expect. Though ideally we'd port the netdev socket backend to use QIOChannel too
This is an automated cleanup. This bug report got closed because it
is a duplicate.
|