Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-17
10:26:18 mdbooth lyarwood: I hadn't realised there was no user in the following patches. I'd just assumed there was.
10:26:53 mdbooth The patches as posted are good, imho. There's no reason I see why they can't merge quickly when they have a reason to be in the code.
10:27:06 mdbooth I just think it's counter-productive to merge them now.
10:27:38 mdbooth s/counter-productive/premature/
10:27:48 lyarwood yup understood
10:28:38 mdbooth lyarwood: Yeah, I will.
10:28:42 lyarwood thanks
10:28:56 mdbooth lyarwood: Is there a merge conflict with the detach patches, btw?
10:29:09 mdbooth If not, why not just separate them into their own independent series anyway?
10:29:19 lyarwood mdbooth: yes, they are based on jgriffith's own db & object change
10:29:22 mdbooth Then they can both proceed at their own pace.
10:29:32 lyarwood mdbooth: ah
10:29:38 lyarwood mdbooth: wait you mean my refactor patches
10:29:42 mdbooth Yeah
10:29:48 lyarwood mdbooth: no, not with the db and object changes
10:29:53 lyarwood iirc
10:30:11 mdbooth I think you could pull https://review.openstack.org/#/c/440693/ to the top of its own series
10:30:12 lyarwood mdbooth: let me grab some more coffee and spin them out
10:30:31 lyarwood mdbooth: sure
10:30:34 mdbooth And that wouldn't compromise either those patches or the attachment_id patches in any way
10:31:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: do not include context to exception notification https://review.openstack.org/446948
10:39:46 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Only destroy BDMs after successful detach call https://review.openstack.org/440693
10:40:05 lyarwood mdbooth: ^ that change should be flying solo now
10:43:29 mdbooth lyarwood: Cool, check in a minute.
11:01:10 gmann mdbooth: johnthetubaguy kashyap : 1 query on swap volume
11:01:42 gmann mdbooth: johnthetubaguy kashyap : when we swap volume with nova volume update, we loss the thin provisioning.
11:02:29 gmann any way to keep the thin provisioning when libvirt rebase during swap volume
11:02:47 johnthetubaguy gmann: what are you aiming to do with the swap volume?
11:02:48 gmann did not find any flag on virDomainBlockRebase
11:03:38 gmann johnthetubaguy: i had thin provisioned volume attached to instance and then i want to swap that volume but new volume is not thin provisioned one its all full size as used
11:04:14 gmann allocated size is all volume size not actual consumed sized
11:05:33 johnthetubaguy gmann: but why did you swap to a new volume, I am just curious? migrating between volume types?
11:06:33 johnthetubaguy ( gmann: honestly, I think its the same problem we have using stroage pools for migration, it doesn't zip copying zeros, but mdbooth and kashyap will know more about that than me)
11:06:51 johnthetubaguy s/zip/skip/
11:07:16 gmann johnthetubaguy: yea same issue, it copy all zero block too
11:07:30 gmann johnthetubaguy: yea use case is migrating volume to new type
11:07:40 johnthetubaguy gmann: cool, that makes sense
11:07:51 johnthetubaguy so we have to copy everything, but copying zeros is stupid
11:08:04 kashyap gmann: Sorry, occupied for a bit with something, bbiab
11:08:07 gmann only thing i had is to do fstrim or blkdiscard
11:08:08 johnthetubaguy sounds consistent with the current problems we have with all that
11:08:28 johnthetubaguy gmann: yeah, that shouldn't be needed for sure.
11:08:36 gmann yea
11:08:45 gmann kashyap: sure take your time.
11:09:07 mdbooth gmann: That could be tough
11:10:14 mdbooth gmann: I think qemu would have to do explicit zero detection during the rebase operation
11:11:13 mdbooth gmann: When we do this for ephemeral storage, we get sparseness from metadata
11:11:57 mdbooth kashyap: Do you know qemu supports doing a block rebase with explicit zero detection?
11:12:06 mdbooth And if libvirt exposes that?
11:12:06 lyarwood gmann: which volumebackend is this with btw?
11:12:25 kashyap mdbooth: I saw some 'detect zeroes' stuff fly by on the QEMU list. Don't recall top off my head, need some digging
11:16:24 gmann mdbooth: kashyap ok. please let us know if something going to be supported or already there. it will really help
11:16:33 gmann lyarwood: lvm
11:17:01 mdbooth gmann: So, for ephemeral storage block migration with qcow2 we use VIR_MIGRATE_NON_SHARED_INC
11:17:31 mdbooth This basically means we copy the backing file
11:17:52 mdbooth Then the live migration copies just the 'overlay'
11:18:20 mdbooth IOW qemu is relying on qcow2 metadata
11:19:15 gmann k
11:19:22 mdbooth For volume copy we don't have this
11:20:31 gmann can it be done with VIR_DOMAIN_BLOCK_REBASE_SHALLOW when same backing file (not sure it can) ?
11:20:47 mdbooth https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainBlockRebaseFlags
11:20:56 mdbooth gmann: There's no backing file for bolumes
11:21:00 mdbooth volumes
11:21:42 mdbooth gmann: It doesn't look to me like any of the above options support zero-detection during copy
11:21:51 gmann humm
11:21:54 gmann yea
11:22:30 mdbooth gmann: I'd be moderately confident that this can't be done right now
11:22:47 kashyap mdbooth: gmann: I was quickly scanning QEMU block schema
11:23:02 kashyap I see a 'detect_zeroes' option that could be specificed when _configuring_ a block device
11:23:31 mdbooth Incidentally, what *could* be done is this:
11:23:50 kashyap And a QEMU block developer confirms: If an area is allocated nowhere in the backing chain, block-stream won't allocate it
11:24:21 mdbooth 1. cinder tells nova to make an atomic local snapshot of the volume
11:24:32 mdbooth 2. Nova makes atomic snapshot and starts writing to snapshot
11:24:51 mdbooth 3. Cinder does fast backend-specific copy of volume from A to B
11:25:20 mdbooth 4. Cinder tells Nova to rebase its snapshot on to B, which is identical to A at the point Nova snapshotted it
11:25:31 mdbooth 5. Nova commits its snapshot to B
11:25:36 mdbooth 6. Profit
11:26:07 mdbooth That's a way different control flow, though
11:27:48 mdbooth kashyap: That's qcow2 thought, right?
11:28:02 mdbooth though
11:28:10 gmann mdbooth: humm, it is on what johnthetubaguy proposal on cinder nova flow ?
11:28:14 kashyap mdbooth: Yep. Still talking to Max. Let me paste my conv. snippet
11:28:32 mdbooth kashyap: So this is a cinder volume: lvm exported over iscsi
11:28:39 mdbooth qemu just sees a single, flat block device
11:29:06 johnthetubaguy that swap volume stuff has to follow after multi-attach I feel
11:29:24 mdbooth johnthetubaguy: Yep.
11:29:35 johnthetubaguy cool, sounds like we are on the same page there then
11:29:42 kashyap mdbooth: Noted
11:29:54 kashyap So, here we go, 8 lines of paste:
11:29:55 kashyap 12:21 < mreitz> Well, if an area is allocated nowhere in the backing chain, block-stream won't allocate it
11:29:59 kashyap 12:21 * kashyap does notice 'detect_zeroes' flag as an option for @BlockDeviceInfo
11:30:02 kashyap 12:22 < mreitz> At least from what I can tell from the code
11:30:04 kashyap 12:22 < mreitz> Yeah, you can open the target BDS with detect-zeroes=on...
11:30:07 kashyap 12:24 < mreitz> But as far as I can tell, copy-on-read actually always uses zero detection and converts requests accordingly
11:30:10 kashyap 12:24 < mreitz> And block-stream performs its writes through the copy-on-read mechanic
11:30:13 kashyap 12:24 < kashyap> mreitz: Ah, so, in that case (when the target block dev is opened with 'detect-zeroes=on'), thin provisioning will be retained?
11:30:16 kashyap 12:24 < mreitz> So I'd think that block-stream should always do zero detection
11:31:21 mdbooth kashyap: Ah, ok. So there's no detect zeroes option because it's always done.
11:31:45 mdbooth So we'd just need to ensure we're doing it on the output?
11:32:40 kashyap mdbooth: I think so. The experiment is:

Earlier   Later