On Tue, Jul 16, 2013 at 05:42:00PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 16, 2013 at 11:50:10AM -0400, Colin Walters wrote: > > On Tue, 2013-07-16 at 15:59 +0100, Richard W.M. Jones wrote: > > > I'm not even sure > > > how to do that because we want the atomic behaviour of hard links, and > > > we want to have qemu running as a different user (for security, oh the > > > irony), so there's no other obvious way to code it. > > > > Can you link to or describe the relevant algorithm/code? The file > > https://github.com/openstack/nova/blob/master/nova/virt/disk/vfs/guestfs.py#L94 > > doesn't contain an obvious call to link(). > > Thanks for any input. It's this code below. The big comment at the > top explains roughly what's going on, but misses out a crucial detail: > If you are using libvirt in a certain way, then libvirtd [which runs > as root] will chown the 'kernel' and 'initrd' files to root.root. If > that chown didn't happen, then none of this would be a problem. > > https://github.com/libguestfs/libguestfs/blob/master/src/appliance.c#L68 I'll just add a bit about how the locking works in this code since it may not be obvious. There's a lock (building_lock) which stops two threads from the same process from entering the appliance building code in parallel. There's also a lock (fcntl held on the file 'checksums') which stops two processes owned by the same user from trying to rebuild the appliance in parallel. And different users have their own directory ($UID == euid is different), so those don't interfere. BUT after we've built the appliance, we have to pass it over (by reference to the filename) to qemu. Now qemu runs in its own sweet time a bit later on, and we can never know when qemu will actually read these files (and because qemu may run for an indefinitely long period of time, we can't block other processes here). That's where the hard link comes in: it gives qemu effectively its own copy of the kernel, initrd and root files, while letting us safely erase [the hard-linked alias] from another process. These files are huge so copying them isn't an alternative. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
