A new direction for vmchannel?
The userspace configuration aspects of the current implementation of vmchannel are pretty annoying. Moreover, we would like to make use of something like vmchannel in a kernel driver and I fear that it's going to be difficult to do that.
So here's an alternative proposal.
Around 2.6.27ish, Eric and I added 9p over virtio support to v9fs. This is all upstream. We backported the v9fs modules all the way back to 2.6.18. I have a 9p client and server library and patches available for QEMU. We were using this for a file system pass through but we could also use it as a synthetic file system in the guest (like sysfs).
The guest would just have to mount a directory in a well known location, and then you could get vmchannel like semantics by just opening a file read/write. Better yet though would be if we actually exposed vmchannel as 9p so that management applications could implement sysfs-like hierarchies.
I think there could be a great deal of utility in something like. For portability to Windows (if an app cared), it would have to access the mount point through a library of some sort. We would need a Windows virtio-9p driver that exposed the 9p session down to userspace. We could then use our 9p client library in the portability library for Windows.
Virtually all of the code is available for this today, the kernel bits are already upstream, there's a reasonable story for Windows, and there's very little that the guest can do to get in the way of things.
The only thing that could potentially be an issue is SELinux. I assume you'd have to do an SELinux policy for the guest application anyway though so it shouldn't be a problem.
Thoughts?
Regards,
Anthony Liguori
Quoted 4 lines · * Anthony Liguori ([email protected]) wrote:
The userspace configuration aspects of the current implementation of vmchannel are pretty annoying. Moreover, we would like to make use of something like vmchannel in a kernel driver and I fear that it's going to be difficult to do that.
What's the use for vmchannel from kernel driver?
Quoted 25 lines
So here's an alternative proposal.
Around 2.6.27ish, Eric and I added 9p over virtio support to v9fs. This is all upstream. We backported the v9fs modules all the way back to 2.6.18. I have a 9p client and server library and patches available for QEMU. We were using this for a file system pass through but we could also use it as a synthetic file system in the guest (like sysfs).
The guest would just have to mount a directory in a well known location, and then you could get vmchannel like semantics by just opening a file read/write. Better yet though would be if we actually exposed vmchannel as 9p so that management applications could implement sysfs-like hierarchies.
I think there could be a great deal of utility in something like. For portability to Windows (if an app cared), it would have to access the mount point through a library of some sort. We would need a Windows virtio-9p driver that exposed the 9p session down to userspace. We could then use our 9p client library in the portability library for Windows.
Virtually all of the code is available for this today, the kernel bits are already upstream, there's a reasonable story for Windows, and there's very little that the guest can do to get in the way of things.
Quoted 5 lines
The only thing that could potentially be an issue is SELinux. I assume you'd have to do an SELinux policy for the guest application anyway though so it shouldn't be a problem.
Thoughts?
Heh, works for me ;-) Last time I suggested an fs it got shot down due to the burden it puts on the guest implementation (notably windows and other guests and ease of adding a new fs implementation).
Doesn't directly solve addressing (IOW, easy to do with hierarchical namespace, but if vmchannel ever talks guest-to-guest...). Clearly not a huge issue.
Should handle the reliable messaging bit (one big push for using tcp), and has advantage of being a structured protocol.
Has the similar ABI issue that we see in Linux with sysfs, namely it's easy to screw up...but that is manageable.
BTW, what ever happened to just using a serial device (granted needs some protocol layered on top...)?
thanks,
-chris
Quoted 7 lines · Chris Wright
Quoted 2 lines · * Anthony Liguori ([email protected]) wrote:
The userspace configuration aspects of the current implementation of vmchannel are pretty annoying. Moreover, we would like to make use of something like vmchannel in a kernel driver and I fear that it's going to be difficult to do that.
What's the use for vmchannel from kernel driver?
Well, it doesn't exactly have to be vmchannel, but the desire is to have the management tools to be able to communicate directly with a kernel driver. We could certainly just use virtio and route it through QEMU to the management tool. It would be useful to just use vmchannel though.
Quoted 11 lines
Quoted 2 lines
Thoughts?
Heh, works for me ;-) Last time I suggested an fs it got shot down due to the burden it puts on the guest implementation (notably windows and other guests and ease of adding a new fs implementation).
Doesn't directly solve addressing (IOW, easy to do with hierarchical namespace, but if vmchannel ever talks guest-to-guest...). Clearly not a huge issue.
Quoted 9 lines
Should handle the reliable messaging bit (one big push for using tcp), and has advantage of being a structured protocol.
Has the similar ABI issue that we see in Linux with sysfs, namely it's easy to screw up...but that is manageable.
BTW, what ever happened to just using a serial device (granted needs some protocol layered on top...)?
I think you end up having a lot of the same issues with respect to making it transparent to the guest. You could still do 9p over serial and still use a synthetic file system in the guest. In fact, this is a pretty reasonable thing to do for older kernel guests and even Windows.
Regards,
Anthony Liguori
Quoted 7 lines
thanks,
-chris
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Anthony Liguori
Thoughts?
Looks good, but I am not to much familiar with p9. Will it provide us with stream semantics? How much work is needed to support this in Windows (what is your estimation)? Will migration be transparent to in guest users?
--
Gleb.
Quoted 7 lines · Gleb Natapov
Quoted 3 lines · Anthony Liguori
Thoughts?
Looks good, but I am not to much familiar with p9. Will it provide us with stream semantics?
Sure. It has read and write operations. You just have to implement them in the same sort of way you'd implement them for a character device.
Quoted 2 lines
How much work is needed to support this in
Windows (what is your estimation)?
If you structure your guest applications to use a library, sort of like libsysfs, then on Windows, you could implement a 9P client in userspace. I have a 9P client that can be used for this. You just need some way to get the stream to userspace. You could write a virtio windows driver that exposed the stream down to userspace. You could also use an alternative transport for Windows (like a serial port).
Quoted 3 lines
Will migration be transparent to
in guest users?
There's no better migration story for vmchannel backends implemented outside of QEMU. For the ones in QEMU, migration should be transparent.
Regards,
Anthony Liguori
Quoted 3 lines
--
Gleb.
Quoted 10 lines · Anthony Liguori
Quoted 7 lines · Gleb Natapov
Quoted 3 lines · Anthony Liguori
Thoughts?
Looks good, but I am not to much familiar with p9. Will it provide us with stream semantics?
Sure. It has read and write operations. You just have to implement them in the same sort of way you'd implement them for a character device.
So why not having a virtio pv-serial device.
Above this device/driver users can have several implementations/semantics:
- raw messages
- 9p
- userspace tcp/ip
- We already used the host part of it.
- It provides reliability and handles migration too.
- Since its userspace, there is no routing/addressing involved.
The above will make windows and other OSs happy and users can still get 9p or tcp or raw. Maybe even the virtio console can be based over it (Don't really know nothing about it )
btw: I do suggest to keep the former work of nic based vmchannel. Except for the cmdline, every thing else is committed. It might be good for older OSs and just work out of the box.
Quoted 22 lines
Quoted 3 lines
How much work is needed to support this in
Windows (what is your estimation)?If you structure your guest applications to use a library, sort of like libsysfs, then on Windows, you could implement a 9P client in userspace. I have a 9P client that can be used for this. You just need some way to get the stream to userspace. You could write a virtio windows driver that exposed the stream down to userspace. You could also use an alternative transport for Windows (like a serial port).
Quoted 3 lines
Will migration be transparent to
in guest users?There's no better migration story for vmchannel backends implemented outside of QEMU. For the ones in QEMU, migration should be transparent.
Regards,
Anthony Liguori
Quoted 3 lines
Signature · 1 line
Gleb.
Quoted 12 lines · Dor Laor
Quoted 10 lines · Anthony Liguori
Quoted 7 lines · Gleb Natapov
Quoted 3 lines · Anthony Liguori
Thoughts?
Looks good, but I am not to much familiar with p9. Will it provide us with stream semantics?
Sure. It has read and write operations. You just have to implement them in the same sort of way you'd implement them for a character device.
Quoted 10 lines
So why not having a virtio pv-serial device.
Above this device/driver users can have several implementations/semantics:
- raw messages
- 9p
- userspace tcp/ip
- We already used the host part of it.
- It provides reliability and handles migration too.
- Since its userspace, there is no routing/addressing involved.
The above will make windows and other OSs happy and users can still get 9p or tcp or raw. Maybe even the virtio console can be based over it (Don't really know nothing about it )
I don't see where there's any benefit here. You need a driver in the guest for virtio either way - and what exactly goes to userspace ( fs or datagram protocol ) is an implementation detail, no?
Alex
Quoted 33 lines
btw: I do suggest to keep the former work of nic based vmchannel. Except for the cmdline, every thing else is committed. It might be good for older OSs and just work out of the box.
Quoted 10 lines
Quoted 3 lines
How much work is needed to support this in
Windows (what is your estimation)?If you structure your guest applications to use a library, sort of like libsysfs, then on Windows, you could implement a 9P client in userspace. I have a 9P client that can be used for this. You just need some way to get the stream to userspace. You could write a virtio windows driver that exposed the stream down to userspace. You could also use an alternative transport for Windows (like a serial port).
Quoted 3 lines
Will migration be transparent to
in guest users?Quoted 12 lines
There's no better migration story for vmchannel backends implemented outside of QEMU. For the ones in QEMU, migration should be transparent.
Regards,
Anthony Liguori
Quoted 3 lines
Signature · 1 line
Gleb.--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 25 lines · Anthony Liguori
The userspace configuration aspects of the current implementation of vmchannel are pretty annoying. Moreover, we would like to make use of something like vmchannel in a kernel driver and I fear that it's going to be difficult to do that.
So here's an alternative proposal.
Around 2.6.27ish, Eric and I added 9p over virtio support to v9fs. This is all upstream. We backported the v9fs modules all the way back to 2.6.18. I have a 9p client and server library and patches available for QEMU. We were using this for a file system pass through but we could also use it as a synthetic file system in the guest (like sysfs).
The guest would just have to mount a directory in a well known location, and then you could get vmchannel like semantics by just opening a file read/write. Better yet though would be if we actually exposed vmchannel as 9p so that management applications could implement sysfs-like hierarchies.
I think there could be a great deal of utility in something like. For portability to Windows (if an app cared), it would have to access the mount point through a library of some sort. We would need a Windows virtio-9p driver that exposed the 9p session down to userspace. We could then use our 9p client library in the portability library for Windows.
Quoted 7 lines
Virtually all of the code is available for this today, the kernel bits are already upstream, there's a reasonable story for Windows, and there's very little that the guest can do to get in the way of things.
The only thing that could potentially be an issue is SELinux. I assume you'd have to do an SELinux policy for the guest application anyway though so it shouldn't be a problem.
For use cases where you are exposing metadata from the host to the guest this would be a very convenient approach indeed. As asked elsewhere in this thread, my main thought would be about how well it suits a application that wants a generic stream based connection between host & guest ? Efficient integration into a poll(2) based event loop would be key to that. Regular files don't offer that kind of ability ordinarily, and not clear whether fifo's would be provided for in p9fs between host/guest ?
In any case, if we have a usable p9fs backend for QEMU, I don't see why we shouldn't integrate that in QEMU, regardless of whether it serves the more general vmchannel use cases. Sharing filesystems is an interesting idea in its own right after all.
I also really don't like guest deployment / configuration complexity that is accompanying the NIC device based vmchannel approach. There are just far too many things that can go wrong with it wrt the guest OS & apps using networking. IMHO, the core motivation of vmchannel is to have a secure guest <-> host data transport that can we relied upon from the moment guest userspace appears, preferrably with zero guest admin configuration requirements, and no need for authentication keys to establish guest identity. UNIX domain sockets are a great example of this ideal, providing a reliable data stream for the localhost before network makes any appearance, with builtin client authentication via SCM_CREDS.
Regards,
Daniel
Signature · 4 lines
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Quoted 14 lines · Daniel P. Berrange
Quoted 12 lines · Anthony Liguori
The userspace configuration aspects of the current implementation of vmchannel are pretty annoying. Moreover, we would like to make use of something like vmchannel in a kernel driver and I fear that it's going to be difficult to do that.
So here's an alternative proposal.
Around 2.6.27ish, Eric and I added 9p over virtio support to v9fs. This is all upstream. We backported the v9fs modules all the way back to 2.6.18. I have a 9p client and server library and patches available for QEMU. We were using this for a file system pass through but we could also use it as a synthetic file system in the guest (like sysfs).
The guest would just have to mount a directory in a well known location, and then you could get vmchannel like semantics by just opening a file read/write. Better yet though would be if we actually exposed vmchannel as 9p so that management applications could implement sysfs-like hierarchies.
I think there could be a great deal of utility in something like. For portability to Windows (if an app cared), it would have to access the mount point through a library of some sort. We would need a Windows virtio-9p driver that exposed the 9p session down to userspace. We could then use our 9p client library in the portability library for Windows.
Virtually all of the code is available for this today, the kernel bits are already upstream, there's a reasonable story for Windows, and there's very little that the guest can do to get in the way of things.
Quoted 7 lines
Quoted 2 lines
The only thing that could potentially be an issue is SELinux. I assume you'd have to do an SELinux policy for the guest application anyway though so it shouldn't be a problem.
For use cases where you are exposing metadata from the host to the guest
this would be a very convenient approach indeed. As asked elsewhere in this
thread, my main thought would be about how well it suits a application that
wants a generic stream based connection between host & guest ? Efficient integration into a poll(2) based event loop would be key to that.
You mean for a very large number of files (determining which property has changed?).
The way you would do this today, without special inotify support, is to have a special file in the hierarchy called "change-notify". You can write a list of deliminated files and whenever one of those files becomes readable, the file itself will become readable (returning a deliminated list of files that have changed since last read).
This way, you get a file you can select on for a very large number of files. That said, it would be nice to add proper inotify support to v9fs too.
Quoted 3 lines
Regular
files don't offer that kind of ability ordinarily, and not clear whether fifo's would be provided for in p9fs between host/guest ?
I'm going to put together a patch this weekend and I'll include a streaming example. Basically, you just ignore the file offset and read/write to the file to your heart's content.
Regards,
Anthony Liguori
Quoted 12 lines
In any case, if we have a usable p9fs backend for QEMU, I don't see why we shouldn't integrate that in QEMU, regardless of whether it serves the more general vmchannel use cases. Sharing filesystems is an interesting idea in its own right after all.
I also really don't like guest deployment / configuration complexity that
is accompanying the NIC device based vmchannel approach. There are just far too many things that can go wrong with it wrt the guest OS & apps using
networking. IMHO, the core motivation of vmchannel is to have a secure guest <-> host data transport that can we relied upon from the moment guest userspace appears, preferrably with zero guest admin configuration requirements, and no need for authentication keys to establish guest identity. UNIX domain sockets are a great example of this ideal, providing a reliable data stream for the localhost before network makes any appearance, with builtin client authentication viaSCM_CREDS.Regards,
Daniel
Quoted 10 lines · Anthony Liguori
Quoted 6 lines
For use cases where you are exposing metadata from the host to the guest this would be a very convenient approach indeed. As asked elsewhere in this thread, my main thought would be about how well it suits a application that wants a generic stream based connection between host & guest ? Efficient integration into a poll(2) based event loop would be key to that.
You mean for a very large number of files (determining which property has changed?).
I think what Daniel means is that for file to have stream semantic it is not enough to ignore offset on read/write, but poll also should behave similar to how it behaves with char device fd. With regular files poll will always report that fd is ready for I/O.
--
Gleb.
Quoted 7 lines · Gleb Natapov
Quoted 5 lines · Anthony Liguori
Quoted 5 lines
For use cases where you are exposing metadata from the host to the guest
this would be a very convenient approach indeed. As asked elsewhere in this
thread, my main thought would be about how well it suits a application that
wants a generic stream based connection between host & guest ? Efficient integration into a poll(2) based event loop would be key to that.
Quoted 8 lines
Quoted 3 lines
You mean for a very large number of files (determining which property has changed?).
I think what Daniel means is that for file to have stream semantic it is not enough to ignore offset on read/write, but poll also should behave similar to how it behaves with char device fd. With regular files poll will always report that fd is ready for I/O.
I'm not really sure, but given the 9P protocol, I suspect it would have to. Eric?
Regards,
Anthony Liguori
Quoted 3 lines
--
Gleb.
Quoted 7 lines · Gleb Natapov
Quoted 5 lines · Anthony Liguori
Quoted 5 lines
For use cases where you are exposing metadata from the host to the guest
this would be a very convenient approach indeed. As asked elsewhere in this
thread, my main thought would be about how well it suits a application that
wants a generic stream based connection between host & guest ? Efficient integration into a poll(2) based event loop would be key to that.
Quoted 8 lines
Quoted 3 lines
You mean for a very large number of files (determining which property has changed?).
I think what Daniel means is that for file to have stream semantic it is not enough to ignore offset on read/write, but poll also should behave similar to how it behaves with char device fd. With regular files poll will always report that fd is ready for I/O.
Thinking more about this, the difficulty is that poll() only has useful semantics when you're dealing with a buffered stream of some sort. That is, poll() is only really capable of asking whether there is data pending in your read buffer.
With 9P, you have to explicitly send a read request. You can implement buffered IO by simply sending constant read requests such that there is always one read request pending. I don't think it's useful to do this in the kernel.
Unfortunately, there's no way to do async IO in userspace that doesn't suck so that would make this pretty difficult. We could use a thread pool, but that's somewhat soul crushing and doesn't scale well. I think that puts a requirement on v9fs to support linux-aio.
Regards,
Anthony Liguori
Quoted 3 lines
--
Gleb.
Quoted 9 lines · Anthony Liguori
Thinking more about this, the difficulty is that
poll()only has useful semantics when you're dealing with a buffered stream of some sort. That is,poll()is only really capable of asking whether there is data pending in your read buffer.With 9P, you have to explicitly send a read request. You can implement buffered IO by simply sending constant read requests such that there is always one read request pending. I don't think it's useful to do this in the kernel.
In linux/Documentation/fs/9p.txt:
nodevmap do not map special files - represent them as normal files.
This can be used to share devices/named pipes/sockets between hosts. This functionality will be expanded in later versions.
Does this mean it can provide the semantics of a named pipe or unix domain socket over 9p?
Both would provide suitable poll() behaviour. A unix domain socket sounds especially useful, practically a drop in replacement for the current network vmchannel, without configuration downsides.
But what about non-Linux guests?
Quoted 4 lines
Unfortunately, there's no way to do async IO in userspace that doesn't suck so that would make this pretty difficult. We could use a thread pool, but that's somewhat soul crushing and doesn't scale well. I think that puts a requirement on v9fs to support linux-aio.
It sounds like a weird mashup of unix regular file behaviour and unix socket behaviour. Poll doesn't work, aio might, but you can read/write like a stream? Very un-unix.
Even if it can be made to work, that's sufficiently un-unix to reduce its general utility with existing scripting languages, existing monitoring programs etc.
-- Jamie
Quoted 7 lines · Jamie Lokier
Quoted 4 lines · Anthony Liguori
Thinking more about this, the difficulty is that
poll()only has useful semantics when you're dealing with a buffered stream of some sort. That is,poll()is only really capable of asking whether there is data pending in your read buffer.With 9P, you have to explicitly send a read request. You can implement buffered IO by simply sending constant read requests such that there is always one read request pending. I don't think it's useful to do this in the kernel.
Quoted 9 lines
In
linux/Documentation/fs/9p.txt:nodevmap do not map special files - represent them as normal files.
This can be used to share devices/named pipes/sockets between hosts. This functionality will be expanded in later versions.Does this mean it can provide the semantics of a named pipe or unix domain socket over 9p?
Eric will have to correct me if I'm wrong, but I believe that that bit of functionality is not yet implemented (although it's been discussed).
Quoted 2 lines
But what about non-Linux guests?
The plan for non-Linux guests is to expose the 9P protocol stream down to userspace and provide a library with posix-like file system semantics. For instance kvmfs_open(), kvmfs_read(), kvmfs_write(), etc. Applications that care about portability can use this library on Linux and non-Linux.
For non-Linux guests where we can get a kernel driver in, the driver will feed the 9P stream directly to userspace. For guests that we cannot get a kernel driver in, we can stream 9P to the guest via TCP, serial port, etc. This requires some config in the guest's userspace and may require some admin intervention but that's the price you pay for avoiding a kernel module.
Quoted 7 lines
Quoted 2 lines
Unfortunately, there's no way to do async IO in userspace that doesn't suck so that would make this pretty difficult. We could use a thread pool, but that's somewhat soul crushing and doesn't scale well. I think that puts a requirement on v9fs to support linux-aio.
It sounds like a weird mashup of unix regular file behaviour and unix socket behaviour. Poll doesn't work, aio might, but you can read/write like a stream? Very un-unix.
Right. We can certainly modify v9fs to make poll() behave more naturally.
Regards,
Anthony Liguori
Quoted 10 lines
Even if it can be made to work, that's sufficiently un-unix to reduce its general utility with existing scripting languages, existing monitoring programs etc.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 29 lines · Alexander Graf
Quoted 12 lines · Dor Laor
Quoted 10 lines · Anthony Liguori
Quoted 7 lines · Gleb Natapov
Quoted 3 lines · Anthony Liguori
Thoughts?
Looks good, but I am not to much familiar with p9. Will it provide us with stream semantics?
Sure. It has read and write operations. You just have to implement them in the same sort of way you'd implement them for a character device.
Quoted 10 lines
So why not having a virtio pv-serial device.
Above this device/driver users can have several implementations/semantics:
- raw messages
- 9p
- userspace tcp/ip
- We already used the host part of it.
- It provides reliability and handles migration too.
- Since its userspace, there is no routing/addressing involved.
The above will make windows and other OSs happy and users can still get 9p or tcp or raw. Maybe even the virtio console can be based over it (Don't really know nothing about it )
Quoted 2 lines
I don't see where there's any benefit here. You need a driver in the guest for virtio either way - and what exactly goes to userspace ( fs or datagram protocol ) is an implementation detail, no?
There are two benefits:
a. Simplify the kernel driver over virtio.
It does not need to implement 9p interface (important for non Linux)
or other.
It would be also possible to use the serial as a medium, so no
driver at all.
b. Flexibility - you're not bound to a specific solution.
One can use userspace tcp/ip over it, others will use 9p (which is
nice), etc.
IMO if the current 9p is mature and supports stream based poll semantics like was discussed, and is not too complex for Windows to implement we can use 9p.
Otherwise, let's go for a generic solution like pv serial using virtio.
- dor
Quoted 39 lines
Alex
Quoted 33 lines
btw: I do suggest to keep the former work of nic based vmchannel. Except for the cmdline, every thing else is committed. It might be good for older OSs and just work out of the box.
Quoted 22 lines
Quoted 3 lines
How much work is needed to support this in
Windows (what is your estimation)?If you structure your guest applications to use a library, sort of like libsysfs, then on Windows, you could implement a 9P client in userspace. I have a 9P client that can be used for this. You just need some way to get the stream to userspace. You could write a virtio windows driver that exposed the stream down to userspace. You could also use an alternative transport for Windows (like a serial port).
Quoted 3 lines
Will migration be transparent to
in guest users?There's no better migration story for vmchannel backends implemented outside of QEMU. For the ones in QEMU, migration should be transparent.
Regards,
Anthony Liguori
Quoted 3 lines
Signature · 1 line
Gleb.Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.htmlSignature · 3 lines
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · Anthony Liguori
Quoted 7 lines · Daniel P. Berrange
On Fri, Jan 23, 2009 at 08:45:33AM -0600, Anthony Liguori wrote:
For use cases where you are exposing metadata from the host to the guest this would be a very convenient approach indeed. As asked elsewhere in this thread, my main thought would be about how well it suits a application that wants a generic stream based connection between host & guest ? Efficient integration into a poll(2) based event loop would be key to that.
You mean for a very large number of files (determining which property has changed?).
Two aspects to main loop integration - for the filesystem as structured metadata use case, an efficient notifiction mechanism for discovering changes to files is key. For the stream based connection use case, obviously polling for incoming data / output write availabilty.
Quoted 9 lines
The way you would do this today, without special inotify support, is to have a special file in the hierarchy called "change-notify". You can write a list of deliminated files and whenever one of those files becomes readable, the file itself will become readable (returning a deliminated list of files that have changed since last read).
This way, you get a file you can select on for a very large number of files. That said, it would be nice to add proper inotify support to v9fs too.
There's probably two distinct user requirements here. For apps which need to implement something that'd work with vmchannel for both Linux and Windows guests, the special 'change-notify' file might be more convenient. For apps which want to work with native Linux APIs, then real inotify support would be desirable, since that's a standard interface across all filesystems in Linux.
Quoted 8 lines
Quoted 4 lines
Regular
files don't offer that kind of ability ordinarily, and not clear whether fifo's would be provided for in p9fs between host/guest ?I'm going to put together a patch this weekend and I'll include a streaming example. Basically, you just ignore the file offset and read/write to the file to your heart's content.
Basically my use case would be that you have an existing application that supports UNIX domain sockets, and / or TCP sockets, and you wish to also have it run acros the host <-> guest channel. Although we're not using sockets here, being able to easily integrate into an app written around a sockets model is the high level goal.
Daniel
Signature · 4 lines
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Quoted 6 lines · Daniel P. Berrange
Quoted 4 lines · Anthony Liguori
Quoted 4 lines
Regular
files don't offer that kind of ability ordinarily, and not clear whether fifo's would be provided for in p9fs between host/guest ?
Quoted 8 lines
Quoted 2 lines
I'm going to put together a patch this weekend and I'll include a streaming example. Basically, you just ignore the file offset and read/write to the file to your heart's content.
Basically my use case would be that you have an existing application
that supports UNIX domain sockets, and / or TCP sockets, and you wish
to also have it run acros the host <-> guest channel. Although we're
not using sockets here, being able to easily integrate into an app written around a sockets model is the high level goal.
It would be pretty trivial to have a small guest daemon that runs and makes a file system stream available as a unix socket. For instance, you would have:
/qemufs/org/libvirt/qemud/stream0
The daemon would create a unix socket, /qemufs/org/libvirt/qemud/stream0.sock, and would spawn a thread that constantly read from /qemufs/org/libvirt/qemud/stream0 providing the data in the stream0.sock's buffer. I think that's a pretty reasonable compromise if that interface is strongly required.
Maybe even just a library to provide that level of functionality? So you could have a function that was essentially vmc_open_as_stream("/org/libvirt/qemud/stream0") and the library would spawn a thread and create a unix domain socketpair() and return the appropriate end. That eliminates the need to have a daemon running.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
Quoted 2 lines
Daniel