Upstream QEMU stubdom: Difference between revisions
(Created page with "These are the TODO items. They don't need to be finished in that order. To make QEMU stubdom works we need to finish all of them. == Bootstrap guest to specific network topology…") |
No edit summary |
||
| Line 22: | Line 22: | ||
== Expose a host disk device as a guest disk device == |
== Expose a host disk device as a guest disk device == |
||
Looks like ETFS is sufficient |
Looks like ETFS is sufficient. It's a matter of passing the right options to rumprun. Performance is tied to underlying mini-os blkfront. |
||
== Communication channel between toolstack and rump kernel QEMU == |
== Communication channel between toolstack and rump kernel QEMU == |
||
Latest revision as of 14:56, 24 June 2015
These are the TODO items. They don't need to be finished in that order. To make QEMU stubdom works we need to finish all of them.
Bootstrap guest to specific network topology
Every virtual network device in QEMU requires a tap device. All interface should be bridged to the real network interface.
It would be good if there a way to run a sequence of commands like
ifconfig tap0 create
ifconfig bridge0 create
brconfig add tap0 bridge0
brconfig add xenif0 bridge0
...
Or at least provide an entry point for user to program rump kernel as stop-gap solution.
Use stable rumprun interface to interact with toolstack (libxl)
I need stable rumprun command line options to specify network topology as mentioned before. Xen toolstack will just call rumprun to launch QEMU stubdom.
It's OK for rumprun to evolve over time and have better syntax for things it does. We only need backward compatibility support. It's also OK to deprecate old command line options over time, just give downstream time to adjust (preferably a few releases).
Expose a host disk device as a guest disk device
Looks like ETFS is sufficient. It's a matter of passing the right options to rumprun. Performance is tied to underlying mini-os blkfront.
Communication channel between toolstack and rump kernel QEMU
The goal is to provide a channel for monitoring machinary to communicate with Xen toolstack.
According to QEMU manual, monitor can be piped to a character device (chardev). A chardev can be piped to a TCP socket. Rump kernel has TCP socket support, so for the moment we have a solution, it is just a matter of plumbing through the right options to QEMU, which is quite easy.
Martin mentioned that he is going to look into implementing libvchan in rump kernel. QEMU stubdom can switch to use that when it's ready.
