16:00:15 <primeministerp> #startmeeting hyper-v
16:00:16 <openstack> Meeting started Tue Jun 11 16:00:15 2013 UTC.  The chair is primeministerp. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:19 <openstack> The meeting name has been set to 'hyper_v'
16:00:26 <primeministerp> hi everyone
16:00:31 <schwicht> hi ...
16:00:40 <ociuhandu> hi everyone
16:00:45 <primeministerp> hi tavi
16:00:49 <primeministerp> pnavarro: hi pedro
16:01:16 <primeministerp> hmm was hoping lluis would show up
16:01:31 <primeministerp> let's wait a couple minutes before we get started
16:02:17 <primeministerp> alexpilotti: i'm waiting a couple in hopes that lluis will join
16:02:30 <alexpilotti> morning!
16:02:35 <primeministerp> hehe
16:02:41 <primeministerp> morning!
16:03:07 <pnavarro> hello !
16:03:13 <alexpilotti> pnavarro: hola!
16:03:22 <primeministerp> pedro!
16:03:27 <primeministerp> ok
16:03:34 <primeministerp> that was a couple
16:03:48 <primeministerp> #topic status update wmiv2
16:04:17 <primeministerp> alexpilotti: how is the wmiv2 code migration progressing
16:04:21 <alexpilotti> we are almost done
16:04:28 <alexpilotti> the idea is simple:
16:04:36 <alexpilotti> V2 utils classes inherit from V1
16:04:52 <alexpilotti> provide the new namespace and different implementations whenever needed
16:05:17 <alexpilotti> a fatory method (like the one we have for volume utils) takes care of instantiating the right one based on the OS
16:05:24 <alexpilotti> *factory
16:05:25 <primeministerp> alexpilotti: so this will allow the backward compatitbility for 2008r2 to remain intact
16:05:35 <alexpilotti> yes
16:05:49 <primeministerp> alexpilotti: perfect
16:05:55 <alexpilotti> everythinhg that used to work on 2008 R2 will still work
16:06:04 <alexpilotti> only new features will be applied to V2 only
16:06:07 <schwicht> nice
16:06:11 <primeministerp> alexpilotti: although obviously this there for "legacy" purposes"
16:06:51 <primeministerp> only
16:06:51 <alexpilotti> yeah, the idea is to eventually remove the V1 classes
16:07:12 <alexpilotti> in a few years, which are geological ages in this domain :-)
16:07:19 <primeministerp> our goal to reiterate is to use 2012 and on as the default platform for development
16:07:55 <primeministerp> ok
16:08:01 <alexpilotti> most meaningful features, including  OpenVSwitch and Ceph
16:08:08 <alexpilotti> will be on 2012+
16:08:15 <primeministerp> when will the bits be ready for testing
16:08:20 <primeministerp> re: wmiv2
16:08:47 <alexpilotti> maybe we'll manage to have them up for review this week already
16:08:58 <primeministerp> great
16:09:15 <alexpilotti> Claudiu, one of our guys is working on it
16:09:38 <primeministerp> oki shall we move on then
16:09:43 <alexpilotti> sure
16:09:50 <primeministerp> alexpilotti: shared mem?
16:10:20 <alexpilotti> oki
16:10:30 <primeministerp> #topic hyper-v shared memory support
16:10:46 <alexpilotti> shared mamory is a fairly easy thing
16:10:55 <alexpilotti> but we'll need 2 options
16:11:19 <alexpilotti> actually it's "dynamic memory"
16:11:29 <primeministerp> sorry
16:11:39 <alexpilotti> np, I was also going on with it :-)
16:11:41 <primeministerp> balooning
16:11:43 <alexpilotti> yep
16:11:49 <primeministerp> re ballooning
16:12:02 <alexpilotti> so we need one optio: "enable_dynamic_memory", defaulting to false
16:12:09 <primeministerp> I knew what i was talking about too ;)
16:12:16 <schwicht> primeministerp: is that supported with regular LIS or just on windows VMs ?
16:12:16 <alexpilotti> and "dynamic_memory_initial_perc"
16:12:26 <primeministerp> schwicht: yes
16:12:43 <primeministerp> schwicht: in newer releases i believe
16:12:44 <alexpilotti> schwicht: yep, including Linux now
16:13:06 <schwicht> ok, good .. we had that discussion the other days, and I was not sure about the RHEL 6.4 situation ...
16:13:16 <alexpilotti> the latter option is needed to tell Hyper-V how much memory to allocate initially in percentage
16:14:31 <alexpilotti> let's say that a flavor states 10GB ram, if the above option's value is 60, the initial memory will be 6GB
16:14:35 <alexpilotti> as easy as that
16:15:08 <alexpilotti> there's of course the risk of overcommitting and what applies for any balooning consideration applies to openstack as well
16:15:15 <primeministerp> obviously
16:15:28 <alexpilotti> in particular the scheduler can get confused by the amount of free memory
16:16:14 <alexpilotti> considering that the host reports to Nova the current free memory, w/o considering VM requirements
16:16:29 <alexpilotti> any comment on this?
16:16:41 <primeministerp> hmm
16:16:43 <primeministerp> i'm thinking
16:17:00 <primeministerp> the scheduler issues can be dangerous leading to cascading failure
16:17:01 <alexpilotti> it's a very useful feature, but misusage can create huge issues
16:17:19 <primeministerp> alexpilotti: exactly
16:17:33 <alexpilotti> that's why I bvote for disabling it by default
16:17:43 <primeministerp> +1
16:17:44 <alexpilotti> > so we need one optio: "enable_dynamic_memory", defaulting to false
16:17:58 <alexpilotti> pnavarro: ehat's your opinion?
16:18:05 <alexpilotti> *what
16:18:36 <pnavarro> in vmare exists the same functionality... I was thinking how they are doing that...
16:18:36 * primeministerp pokes pnavarro
16:18:50 <pnavarro> in the esxi plugin
16:18:51 <alexpilotti> pnavarro: VMWare uses shared paging
16:19:11 <alexpilotti> pnavarro: the implementation differs from the Hyper-V way
16:19:34 <alexpilotti> since we are using SLAT on Hyper-V shared pages make little sense
16:20:01 <pnavarro> ok, but from an  API point of view, you set % and intervals too..
16:20:09 <alexpilotti> pnavarro: sure
16:20:27 <alexpilotti> pnavarro: I'm not familiar with their settings, let me take a look
16:21:07 <pnavarro> about overcommitment there are some flags to make the scheduler aware
16:22:23 <primeministerp> pnavarro: could we theoritically reuse those?
16:22:28 <alexpilotti> pnavarro: I'm looking at the VMWare driver, but I don't see anything
16:22:47 <alexpilotti> pnavarro: do you have a link to teh code line by any chance?
16:23:58 <pnavarro> no, I've used the vmware API in the past, I didn't know how the esxi was using that
16:24:15 <pnavarro> I was just wondering...
16:24:46 <alexpilotti> pnavarro: are you sure is not the scheduler's overcommit?
16:25:12 <pnavarro> well, I'm not sure...
16:25:18 <pnavarro> sorry
16:25:24 <primeministerp> ok
16:25:26 <primeministerp> no worries
16:25:42 <alexpilotti> pnavarro: ram_allocation_ratio
16:25:54 <alexpilotti> that's the option name
16:26:52 <alexpilotti> ok, if any additional idea should come up, let's add comments to the BP whiteboard in case, please
16:27:02 <primeministerp> perfect
16:27:15 <primeministerp> I was hoping luis would be here
16:27:33 <primeministerp> i'll skip the puppet discussion as I need his input
16:27:39 <alexpilotti> primeministerp: can you please add Ceph to the topics?
16:27:42 <primeministerp> o
16:27:43 <primeministerp> yes
16:27:53 <primeministerp> #topic ceph
16:28:30 <primeministerp> alexpilotti: you want to begin or do you want me to start?
16:28:30 <alexpilotti> So, we're prelimiarily discussing the porting of BRD to Hyper-V with Inktank
16:28:43 <primeministerp> alexpilotti: RBD
16:28:59 <alexpilotti> my initial idea was to "simply" port the linux kernel driver to Windows
16:29:22 <alexpilotti> primeministerp: yep sorry, mixing up acronysm is a passion of mine :-)
16:29:31 <primeministerp> alexpilotti: i'm here to keep you honest
16:29:33 <primeministerp> ;)
16:29:35 <alexpilotti> lol
16:29:48 <alexpilotti> back to RBD,
16:29:49 <primeministerp> alexpilotti: although that could totally be taken out of context
16:30:05 <primeministerp> ;)
16:30:11 <alexpilotti> the problem is that the kernel driver is way behind librbd
16:30:26 <alexpilotti> which is the userspace library used by qemu, for example
16:30:52 <alexpilotti> for example cloning is not implemented in the kernel module, only in the userspace lib
16:31:13 <alexpilotti> in Hyper-V we have no choice, we need a kernel driver
16:31:17 <primeministerp> alexpilotti: meaning that's it consumed more via vms through qemu than by native kernel drivers?
16:31:42 <alexpilotti> primeministerp: yep, the main business case is KVM
16:32:07 <alexpilotti> my initial idea is to write a userspace filesystem driver using librbd
16:32:18 <primeministerp> the kernel drivers were more for the clustered storage replacement
16:32:44 <alexpilotti> moving to a full kernel one once Inktank (or the community) will bring the kernel module on parity
16:32:56 <alexpilotti> advantages of this approach:
16:33:11 <alexpilotti> security: we are in userspace, no blue screen
16:33:39 <primeministerp> alexpilotti: i'm assuming it's quciker development too
16:33:41 <alexpilotti> fast development: we avoid all the kernel debugging nightmares
16:33:47 <primeministerp> hehe
16:33:48 <alexpilotti> yep :)
16:34:12 <primeministerp> so are we talking h timeframe?
16:34:20 <alexpilotti> we can use threads, work in C++, no IRQ dispatch issues, etc etc
16:34:32 <alexpilotti> disadvantages:
16:34:55 <alexpilotti> context switches might affect quite a bit the performance side
16:35:02 <zehicle_at_dell> sorry, I was late
16:35:10 <zehicle_at_dell> had to prep for HostingCon panel next week
16:35:27 <primeministerp> zehicle_at_dell: ok
16:35:31 <primeministerp> zehicle_at_dell: and you are?
16:35:41 <alexpilotti> although all the traffic will go on TCP/IP
16:35:41 <primeministerp> zehicle_at_dell: care to introduce yourself?
16:35:57 <alexpilotti> zehicle_at_dell: nice to see you here :-)
16:36:21 <primeministerp> haha
16:36:22 <primeministerp> rob
16:36:27 <primeministerp> zehicle_at_dell: hi rob
16:36:32 <zehicle_at_dell> L)
16:36:40 <primeministerp> zehicle_at_dell: nice name
16:36:48 <ociuhandu> zehicle_at_dell: hi Rob
16:36:51 <zehicle_at_dell> This is Rob Hirschfeld, I'm on the Dell OpenStack team
16:36:58 <primeministerp> zehicle_at_dell: we're talking ceph on hyperv
16:37:06 <zehicle_at_dell> Cool!
16:37:25 <primeministerp> zehicle_at_dell: alexpilotti is talking about the userspace being ported to hyper-v
16:37:33 <alexpilotti> zehicle_at_dell: can you see the previous msgs in the chat?
16:37:42 <zehicle_at_dell> yy
16:37:50 <alexpilotti> zehicle_at_dell: I'd like to hear your opinion on this
16:38:38 <alexpilotti> zehicle_at_dell: but we can talk about it later if you need time
16:38:40 <zehicle_at_dell> intersting, so are you saying that the HyperV Cinder integration cannot use block store?
16:39:04 <alexpilotti> zehicle_at_dell: only the iSCSI wrapper for now
16:39:14 <zehicle_at_dell> ok, that should be OK
16:39:31 <alexpilotti> zehicle_at_dell: fairly ok, not as good as native Ceph of course
16:39:53 <alexpilotti> *native RBD
16:39:57 <zehicle_at_dell> the goal would be to have the RBD driver I'm assuming
16:40:00 <zehicle_at_dell> client
16:40:01 <alexpilotti> yep
16:40:08 <primeministerp> that's what we're talking about
16:40:56 <primeministerp> alexpilotti: move on to ovs?
16:41:04 <alexpilotti> sure
16:41:15 <primeministerp> #topic OpenVSwitch
16:41:16 <alexpilotti> I just wanted to introduce the topic
16:41:24 <alexpilotti> (i mean RBD)
16:41:29 <primeministerp> alexpilotti: yep
16:41:57 <primeministerp> alexpilotti: we should do the same now for ovs, considering your recent announcement?
16:42:01 <zehicle_at_dell> (closing on RBD, I think it's interesting for us.  Will have to reflect on it some more, it's not our first use case)
16:42:13 <alexpilotti> zehicle_at_dell: I don't know if the news reached you, we're porting OVS to Hyper-V
16:42:41 <zehicle_at_dell> I think that's awesome
16:43:01 <alexpilotti> do you have any specific requirements for OVS?
16:43:11 <alexpilotti> like specific tunnelling protocols, etc
16:44:49 <alexpilotti> zehicle_at_dell: ^^
16:44:56 <primeministerp> alexpilotti: ideall the same ones as the core project
16:44:58 <zehicle_at_dell> We're looking at GRE tunnels as the integration approach
16:45:16 <alexpilotti> ok, tx
16:45:39 <alexpilotti> talking in general about OVS, it's a fairly big effort
16:45:57 <alexpilotti> lot's of kernel code to be ported (including GRE and VXLAN)
16:46:15 <alexpilotti> lots of userspace posix -> Windows migration work
16:46:35 <alexpilotti> we're ramping up a "swat" team for it
16:46:49 <zehicle_at_dell> what features of OVS are being planned?
16:47:02 <zehicle_at_dell> for example, is VLAN support higher than GRE
16:47:24 <alexpilotti> zehicle_at_dell: well, VLAN altready works with OVS on Hyper-v now
16:48:21 <alexpilotti> zehicle_at_dell: for the rest: OpenFlow, ovsdb, all userspace tools, tiunnelling (GRE, VXLAN)
16:48:41 <alexpilotti> those are roughly the main features involved
16:49:20 <primeministerp> alexpilotti: all the usual suspects
16:49:25 <primeministerp> ;)
16:49:31 <alexpilotti> among the goals, we want to use the Quantum OVS agent on Hyper-V
16:49:46 <alexpilotti> which means thet the CLI tools must be completely ported as well
16:50:00 <zehicle_at_dell> do you have a feel for the relatative priorities?
16:50:16 <zehicle_at_dell> beause GRE would be high on our list since we've built infrastructure to work with that
16:50:59 <primeministerp> zehicle_at_dell: is the switch integration stronger now?
16:51:02 <alexpilotti> zehicle_at_dell: we're collecting customer based priorities now
16:51:16 <zehicle_at_dell> good question -> the choice for GRE allowed use to bypass that for now
16:51:34 <alexpilotti> zehicle_at_dell: good to know
16:51:40 <zehicle_at_dell> so, it was a good first pass because it was easier to get adoption started
16:51:50 <zehicle_at_dell> VLAN would have required more switch config work
16:52:03 <primeministerp> zehicle_at_dell: understood
16:52:06 <alexpilotti> zehicle_at_dell: GRE is anyway already before VXLAN oin our GANTT
16:52:10 <zehicle_at_dell> downside is that GRE will have performance impacts
16:52:13 <zehicle_at_dell> perfect
16:52:36 <alexpilotti> VXLAN introduction in OVS is very recent
16:52:55 <alexpilotti> and I expect some big changes in the tunnelling world soon
16:53:19 <alexpilotti> so it's hard to predict now how much VXLAN will get traction in QUantum
16:53:45 <primeministerp> zehicle_at_dell: do you have specific topics to add?
16:53:46 <alexpilotti> (I keep on calling it Quantum if you don't mind for now) ;-)
16:54:08 <primeministerp> pfkaq
16:54:18 <alexpilotti> lol
16:54:19 <pnavarro> lol !
16:54:48 <primeministerp> alexpilotti: any final words on ovs?
16:55:12 <zehicle_at_dell> for the current working set, you said VLAN was enabled?
16:55:17 <zehicle_at_dell> against Grizzly?
16:55:17 <alexpilotti> yep
16:55:19 <alexpilotti> yep
16:55:20 <primeministerp> zehicle_at_dell: yes
16:55:37 <alexpilotti> that was our goal
16:55:52 <zehicle_at_dell> ok, I'll need to see where we stand on VLAN.  I think we've got it in place but not our primary test path
16:56:15 <alexpilotti> using the Hyper-V Quantum agent with 100% OVS compatibility was the main use case
16:56:24 <alexpilotti> on VLAN, I mean
16:56:49 <alexpilotti> primeministerp: should we move to the next topic?
16:56:54 <primeministerp> alexpilotti: yes
16:57:00 <primeministerp> alexpilotti: is there one?
16:57:20 <primeministerp> alexpilotti: puppet bits are on hold until luis and i sync
16:57:21 <alexpilotti> if nexttopic == NULL -> endmeeting() ;-)
16:57:26 <primeministerp> ok
16:57:35 <primeministerp> zehicle_at_dell: anything you want to add?
16:58:18 <primeministerp> looks like frank left
16:58:19 <primeministerp> ok
16:58:24 <primeministerp> #endmeeting