16:02:04 #startmeeting hyper-v 16:02:04 Meeting started Tue Oct 7 16:02:04 2014 UTC and is due to finish in 60 minutes. The chair is primemin7sterp. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:07 The meeting name has been set to 'hyper_v' 16:02:14 hey all 16:02:22 \o/ 16:02:51 quick meeting today as we're trying to recover from a major outage 16:03:00 alexpilotti: I know bp's for K are in full swing 16:03:06 alexpilotti: do we want to start there 16:03:09 yep 16:03:15 #topic bp's for k 16:03:17 so kilo opened yesterday 16:03:29 nick primemin7sterp 16:03:39 #topic bp's for k 16:03:50 the good part is that self-contained BPs (e.g. drivers) *shouldn’t* need a spec anymore 16:03:54 this will speed up things 16:04:01 that's great news 16:04:05 the first batch of thos bps are: 16:04:27 #link https://blueprints.launchpad.net/nova/+spec/hyper-v-generation-2-vms 16:04:33 generation 2 VMs 16:04:49 very important as it also unblocks other BPs 16:05:14 in particular vNIC add/remote at runtime 16:05:24 and USEFI secureboot 16:05:29 *USEFI 16:05:41 damn autocorrect U-E-F-I :-) 16:05:47 next 16:05:56 https://blueprints.launchpad.net/nova/+spec/hyper-v-host-power-actions 16:06:15 hello everyone, wow, first meeting in months I can attend 16:06:18 simple and straight forward feature parity bp 16:06:25 pnavarro: heyyy 16:06:34 #link https://blueprints.launchpad.net/nova/+spec/hyper-v-remotefx 16:06:50 RemoteFX, this one is around since Havana, waiting approval 16:07:00 #link https://blueprints.launchpad.net/nova/+spec/hyper-v-rescue 16:07:11 yep 16:07:14 Rescue / unrescue: more feature parity 16:07:15 it's been a while 16:07:28 all those BPs have implementations ready 16:08:11 alexpilotti, maybe we should add the extra_spec hyperv:remotefx at image level too 16:08:11 More BPs which I want to file and that *should* not require a spec: 16:08:23 similarly it's been done with NFV extra_specs 16:08:30 pnavarro: it’s more a flavor thing 16:08:57 pnavarro: but if you look at teh BP, it refers also to images 16:09:26 k 16:09:37 is that it for the new bp's 16:09:38 pnavarro: one thing is for sure, it’ll require a scheduler filter :) 16:09:44 back to new BPs 16:09:58 pnavarro: I’d be happy to discuss the BP details later! 16:10:14 1) Hyper-V UEFI SecureBoot 16:10:24 2) Hyper-V Storage QoS 16:10:48 this is a new feature in the current Hyepr-V “”technical Preview” 16:10:59 3) Hyper-V vNic hot-plug (requires gen2 vm support) 16:11:11 hi 16:11:14 also a new feature in the upcoming version 16:11:19 luis_: hey! 16:11:29 alexpilotti, do you know if in Hyper-V it's possible to do cpu-pinning, or other NFV related ops ? 16:11:55 4) Hyper-V console (feature available in Juno for libvirt) 16:12:10 not to be confused with teh console log 16:12:34 pnavarro: sorry, finishing this list, just to get over teh list of new stuff! :) 16:12:41 sorry man 16:12:45 5) Hyper-V vNUMA 16:12:57 nice ! 16:13:06 since we have NUMA support in OpenStack, this makes sense to add 16:13:41 now, on the Nova BPs, as in bps that affect Nova code and not only our driver 16:13:57 #link https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates 16:14:17 this was proposed for Juno already, one of my favorites: 16:14:28 password-less authentication in WIndows! 16:14:46 #link https://blueprints.launchpad.net/nova/+spec/windows-smbfs-volume-driver 16:14:51 awesome 16:14:53 #link https://blueprints.launchpad.net/nova/+spec/libvirt-smbfs-volume-support 16:15:11 those 2 BPs add SMB volumes support in Nova 16:15:23 maybe it makes more sense to use barbican for storing x509 certificates? 16:15:42 we merged the corresponding SMB3 feats in Cinder during Juno 16:15:54 pnavarro: about certificates, there are 2 aspects: 16:16:18 1) the quick and dirty keypair approach, which is teh main focus of the BP 16:16:51 basically we want to give Windows users the same “user experience” that Linux users have since a while: no darn passwords :-) 16:17:21 exactly like in the SSH keypair case, X509 certs are not meant to be distributed 16:17:28 which brings to: 16:17:34 2) Barbican support 16:17:49 in this case we’d want to integrate a fully fledged PKI 16:17:52 it makes sense... 16:18:10 but I’d avoid mixing the two things 16:18:27 we need to have Windows users getting over passwords 16:18:39 and we need the simplest possible way to get there 16:19:09 depending on an additional service which is rarely deployed, won’t help outside large organizations 16:19:46 ok, I understand. thanks alex 16:19:57 np! 16:20:15 What I don't understand SMBFs in Cinder instead of in Manila.. 16:20:29 pnavarro: the hypervisor has a client 16:20:38 pnavarro: we store vhdx on smb3 lun 16:20:47 pnavarro: like a passthru device 16:20:57 Hyper-V best practice for volumes is to attach VHD(X)s directly off SMB3 16:20:59 to the guest 16:21:10 the guest won’t see the SMB share 16:21:33 so, it's similar like we get using RBD library in Ceph.. 16:21:45 kinda 16:22:04 although in Windows the Ceph port wil work via passthrough devices 16:22:31 exposed to guests like we do today with iSCSI 16:22:58 oki, thanks for the clarification primemin7sterp 16:23:12 that’s only because the Hyper-V team is not making the APIs used for attaching SMB based VHDXs public 16:23:38 one last BP, just to get over them: 16:24:05 Refactoring Mox tests with Mock in the Hyper-V driver 16:24:28 all new tests are Mock based, so it’s just about replacing test_hyperapi.py 16:25:44 pnavarro: getting back to your question, we don’t have NFV pinning atm 16:26:00 pnavarro: teh closest thing we have is vNUMA :) 16:26:06 and hugepages? 16:26:41 you mean still related to NFV? 16:26:46 yeah 16:27:40 alexpilotti: anything else to cover? 16:27:55 pnavarro: not really 16:28:05 ok 16:28:09 i'm going to end it 16:28:11 ok 16:28:17 thx everyone 16:28:20 #endmeeting