[libvirt] [PATCH 0/3] A couple of UML-related fixes

I've been trying to get UML working for the last couple of days. As it stands, at least bridged networking doesn't work for me. I've got a fix, but I'm not sure I'm doing it right. I can get it to fail in three distinct ways: * With the current code, it seems that the tap device disappears almost immediately. This happens becuase the call to brAddTap includes an (int *)tapfd argument, so the tap device isn't persistent. A few lines after brAddTap, close(tapfd) is called and the tap device goes missing. * Passing a NULL tapfd argument to brAddTap and removing the call to close(tapfd) makes the tapfd persist, but when the uml domain attempts to bring up the interface, it fails with EBUSY. This turns out to be because brAddTap marks the tap device persistent, but doesn't close the fd, so both libvirt and uml have the fd open and that's doesn't work out well. * Finally, I tried passing the tapfd result back up the call chain so that I have a list of them that I could tell virExecDaemonize to keep open and then close them in libvirt after the fork. I think this is when I got EPERM when trying to bring the interface up in UML domain, but I'm not sure right now. Also, I've had problems connecting to the domain's console. These three patches seem to fix everything for me. Soren Hansen (3): Close fd's of persistent tap devices Make umlConnectTapDevice ask brAddTap for a persistent tap device. Remove wrong check for uml monitor response size src/uml/uml_conf.c | 6 +----- src/uml/uml_driver.c | 4 ---- src/util/bridge.c | 2 ++ 3 files changed, 3 insertions(+), 9 deletions(-)

On Thu, Aug 12, 2010 at 11:08:16AM +0200, Soren Hansen wrote:
I've been trying to get UML working for the last couple of days. As it stands, at least bridged networking doesn't work for me. I've got a fix, but I'm not sure I'm doing it right.
I can get it to fail in three distinct ways:
* With the current code, it seems that the tap device disappears almost immediately. This happens becuase the call to brAddTap includes an (int *)tapfd argument, so the tap device isn't persistent. A few lines after brAddTap, close(tapfd) is called and the tap device goes missing.
Yep, this is a regression we introduced. It definitely needs to be persistent.
* Passing a NULL tapfd argument to brAddTap and removing the call to close(tapfd) makes the tapfd persist, but when the uml domain attempts to bring up the interface, it fails with EBUSY. This turns out to be because brAddTap marks the tap device persistent, but doesn't close the fd, so both libvirt and uml have the fd open and that's doesn't work out well.
Ah, good point.
* Finally, I tried passing the tapfd result back up the call chain so that I have a list of them that I could tell virExecDaemonize to keep open and then close them in libvirt after the fork. I think this is when I got EPERM when trying to bring the interface up in UML domain, but I'm not sure right now.
Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (2)
-
Daniel P. Berrange
-
Soren Hansen