15:00:17 <danpb> #startmeeting libvirt
15:00:18 <openstack> Meeting started Tue Jun  3 15:00:17 2014 UTC and is due to finish in 60 minutes.  The chair is danpb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'libvirt'
15:00:26 <thomasem> o/
15:00:31 <ndipanov> \o
15:00:39 <s1rp> o/
15:00:41 <vladikr> o/
15:00:44 * bauzas lurking
15:00:46 <danpb> greetings team !
15:00:59 <thomasem> 'ello!
15:01:02 <lparth> hello
15:01:17 <danpb> reminder that the agenda for today is in - seems quite short currently https://etherpad.openstack.org/p/nova-libvirt-meeting-agenda
15:01:53 <thomasem> Yep, haven't had time to look into the IPv6 stuff any further (like checking for what's shared between host and guest) :(
15:01:54 <apmelton> o/
15:01:55 <danpb> lets give a couple of  mins grace for anyone else to join before getting into it
15:04:02 <danpb> #topic Security contact
15:04:37 <danpb> so it seems the openstack security team want some contacts for libvirt driver issues
15:05:10 * danpb will throw himself under that bus, but anyone else who's got a strong understanding of the driver can also volunteer
15:05:30 <ndipanov> I've done it for a few bugs in I
15:05:48 <ndipanov> so I guess write me down unless I am THE SOLE poc...
15:05:55 <danpb> ideally we'd probably want ~3 official points of contact to give coverage  when folks are away
15:06:44 <vladikr> I think I can help on that as well
15:07:31 <danpb> FYI, I expect you'll be required to respect any agreed embargo for non-public issues
15:08:37 <danpb> #action danpb, ndipanov and vladikr  volunteered as security contacts
15:09:09 <danpb> #topic USB Passthrough
15:09:33 <danpb> is Jing Yuan here ?
15:09:34 <JingYuan> hi
15:09:45 <JingYuan> I'm here
15:09:54 <danpb> great - anything you wanted to talk about for this topic ?
15:09:54 <JingYuan> I have implemented a demo about pass-through host's usb device
15:10:04 <JingYuan> I want to share some key information about hypervisor(libvirt,qemu) i met when implemented the demo
15:10:14 <danpb> ok
15:10:50 <JingYuan> Do you think i need to repeat the use cases in the first?
15:11:24 <JingYuan> If not i will share the key information directly
15:11:28 <danpb> personally I'm fine with the use cases
15:11:55 <danpb> so just go straight to the info you have
15:12:13 <JingYuan> ok
15:12:28 <JingYuan> The example xml of pass-through a usb device is as follow:<hostdev mode='subsystem' type='usb'> <source>  <vendor id='0x136b'/>  <product id='0x0003'/>  <address bus='2' device='3'/> </source> </hostdev>
15:12:49 <JingYuan> 1. How to distinguish a usb device of a host?  I want to use bus+device to distinguish a usb device, but found that device number will change every time unplug/plug usb device from/to the host.  Vmware and some other software implement this function by pass-through usb port but not usb device. Libvirt doesn't support pass-through usb port. Users have a little inconvenient to use this function
15:13:22 <JingYuan> 2. This feature is strong correlation with guest os type. Win7 with default 'uhci controller' the usb device is in abnormal status, but with 'ehci controller' it is normal. Winxp sp3 is opposed with win7. Both 'uhci' and 'ehci' are ok in centos 6.5.
15:13:32 <JingYuan> So i think it is better let end user optionally choose usb controller type
15:13:40 <JingYuan> 3. usb 2.0 and 3.0 controller may improve guest performance as compared to usb 1.1 controller when using usb tablet in windows guest os. I have a statistics about it.
15:13:51 <JingYuan> 4. Some other server actions inlude start, stop, reboot, pause/unpause, suspend/resume, rebuild are not affected by this new feature
15:13:56 <JingYuan> 5. The actions of resize and live migrate may be affected by this new feature
15:14:37 <danpb> 1.  this sounds like a valid RFE to send to  libvirt upstream for specification of host USB devices based on port number
15:15:52 <danpb> 2. yes, we already allow for  hw_scsi image property to choose scsi controller type, so no reason why we can't allow choice of usb controller model with a image property
15:16:27 <danpb> another idea we have is to integrate with libosinfo - so you just specify the os_id in the image property and then nova would query libosinfo to find the best USB controller model to use
15:17:14 <danpb> that all said, if Win7 can't use  uhci, it could well be a QEMU bug - try reporting the problem to the qemu mailing list and see if they know about it / fix it
15:17:53 <danpb> 3. we should consider whether we enable usb 2 or 3 by default for guests  so we get good performance out of the box
15:18:31 <JingYuan> I have found a bug about uhci with win7, it was reported in a few years ago, but have no progress by now
15:19:17 <danpb> ok try just reminding qemu-devel about it - in particular Gerd Hoffmann <kraxel@redhat.com>  is a good person to CC on the mail about USB in QEMU ,since he's active maintainer of this code
15:19:53 <JingYuan> ok, i will connect him
15:19:54 <danpb> 4/5.  libvirt will usually report an error if the virDomainMigrate command is used when the guest config won't migrate. so might want to catch that error and make sure it propagates back to the Nova API in a nice way
15:21:05 <danpb> JingYuan: thanks for  the info on USB progress
15:21:43 <JingYuan> Thank you very much for your suggestion.
15:22:04 <JingYuan> I will modify spec and hope you can review them too
15:22:36 <danpb> FYI, while reviews will continue, no specs will be approved until Juno-1 snapshot is released
15:22:55 <danpb> since we've want a focus on code reviews for next 1+1/2 weeks
15:23:13 <danpb> #topic Bug Triage
15:23:39 <danpb> not sure who added this agenda item ?  kashyap was it yours  ?
15:24:03 <kashyap> danpb, Hi, yes,
15:24:36 <danpb> anything you want to say, or were you just reminding us that there are alot of open bugs :-)
15:24:43 <kashyap> I don't have anything significant to report, I just started triaging this morning again
15:25:10 <thomasem> Wasn't there a suggestion for a triage day each month or something?
15:25:10 <kashyap> danpb, I just opened the etherpad, and didn't realize I added it :-)
15:25:23 <kashyap> thomasem, Tomorrow is Nova bug triage day
15:25:28 <kashyap> in #openstack-bugday
15:25:29 <thomasem> ah, gotcha
15:26:05 <thomasem> neat :)
15:26:23 <danpb> ok, so guess that's all the agenda items
15:26:25 <kashyap> This supposedly "high" bug is
15:26:31 <kashyap> languishing for 8 months - https://bugs.launchpad.net/nova/+bug/1221985
15:26:50 <kashyap> I'm sure we'll have many such I guess, and it's not worth discussing spending time here in this meeting
15:27:18 <thomasem> kk
15:27:36 <danpb> #topic Open Forum
15:27:52 <danpb> ....any other things people want to raise before we end the meeting...
15:27:52 <apmelton> so, I had a quick question about the idmap tool I've been working on
15:28:14 <danpb> apmelton: sure, go for it
15:28:24 <apmelton> I was planning on just listing it in pypi, and getting it included in nova's requirements, but I'm wondering if it should just be included as a nova util
15:28:45 <apmelton> I personally feel that it's useful for more than just nova (or openstack) so pypi might be the best place
15:29:51 <danpb> i'm fairly ambivalent - going the pypi route is more work for you, but if you want todo that, then go for it
15:30:27 <thomasem> What all's involved there?
15:30:28 <danpb> i can see how it could be useful for others doing container stuff
15:30:36 <thomasem> out of curiosity
15:30:52 <danpb> thomasem: you mean, what does the tool do ?
15:31:03 <apmelton> I've already got it in it's own repo, with travis-ci hooked up for tests, just need to get everything set up to get it in pypi
15:31:15 <thomasem> Oh, sorry, no. I'm referring to what's the trouble with going to PyPI :)
15:31:24 <thomasem> compared to having it as a nova util
15:31:31 <thomasem> danpb ^^
15:31:36 <danpb> thomasem: well nova util means you just drop one file into the existing git repo
15:31:53 <apmelton> getting it in pypi, getting it approved for our requirements.txt, maintaining it, tagging, etc
15:31:57 <danpb> pypi means you have to create a new git repo, setup setuptools script, etc, etc
15:32:07 <thomasem> Gotcha
15:32:22 <danpb> nothing really hard, its just a bit more work
15:32:28 <thomasem> Okay, I wasn't sure if there was something else. :)
15:32:32 <vladikr> Just a quick question.. is there a blueprint about integrating with libosinfo? I didn't find any
15:32:42 <danpb> vladikr: no, nothing beyond what's in my head
15:32:47 <thomasem> Thanks for the explanation
15:32:48 <vladikr> :)
15:32:56 <apmelton> alright, I'm gonna go with the pypi route
15:33:06 <danpb> should probably write one at some point :-)
15:33:29 <danpb> because the number of image properties is getting quite large and tedious for users to deal with
15:34:27 <aloga> i've a small question regarding disk drivers and xen
15:36:44 <danpb> ok
15:37:05 <aloga> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/utils.py#L450
15:37:20 <aloga> currently the disk driver is being selected regarding on the version of the hypervisor
15:37:24 <aloga> (i'm talking about xen)
15:37:38 <aloga> since blktap was deprecated in 4.0.0 and blktap2 was the replacement
15:38:16 <danpb> yes
15:38:17 <aloga> but it seems that the preferred driver is qdisk (qemu)  http://lists.xen.org/archives/html/xen-devel/2013-08/msg02633.html
15:38:50 <aloga> and to complete the mess, it seems that libxl is able to select the best driver http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt
15:39:47 <danpb> ok, so you'd need to find out what version of Xen supports  'qdisk' and also check if libvirt supports use of qdisk with xen driver
15:40:02 <aloga> danpb: yep, the problem is with the xen management stack
15:40:31 <aloga> xend (xm) was deprecated in 4.2
15:40:36 <danpb> if qdisk is current recommended driver, then we should be using it in poenstacak
15:40:50 <danpb> sure, libvirt uses the libxl driver for Xen >= 4.2
15:41:40 <aloga> danpb: but what if the admin selects xm a the toolstack
15:41:50 <aloga> using xen >= 4.2
15:41:51 <aloga> ?
15:42:16 <aloga> is there any way of knowing if the stack being used is xl or xm from libvirt?
15:42:17 <danpb> libvirt does the right thing
15:42:23 <aloga> danpb: great then
15:42:41 <thomasem> I've got to drop off, folks. I'll catch y'all next week! Hopefully I'll have time to poke around the IPv6 issues with LXC. :)
15:42:46 <aloga> i will submit a patch for this asap
15:42:54 <aloga> danpb: thanks
15:43:03 <danpb> you can query libvirt for the driver name - xenlight vs xen
15:43:46 <danpb> so I think we can wrap up this meeting - thanks for coming everyone. same time/place next week...
15:43:55 <danpb> #endmeeting