Meetings/Libvirt/Minutes/20140527
< Meetings | Libvirt
Revision as of 15:38, 27 May 2014 by Daniel Berrange (talk | contribs) (Created page with "=Libvirt Sub-Team Meeting= ==Agenda: 2014/05/27== Please put your full name + IRC nick against any agenda items you add * libvirt: start LXC from a block device volume - http...")
Libvirt Sub-Team Meeting
Agenda: 2014/05/27
Please put your full name + IRC nick against any agenda items you add
- libvirt: start LXC from a block device volume - https://review.openstack.org/88062 - (Vladik Romanovsky, vladikr)
- Confused with what should be actually done.
- IPv6 Guest Configuration with /proc/sys mounted read-only (Thomas Maddox / thomasem)
- https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/964882
- Workarounds checked (both worked, the latter seems to maintain the limitation that we still can't use the inet6 static configuration in /etc/network/interfaces):
- Mounting /proc/sys/net as RW via Libvirt patch (tried this and it worked, just need to discuss security implications...) (danpb mentions that some settings are host local and some are namespace local)
- Using a post-up configuration to run ifconfig IPv6 net addr configurations and route to add gateway (desired as it doesn't require Libivrt patch, afaik)
- The R/O mount was mostly security through obsecurity - only SELinux/APpArmour/UserNS provide any real security
- Curious about long-term solution; do network namespaces fix the problem the read-only mount aimed to prevent?
- Need to figure out what bits of sysfs must be chown'd for userns
- Might be kernel bugs lurking where the kernel sysfs handler uses capable vs ns_capable()
- Action Item: Take this to the libvirt mailing list
- Config-Drive with Libvirt LXC (Rick Harris / s1rp)
- WHY: Config-drive allows us to pass networking configuration into guest and perform file-injection (drop app specific configs into place, etc...)
- Should we use block-device (ISO format) or FS-style (plain old directory) via a bind mount?
- FS-style involves adding a new config-drive backend plugin (only a few lines of code) and uses <filesystem type="mount> in the domain XML
- PROPOSED ALTERNATIVE: Block-style would use standard ISO formatted blockdevice and use <filesystem type="block"> in the XML (haven't confirmed this works, but it should)
- QUESTION: Currently using FS-style, but would like to switch to block-style for the Nova upstream patch. Thoughts?
- BLOCK-STYLE PRO: No new config-drive backend (all virt-configuraitons basically use ISO, except potentialy hyperV using fat)
- BLOCK-STYLE CON: issues using <block> with <idmap> so far....
- FS-STYLE PRO: Already have patch, very small
- What should the default mount-point destination be? Currently it's /var/lib/cloud/seed/config_drive (cloud-init's preferred dest) [make this configurable?]
- Action Item: Toss current patch up on to Gerrit for comments
- Action Item: Draft spec :-/
- Remove-fakelibvirt Update (Rick Harris / s1rp)
- On hold for now, turns out to be very contraversial, and it's not blocking anything
- Action Item: Need ML discussion on testing across hypervisors (unit vs integration) so we can get some kind of consistency
- Bug Triage