15:01:01 #startmeeting libvirt 15:01:02 Meeting started Tue May 27 15:01:01 2014 UTC and is due to finish in 60 minutes. The chair is danpb. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:05 The meeting name has been set to 'libvirt' 15:01:17 hello 15:01:21 o/ 15:01:39 o/ 15:01:53 ah, great, some people added some agenda items 15:02:01 o/ 15:02:19 Yeah, wouldn't want crickets chirping, now would we? 15:02:23 o/ 15:02:29 lets be traditional and begin at the beginning 15:02:43 #topic LXC boot from block device 15:02:56 vladikr: you added this item ....anything you want to say 15:03:20 danpb, thank you for the help with this 15:03:48 I'm a bit confused with what should actually be done regarding your last comment 15:04:25 o/ 15:04:27 i think that all we need is a bit more description about some of the supported scenarios 15:04:27 on checking the number of partitions in the volume 15:04:35 and shouldn't we do the same for images, in this case? 15:04:57 ie say that the change is only intended to work with the case of an unpartitioned block dev 15:05:29 and describe the security considerations inherent in mounting untrusted filesystems 15:05:52 vladikr: yes most of the comments there apply just as well to images 15:06:12 so you're spec is really just going to be describing the status quo 15:06:17 danpb, ah, I see, it's not about the actual implementation? they don't expect us to mount the device and look into how many partitions are there? 15:06:35 no, no, definitely not 15:06:47 just document what scenarios you intend to support with your change 15:07:00 danpb, ok :) thanks, I got it. 15:07:13 ok cool 15:07:37 #topic IPv6 Guest Configuration 15:07:49 thomasem: ^^ 15:08:16 So, s1rp and myself were messing around with IP configurations in the guest. Pretty much the scenario is the /etc/network/interfaces file is generated for the guest, and then cloud-init uses that. 15:09:18 We found that IPv6 was failing to get configured since, when it used an inet6 static configuration in the interfaces file, the upstart job was trying to change the following value via sysctl: net.ipv6.conf.eth0.autoconf=0 15:09:38 it appeared to be the case outlined in this bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/964882 from a couple years ago 15:09:49 hmmm, ok, interesting problem 15:09:56 Libvirt mounts /proc/sys as readonly 15:10:04 So, I'm wondering 15:10:35 so the mounting of /proc/sys readonly is mostly considered security-through-obscurity - it only ever really prevented accidental changes 15:10:53 hmm okay 15:11:05 real security requried that SELinux/AppArmour prevent the changes, or for user namespaces to be active 15:11:25 right, so we made a change that just made /proc/sys/net RW, but left everything else RO 15:11:29 So, that's what I'm wondering... with the appropriate documentation, could we change that and assume that if you want that security, you'll use namespaces? 15:11:44 based on the documented way to secure containers :) 15:12:16 I found that when I changed the host value, it wasn't reflected in the guest, so the guest seems to have its own set of values, at least in /proc/sys/net. 15:12:20 so the problem is that some stuff in /proc/sys/net is host-global while some stuff is namespace-local 15:12:24 oh 15:12:50 when user namespaces are active we'd need to figure out how to allow access - presumably we'd have the chown the files we need to grant acess for 15:13:52 thomasem: oh, hmm, i thought that only the tunables related to network interfaces were made local, but perhaps the kernel does more than i thought 15:14:23 in any case, doing a read-write mount is easy enough in libvirt for the non-userns case 15:14:28 danpb: I didn't test thoroughly, or anything, I just know that the value it was trying to set when configuring IPv6 wasn't the shared between host and guest. 15:14:52 s/the// 15:14:55 we'll need to check what we can do in the user-namespace case - hopefully chown would work 15:15:30 this is probably something we should just take to the upstream libvirt mailing list, since i think any fix belongs in the libvirt layer 15:15:38 agreed 15:15:40 I'll do that 15:15:59 and any place where chown does not suffice might require kernel fix (i.e. s/capable/ns_capable in sysctl handler) 15:16:45 hallyn: yep, good point 15:17:25 +1 15:17:49 Okay, I'll write up an e-mail when I get a chance with some gists and what-not to help the discussion and fire off to the libvirt upstream ML 15:17:55 ok, great 15:18:15 #topic Config drive with LXC 15:18:37 yeah, so we want to be able to pass info into the guests, just like the hypervisor case 15:18:56 yep, use case totally makes sense 15:18:57 seems like there are two possible approaches, blockstyle and fs-style 15:19:14 i've already done fs-style, using a plain-old directory that gets bind mounted 15:19:28 but for the upstream patch, i'm thinking that block-style would be more 'harmonious' with the other hypervisors 15:19:39 since it doesn't introduce another config-drive backend 15:19:44 hmmm, i could see that fs-style is more convenient for containers though 15:19:51 it really is 15:19:58 and it's a very small patch 15:20:01 because if your container image is a single app binary that is launched as init 15:20:17 then you don't need to worry about having a shell wrapper script to mount the config drive and so forth 15:20:30 openstack just takes care of making it immediately accessible to the app 15:21:06 FWIW, a FS style approach is not totally unreasonable for hypervisors too 15:21:19 KVM has 9p filesystem passthrough from the host, and vmware has a shared filesystem capability too 15:21:45 s1rp: Maybe we should toss that patch upstream and see where it goes? 15:22:01 so I think it is pretty reasonable for openstack to support both FS-style and block-style config drives 15:22:06 danpb: good poiints 15:22:09 thomasem: yeah, can do 15:22:36 i can toss up the patch, wonder if i need to retroactively create a spec 15:22:40 i think FS style approach would probably appeal to docker people too 15:22:43 it's so simple, i hope not 15:22:49 It's like 3 lines of code, lol. 15:22:56 pretty awesome, imo. 15:23:02 i think you do need to have a spec 15:23:18 if only to let us bikeshed about the "best" mount point for the config drive 15:23:42 Haha, well by default cloud-init looks in /var/lib/cloud/seed/config_drive 15:23:55 and to allow us to explain why it is conceptually useful for multiple hypervisors, even if we don't intend to implement fs-approach for others 15:24:12 yeah have it hard coded to config-drive's preferred dest, but could make it configurable 15:24:14 thomasem: ah, well that's something to say in the spec :-) 15:24:17 with cloud-init the option's default 15:24:23 definitely 15:25:53 cool cool, s1rp, I'll work with you on that 15:26:04 good, sounds like a plan 15:26:17 #topic Any other business ? 15:26:32 ....we're out of agenda items now... so speak up if you've anything else to add 15:26:50 so remove-fakelibvirt turned out to be pretty contraversial 15:27:03 busy at the moment, so holding off for a bit, hope to get to it later in the cycle 15:27:05 lol, yeah 15:27:37 it isn't really blocking anything on critical path, so no particular rush 15:27:50 yeah exactly, just sort of a nice-to-have 15:28:06 but johannes had a good point about trying to figure out what's expected across hypervisors testing-wise 15:28:21 right not it's very ad hoc, some integration tests, some unit, etc 15:28:41 How're they going to figure that out? 15:28:56 or we, rather... not sure what all's involved there. :) 15:29:02 yeah, its kind of fuzzy 15:29:04 guessing we just need a ML thread to hash it out 15:29:08 Gotcha 15:29:11 i was always rather under the impression that its primarily unit testing 15:29:26 so i think it's mostly integration tests under the guise of unit-tests 15:29:28 but that we need the real libvirt module around, so we can access module constants & the like 15:29:38 i think we have very few true unit-tests 15:29:53 but that's a whole can-of-worms :) 15:30:05 s1rp: the stuff in nova/tests/virt/libvirt isn't actually making changes against the real hypervisors though is it ? 15:30:06 Yeah... 15:30:14 s1rp: true unit tests turn out to have tons of @patch's in nova >_> 15:30:27 Lol! Boy, do they. 15:30:29 i mean it might connect to the hypervisor, but its stubbing out the real interesting APIs to avoid hitting the host 15:31:09 danpb: yeah, we're not hitting the real hypervisor, but we're making very high-level calls and then asserting stuff at a very low-level (via fakelibvirt or fakexenapi), so we're testing multiple 'units' 15:31:46 ok, right, i see what you mean 15:32:17 i guess i was still thinking of that as unit testing but I see why you might call it integration testing 15:32:47 yeah consistent terminology is probably half-the-battle 15:33:03 so many of the discussions about this, we end up talking past each other 15:33:32 yeah, i can imagine 15:34:02 anyhow, I guess we can end this meeting now 15:34:24 thanks to all for coming, see you same time / place next week 15:34:32 o/ 15:34:36 thanks 15:34:40 Thanks! o/ 15:34:50 thanks 15:34:58 #endmeeting