Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 24 June 2014 16:40, Jay Pipes jaypi...@gmail.com wrote: On 06/24/2014 07:32 AM, Daniel P. Berrange wrote: On Tue, Jun 24, 2014 at 10:55:41AM +, Day, Phil wrote: -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: 23 June 2014 10:35 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 18 June 2014 21:57, Jay Pipes jaypi...@gmail.com wrote: On 06/17/2014 05:42 PM, Daniel P. Berrange wrote: On Tue, Jun 17, 2014 at 04:32:36PM +0100, Pádraig Brady wrote: On 06/13/2014 02:22 PM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 There is an existing libvirt blueprint: https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down which I've never been in favor of: https://bugs.launchpad.net/nova/+bug/1270238/comments/1 All of the functionality around resizing VMs to match a different flavour seem to be a recipe for unleashing a torrent of unfixable bugs, whether resizing disks, adding CPUs, RAM or any other aspect. +1 I'm of the opinion that we should plan to rip resize functionality out of (the next major version of) the Compute API and have a *single*, *consistent* API for migrating resources. No more API extension X for migrating this kind of thing, and API extension Y for this kind of thing, and API extension Z for migrating /live/ this type of thing. There should be One move API to Rule Them All, IMHO. +1 for one move API, the two evolved independently, in different drivers, its time to unify them! That plan got stuck behind the refactoring of live-migrate and migrate to the conductor, to help unify the code paths. But it kinda got stalled (I must rebase those patches...). Just to be clear, I am against removing resize down from v2 without a deprecation cycle. But I am pro starting that deprecation cycle. John I'm not sure Daniel and Jay are arguing for the same thing here John: I *think* Daniel is saying drop resize altogether and Jay is saying unify it with migration - so I'm a tad confused which of those you're agreeing with. OK, I got the wrong end of the stick, sorry. Yes, I'm personally for removing resize completely since, IMHO, no matter how many bugs we fix it is always going to be a mess. That said I realize that people probably find resize-up useful, so I won't push hard to kill it - we should just recognize that it is always going to be a mess which does not result in the same setup you'd get if you booted fresh with the new settings. Resize down should probably get deprecated and die. But I think resize up is quite useful. If we make snapshot, then build work well for all use cases, then resize up could die too. But I am still on the fence here, mostly due to how slow snapshots can be, and loosing your IP addresses across the whole process. But thats more a problem for me than it is for nova users as a whole. I am of the opinion that the different API extensions and the fact that they have evolved separately have created a giant mess for users, and that we should consolidate the API into a single move API that can take an optional new set of resources (via a new specified flavor) and should automatically live move the instance if it is possible, and fall back to a cold move if it isn't possible, with no confusing options or additional/variant API calls needed by the user. I agree, we need to bring together all move APIs into a single API. Mostly thinking about migrate and live-migrate. We could probably leave resize behind for now, but I really want to do resize up like this: * live migrate to host where it fits * now shutdown guest and do the resize up of the disk And there are specs about hot plugging CPUs as soon as you get to the destination, if thats all you need to do. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
-Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: 23 June 2014 10:35 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 18 June 2014 21:57, Jay Pipes jaypi...@gmail.com wrote: On 06/17/2014 05:42 PM, Daniel P. Berrange wrote: On Tue, Jun 17, 2014 at 04:32:36PM +0100, Pádraig Brady wrote: On 06/13/2014 02:22 PM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 There is an existing libvirt blueprint: https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down which I've never been in favor of: https://bugs.launchpad.net/nova/+bug/1270238/comments/1 All of the functionality around resizing VMs to match a different flavour seem to be a recipe for unleashing a torrent of unfixable bugs, whether resizing disks, adding CPUs, RAM or any other aspect. +1 I'm of the opinion that we should plan to rip resize functionality out of (the next major version of) the Compute API and have a *single*, *consistent* API for migrating resources. No more API extension X for migrating this kind of thing, and API extension Y for this kind of thing, and API extension Z for migrating /live/ this type of thing. There should be One move API to Rule Them All, IMHO. +1 for one move API, the two evolved independently, in different drivers, its time to unify them! That plan got stuck behind the refactoring of live-migrate and migrate to the conductor, to help unify the code paths. But it kinda got stalled (I must rebase those patches...). Just to be clear, I am against removing resize down from v2 without a deprecation cycle. But I am pro starting that deprecation cycle. John I'm not sure Daniel and Jay are arguing for the same thing here John: I *think* Daniel is saying drop resize altogether and Jay is saying unify it with migration - so I'm a tad confused which of those you're agreeing with. Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On Tue, Jun 24, 2014 at 10:55:41AM +, Day, Phil wrote: -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: 23 June 2014 10:35 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 18 June 2014 21:57, Jay Pipes jaypi...@gmail.com wrote: On 06/17/2014 05:42 PM, Daniel P. Berrange wrote: On Tue, Jun 17, 2014 at 04:32:36PM +0100, Pádraig Brady wrote: On 06/13/2014 02:22 PM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 There is an existing libvirt blueprint: https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down which I've never been in favor of: https://bugs.launchpad.net/nova/+bug/1270238/comments/1 All of the functionality around resizing VMs to match a different flavour seem to be a recipe for unleashing a torrent of unfixable bugs, whether resizing disks, adding CPUs, RAM or any other aspect. +1 I'm of the opinion that we should plan to rip resize functionality out of (the next major version of) the Compute API and have a *single*, *consistent* API for migrating resources. No more API extension X for migrating this kind of thing, and API extension Y for this kind of thing, and API extension Z for migrating /live/ this type of thing. There should be One move API to Rule Them All, IMHO. +1 for one move API, the two evolved independently, in different drivers, its time to unify them! That plan got stuck behind the refactoring of live-migrate and migrate to the conductor, to help unify the code paths. But it kinda got stalled (I must rebase those patches...). Just to be clear, I am against removing resize down from v2 without a deprecation cycle. But I am pro starting that deprecation cycle. John I'm not sure Daniel and Jay are arguing for the same thing here John: I *think* Daniel is saying drop resize altogether and Jay is saying unify it with migration - so I'm a tad confused which of those you're agreeing with. Yes, I'm personally for removing resize completely since, IMHO, no matter how many bugs we fix it is always going to be a mess. That said I realize that people probably find resize-up useful, so I won't push hard to kill it - we should just recognize that it is always going to be a mess which does not result in the same setup you'd get if you booted fresh with the new settings. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 06/24/2014 07:32 AM, Daniel P. Berrange wrote: On Tue, Jun 24, 2014 at 10:55:41AM +, Day, Phil wrote: -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: 23 June 2014 10:35 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 18 June 2014 21:57, Jay Pipes jaypi...@gmail.com wrote: On 06/17/2014 05:42 PM, Daniel P. Berrange wrote: On Tue, Jun 17, 2014 at 04:32:36PM +0100, Pádraig Brady wrote: On 06/13/2014 02:22 PM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 There is an existing libvirt blueprint: https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down which I've never been in favor of: https://bugs.launchpad.net/nova/+bug/1270238/comments/1 All of the functionality around resizing VMs to match a different flavour seem to be a recipe for unleashing a torrent of unfixable bugs, whether resizing disks, adding CPUs, RAM or any other aspect. +1 I'm of the opinion that we should plan to rip resize functionality out of (the next major version of) the Compute API and have a *single*, *consistent* API for migrating resources. No more API extension X for migrating this kind of thing, and API extension Y for this kind of thing, and API extension Z for migrating /live/ this type of thing. There should be One move API to Rule Them All, IMHO. +1 for one move API, the two evolved independently, in different drivers, its time to unify them! That plan got stuck behind the refactoring of live-migrate and migrate to the conductor, to help unify the code paths. But it kinda got stalled (I must rebase those patches...). Just to be clear, I am against removing resize down from v2 without a deprecation cycle. But I am pro starting that deprecation cycle. John I'm not sure Daniel and Jay are arguing for the same thing here John: I *think* Daniel is saying drop resize altogether and Jay is saying unify it with migration - so I'm a tad confused which of those you're agreeing with. Yes, I'm personally for removing resize completely since, IMHO, no matter how many bugs we fix it is always going to be a mess. That said I realize that people probably find resize-up useful, so I won't push hard to kill it - we should just recognize that it is always going to be a mess which does not result in the same setup you'd get if you booted fresh with the new settings. I am of the opinion that the different API extensions and the fact that they have evolved separately have created a giant mess for users, and that we should consolidate the API into a single move API that can take an optional new set of resources (via a new specified flavor) and should automatically live move the instance if it is possible, and fall back to a cold move if it isn't possible, with no confusing options or additional/variant API calls needed by the user. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 18 June 2014 21:57, Jay Pipes jaypi...@gmail.com wrote: On 06/17/2014 05:42 PM, Daniel P. Berrange wrote: On Tue, Jun 17, 2014 at 04:32:36PM +0100, Pádraig Brady wrote: On 06/13/2014 02:22 PM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 There is an existing libvirt blueprint: https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down which I've never been in favor of: https://bugs.launchpad.net/nova/+bug/1270238/comments/1 All of the functionality around resizing VMs to match a different flavour seem to be a recipe for unleashing a torrent of unfixable bugs, whether resizing disks, adding CPUs, RAM or any other aspect. +1 I'm of the opinion that we should plan to rip resize functionality out of (the next major version of) the Compute API and have a *single*, *consistent* API for migrating resources. No more API extension X for migrating this kind of thing, and API extension Y for this kind of thing, and API extension Z for migrating /live/ this type of thing. There should be One move API to Rule Them All, IMHO. +1 for one move API, the two evolved independently, in different drivers, its time to unify them! That plan got stuck behind the refactoring of live-migrate and migrate to the conductor, to help unify the code paths. But it kinda got stalled (I must rebase those patches...). Just to be clear, I am against removing resize down from v2 without a deprecation cycle. But I am pro starting that deprecation cycle. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
-Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: 17 June 2014 15:57 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 06/17/2014 10:43 AM, Richard W.M. Jones wrote: On Fri, Jun 13, 2014 at 06:12:16AM -0400, Aryeh Friedman wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. True for live resizing. For dead resizing, libguestfs + virt-resize can do it. Although I wouldn't necessarily recommend it. In almost all cases where someone wants to shrink a disk, IMHO it is better to sparsify it instead (ie. virt-sparsify). FWIW, the resize operation in OpenStack is a dead one. Dead as in not supported in V3 ? How does that map into the plans to implement V2.1 on top of V3 ? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On Wed, Jun 18, 2014 at 11:05:01AM +, Day, Phil wrote: -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: 17 June 2014 15:57 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 06/17/2014 10:43 AM, Richard W.M. Jones wrote: On Fri, Jun 13, 2014 at 06:12:16AM -0400, Aryeh Friedman wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. True for live resizing. For dead resizing, libguestfs + virt-resize can do it. Although I wouldn't necessarily recommend it. In almost all cases where someone wants to shrink a disk, IMHO it is better to sparsify it instead (ie. virt-sparsify). FWIW, the resize operation in OpenStack is a dead one. Dead as in not supported in V3 ? dead as in not live resizing, ie. it happens only on offline disk images. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
-Original Message- From: Richard W.M. Jones [mailto:rjo...@redhat.com] Sent: 18 June 2014 12:32 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On Wed, Jun 18, 2014 at 11:05:01AM +, Day, Phil wrote: -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: 17 June 2014 15:57 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 06/17/2014 10:43 AM, Richard W.M. Jones wrote: On Fri, Jun 13, 2014 at 06:12:16AM -0400, Aryeh Friedman wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. True for live resizing. For dead resizing, libguestfs + virt-resize can do it. Although I wouldn't necessarily recommend it. In almost all cases where someone wants to shrink a disk, IMHO it is better to sparsify it instead (ie. virt-sparsify). FWIW, the resize operation in OpenStack is a dead one. Dead as in not supported in V3 ? dead as in not live resizing, ie. it happens only on offline disk images. Rich. Ah, thanks. I was thinking of dead as in it is an ex-operation, it has ceased to be, ... ;-) There seems to be a consensus towards this being treated as an error - so I'll raise a spec. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 06/17/2014 05:42 PM, Daniel P. Berrange wrote: On Tue, Jun 17, 2014 at 04:32:36PM +0100, Pádraig Brady wrote: On 06/13/2014 02:22 PM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 There is an existing libvirt blueprint: https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down which I've never been in favor of: https://bugs.launchpad.net/nova/+bug/1270238/comments/1 All of the functionality around resizing VMs to match a different flavour seem to be a recipe for unleashing a torrent of unfixable bugs, whether resizing disks, adding CPUs, RAM or any other aspect. +1 I'm of the opinion that we should plan to rip resize functionality out of (the next major version of) the Compute API and have a *single*, *consistent* API for migrating resources. No more API extension X for migrating this kind of thing, and API extension Y for this kind of thing, and API extension Z for migrating /live/ this type of thing. There should be One move API to Rule Them All, IMHO. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
So I am +1 deprecating resize down, mostly for consistency reasons. On 16 June 2014 10:34, Day, Phil philip@hp.com wrote: Beyond what is and isn’t technically possible at the file system level there is always the problem that the user may have more data than can fit into the reduced disk. I don’t want to take away useful functionality from folks if there are cases where it already works – mostly I just want to improve the user experience, and to me the biggest problem here is the current failure mode where the user can’t tell if the request has been tried and failed, or just not happened at all for some other reason. What if we introduced a new state of “Resize_failed” from which the only allowed operations are “resize_revert” and delete – so the user can at least get some feedback on the cases that can’t be supported ? In the XenAPI driver, the instance actions should report the error that occurred and how to fix it (i.e. you have too much data in your disk, delete some). Longer term, the tasks API makes it much more obvious what happens with async tasks that error, with a clean rollback. Given we are leaning towards deprecation, I would rather we didn't add an extra Resize_failed state. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On Fri, Jun 13, 2014 at 06:12:16AM -0400, Aryeh Friedman wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. True for live resizing. For dead resizing, libguestfs + virt-resize can do it. Although I wouldn't necessarily recommend it. In almost all cases where someone wants to shrink a disk, IMHO it is better to sparsify it instead (ie. virt-sparsify). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On Tue, Jun 17, 2014 at 10:56:36AM -0400, Russell Bryant wrote: On 06/17/2014 10:43 AM, Richard W.M. Jones wrote: On Fri, Jun 13, 2014 at 06:12:16AM -0400, Aryeh Friedman wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. True for live resizing. For dead resizing, libguestfs + virt-resize can do it. Although I wouldn't necessarily recommend it. In almost all cases where someone wants to shrink a disk, IMHO it is better to sparsify it instead (ie. virt-sparsify). FWIW, the resize operation in OpenStack is a dead one. advert In = 1.26, `virt-sparsify --in-place' is very fast, doesn't copy, and doesn't need mountains of temporary space (unlike the copying mode virt-sparsify). http://libguestfs.org/virt-sparsify.1.html#in-place-sparsification /advert Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 06/17/2014 10:43 AM, Richard W.M. Jones wrote: On Fri, Jun 13, 2014 at 06:12:16AM -0400, Aryeh Friedman wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. True for live resizing. For dead resizing, libguestfs + virt-resize can do it. Although I wouldn't necessarily recommend it. In almost all cases where someone wants to shrink a disk, IMHO it is better to sparsify it instead (ie. virt-sparsify). FWIW, the resize operation in OpenStack is a dead one. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 06/13/2014 02:22 PM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 There is an existing libvirt blueprint: https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down which I've never been in favor of: https://bugs.launchpad.net/nova/+bug/1270238/comments/1 thanks, Pádraig. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
This is a fix in flight for the vmware driver. It also throws an exception on disk size reduction. https://review.openstack.org/#/c/85804/ On Jun 13, 2014, at 3:02 AM, Day, Phil philip@hp.com wrote: Hi Folks, I was looking at the resize code in libvirt, and it has checks which raise an exception if the target root or ephemeral disks are smaller than the current ones – which seems fair enough I guess (you can’t drop arbitary disk content on resize), except that the because the check is in the virt driver the effect is to just ignore the request (the instance remains active rather than going to resize-verify). It made me wonder if there were any hypervisors that actually allow this, and if not wouldn’t it be better to move the check to the API layer so that the request can be failed rather than silently ignored ? As far as I can see: baremetal: Doesn’t support resize hyperv: Checks only for root disk (https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L99-L108 ) libvirt: fails for a reduction of either root or ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4918-L4923 ) vmware: doesn’t seem to check at all ? xen: Allows resize down for root but not for ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L1015-L1032 ) It feels kind of clumsy to have such a wide variation of behavior across the drivers, and to have the check performed only in the driver ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
Theoretically impossible to reduce disk unless you have some really nasty guest additions. On Fri, Jun 13, 2014 at 6:02 AM, Day, Phil philip@hp.com wrote: Hi Folks, I was looking at the resize code in libvirt, and it has checks which raise an exception if the target root or ephemeral disks are smaller than the current ones – which seems fair enough I guess (you can’t drop arbitary disk content on resize), except that the because the check is in the virt driver the effect is to just ignore the request (the instance remains active rather than going to resize-verify). It made me wonder if there were any hypervisors that actually allow this, and if not wouldn’t it be better to move the check to the API layer so that the request can be failed rather than silently ignored ? As far as I can see: baremetal: Doesn’t support resize hyperv: Checks only for root disk ( https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L99-L108 ) libvirt: fails for a reduction of either root or ephemeral ( https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4918-L4923 ) vmware: doesn’t seem to check at all ? xen: Allows resize down for root but not for ephemeral ( https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L1015-L1032 ) It feels kind of clumsy to have such a wide variation of behavior across the drivers, and to have the check performed only in the driver ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
Theoretically impossible to reduce disk unless you have some really nasty guest additions. That’s what I thought – but many of the drivers seem to at least partially support it based on the code, hence the question on here to find out of that is really supported and works – or is just inconsistent error checking across drivers. From: Aryeh Friedman [mailto:aryeh.fried...@gmail.com] Sent: 13 June 2014 11:12 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? Theoretically impossible to reduce disk unless you have some really nasty guest additions. On Fri, Jun 13, 2014 at 6:02 AM, Day, Phil philip@hp.commailto:philip@hp.com wrote: Hi Folks, I was looking at the resize code in libvirt, and it has checks which raise an exception if the target root or ephemeral disks are smaller than the current ones – which seems fair enough I guess (you can’t drop arbitary disk content on resize), except that the because the check is in the virt driver the effect is to just ignore the request (the instance remains active rather than going to resize-verify). It made me wonder if there were any hypervisors that actually allow this, and if not wouldn’t it be better to move the check to the API layer so that the request can be failed rather than silently ignored ? As far as I can see: baremetal: Doesn’t support resize hyperv: Checks only for root disk (https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L99-L108 ) libvirt: fails for a reduction of either root or ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4918-L4923 ) vmware: doesn’t seem to check at all ? xen: Allows resize down for root but not for ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L1015-L1032 ) It feels kind of clumsy to have such a wide variation of behavior across the drivers, and to have the check performed only in the driver ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 06/13/2014 08:03 AM, Day, Phil wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. That's what I thought -- but many of the drivers seem to at least partially support it based on the code, hence the question on here to find out of that is really supported and works -- or is just inconsistent error checking across drivers. My grumpy dev answer is that what works is not resizing down. I'm familiar with the xen driver resize operation and will say that it does work when the guest filesystem and partition sizes are accommodating, but there's no good way to know whether or not it will succeed without actually trying it. So when it fails it's after someone was waiting on a resize that seemed like it was working and then suddenly didn't. If we want to aim for what's going to work consistently across drivers, it's probably going to end up being not resizing disks down. *From:*Aryeh Friedman [mailto:aryeh.fried...@gmail.com] *Sent:* 13 June 2014 11:12 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? Theoretically impossible to reduce disk unless you have some really nasty guest additions. On Fri, Jun 13, 2014 at 6:02 AM, Day, Phil philip@hp.com mailto:philip@hp.com wrote: Hi Folks, I was looking at the resize code in libvirt, and it has checks which raise an exception if the target root or ephemeral disks are smaller than the current ones -- which seems fair enough I guess (you can't drop arbitary disk content on resize), except that the because the check is in the virt driver the effect is to just ignore the request (the instance remains active rather than going to resize-verify). It made me wonder if there were any hypervisors that actually allow this, and if not wouldn't it be better to move the check to the API layer so that the request can be failed rather than silently ignored ? As far as I can see: baremetal: Doesn't support resize hyperv: Checks only for root disk (https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L99-L108 ) libvirt: fails for a reduction of either root or ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4918-L4923 ) vmware: doesn't seem to check at all ? xen: Allows resize down for root but not for ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L1015-L1032 ) It feels kind of clumsy to have such a wide variation of behavior across the drivers, and to have the check performed only in the driver ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
I guess the question I'm really asking here is: Since we know resize down won't work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ? From: Andrew Laski [mailto:andrew.la...@rackspace.com] Sent: 13 June 2014 13:57 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 06/13/2014 08:03 AM, Day, Phil wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. That's what I thought - but many of the drivers seem to at least partially support it based on the code, hence the question on here to find out of that is really supported and works - or is just inconsistent error checking across drivers. My grumpy dev answer is that what works is not resizing down. I'm familiar with the xen driver resize operation and will say that it does work when the guest filesystem and partition sizes are accommodating, but there's no good way to know whether or not it will succeed without actually trying it. So when it fails it's after someone was waiting on a resize that seemed like it was working and then suddenly didn't. If we want to aim for what's going to work consistently across drivers, it's probably going to end up being not resizing disks down. From: Aryeh Friedman [mailto:aryeh.fried...@gmail.com] Sent: 13 June 2014 11:12 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? Theoretically impossible to reduce disk unless you have some really nasty guest additions. On Fri, Jun 13, 2014 at 6:02 AM, Day, Phil philip@hp.commailto:philip@hp.com wrote: Hi Folks, I was looking at the resize code in libvirt, and it has checks which raise an exception if the target root or ephemeral disks are smaller than the current ones - which seems fair enough I guess (you can't drop arbitary disk content on resize), except that the because the check is in the virt driver the effect is to just ignore the request (the instance remains active rather than going to resize-verify). It made me wonder if there were any hypervisors that actually allow this, and if not wouldn't it be better to move the check to the API layer so that the request can be failed rather than silently ignored ? As far as I can see: baremetal: Doesn't support resize hyperv: Checks only for root disk (https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L99-L108 ) libvirt: fails for a reduction of either root or ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4918-L4923 ) vmware: doesn't seem to check at all ? xen: Allows resize down for root but not for ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L1015-L1032 ) It feels kind of clumsy to have such a wide variation of behavior across the drivers, and to have the check performed only in the driver ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 06/13/2014 09:22 AM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 for consistency. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On Fri, Jun 13, 2014, Russell Bryant rbry...@redhat.com wrote: On 06/13/2014 09:22 AM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 for consistency. +1 for having written the code for the xenapi driver and not wishing that on anyone else :) JE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
I think that is a very good point. This should maybe be addressed in the API layer as you have suggested. Thanks Gary From: Day, Phil Day philip@hp.commailto:philip@hp.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, June 13, 2014 at 4:22 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? I guess the question I'm really asking here is: Since we know resize down won't work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ? From: Andrew Laski [mailto:andrew.la...@rackspace.com] Sent: 13 June 2014 13:57 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? On 06/13/2014 08:03 AM, Day, Phil wrote: Theoretically impossible to reduce disk unless you have some really nasty guest additions. That's what I thought - but many of the drivers seem to at least partially support it based on the code, hence the question on here to find out of that is really supported and works - or is just inconsistent error checking across drivers. My grumpy dev answer is that what works is not resizing down. I'm familiar with the xen driver resize operation and will say that it does work when the guest filesystem and partition sizes are accommodating, but there's no good way to know whether or not it will succeed without actually trying it. So when it fails it's after someone was waiting on a resize that seemed like it was working and then suddenly didn't. If we want to aim for what's going to work consistently across drivers, it's probably going to end up being not resizing disks down. From: Aryeh Friedman [mailto:aryeh.fried...@gmail.com] Sent: 13 June 2014 11:12 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ? Theoretically impossible to reduce disk unless you have some really nasty guest additions. On Fri, Jun 13, 2014 at 6:02 AM, Day, Phil philip@hp.commailto:philip@hp.com wrote: Hi Folks, I was looking at the resize code in libvirt, and it has checks which raise an exception if the target root or ephemeral disks are smaller than the current ones - which seems fair enough I guess (you can't drop arbitary disk content on resize), except that the because the check is in the virt driver the effect is to just ignore the request (the instance remains active rather than going to resize-verify). It made me wonder if there were any hypervisors that actually allow this, and if not wouldn't it be better to move the check to the API layer so that the request can be failed rather than silently ignored ? As far as I can see: baremetal: Doesn't support resize hyperv: Checks only for root disk (https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L99-L108https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py%23L99-L108k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=1meUXb4syMIPy2G%2BHcsy3qccL7i2ULAgEaQdNbTNnOk%3D%0As=18797dc88941e101a48538fe1b7e74595d19af8bd10c4305df404b5309ee66f2 ) libvirt: fails for a reduction of either root or ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4918-L4923https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py%23L4918-L4923k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=1meUXb4syMIPy2G%2BHcsy3qccL7i2ULAgEaQdNbTNnOk%3D%0As=a00cd8642bba9bd0a6b788f3aabdeace918e86a6129ace3bce316a9d3a613592 ) vmware: doesn't seem to check at all ? xen: Allows resize down for root but not for ephemeral (https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L1015-L1032https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py%23L1015-L1032k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=1meUXb4syMIPy2G%2BHcsy3qccL7i2ULAgEaQdNbTNnOk%3D%0As=7507996a7fb34b0497f85386caf7980f73d0c90fe2f59e15b3c4c87e30157e82 ) It feels kind of clumsy to have such a wide variation of behavior across the drivers, and to have the check performed only in the driver ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.orghttps
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On Fri, Jun 13, 2014, Andrew Laski andrew.la...@rackspace.com wrote: On 06/13/2014 10:53 AM, Johannes Erdfelt wrote: On Fri, Jun 13, 2014, Russell Bryant rbry...@redhat.com wrote: On 06/13/2014 09:22 AM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 for consistency. +1 for having written the code for the xenapi driver and not wishing that on anyone else :) I'm also +1. But this is a feature that's offered by some cloud providers so removing it may cause some pain even with a deprecation cycle. Yeah, that's the hard part about this. On the flip side, supporting it going forward will be a pain too. The xenapi implementation only works on ext[234] filesystems. That rules out *BSD, Windows and Linux distributions that don't use ext[234]. RHEL7 defaults to XFS for instance. In some cases, we couldn't even support resize down (XFS doesn't support it). That is to go along with all of the other problems with resize down as it currently stands. JE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On Fri, Jun 13, 2014 at 08:24:04AM -0700, Johannes Erdfelt wrote: On Fri, Jun 13, 2014, Andrew Laski andrew.la...@rackspace.com wrote: On 06/13/2014 10:53 AM, Johannes Erdfelt wrote: On Fri, Jun 13, 2014, Russell Bryant rbry...@redhat.com wrote: On 06/13/2014 09:22 AM, Day, Phil wrote: I guess the question I’m really asking here is: “Since we know resize down won’t work in all cases, and the failure if it does occur will be hard for the user to detect, should we just block it at the API layer and be consistent across all Hypervisors ?” +1 for consistency. +1 for having written the code for the xenapi driver and not wishing that on anyone else :) I'm also +1. But this is a feature that's offered by some cloud providers so removing it may cause some pain even with a deprecation cycle. Yeah, that's the hard part about this. On the flip side, supporting it going forward will be a pain too. The xenapi implementation only works on ext[234] filesystems. That rules out *BSD, Windows and Linux distributions that don't use ext[234]. RHEL7 defaults to XFS for instance. Presumably it'll have a hard time if the guest uses LVM for its image or does luks encryption, or anything else that's more complex than just a plain FS in a partition. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
On 06/13/14 16:37, Daniel P. Berrange wrote: The xenapi implementation only works on ext[234] filesystems. That rules out *BSD, Windows and Linux distributions that don't use ext[234]. RHEL7 defaults to XFS for instance. Presumably it'll have a hard time if the guest uses LVM for its image or does luks encryption, or anything else that's more complex than just a plain FS in a partition. For example ZFS, which doesn't currently support device removal (except for mirror detach) or device size shrink (but does support device grow). ZFS does support file system resize but file systems are just logical things within a storage pool (made up of 1 or more devices) so that has nothing to do with the block device size. -- Darren J Moffat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
Also ZFS needs to know what is on the guest for example bhyve (the only working hv for bsd currency [vbox kind of also works]) stores the backing store (unless bare metal) as single block file. It is impossible to make that non-opaque to the outside world unless you can run commands on the instance. On Fri, Jun 13, 2014 at 11:53 AM, Darren J Moffat darren.mof...@oracle.com wrote: On 06/13/14 16:37, Daniel P. Berrange wrote: The xenapi implementation only works on ext[234] filesystems. That rules out *BSD, Windows and Linux distributions that don't use ext[234]. RHEL7 defaults to XFS for instance. Presumably it'll have a hard time if the guest uses LVM for its image or does luks encryption, or anything else that's more complex than just a plain FS in a partition. For example ZFS, which doesn't currently support device removal (except for mirror detach) or device size shrink (but does support device grow). ZFS does support file system resize but file systems are just logical things within a storage pool (made up of 1 or more devices) so that has nothing to do with the block device size. -- Darren J Moffat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
