Bug 1414499
Summary: | [RFE] ability to download images that are attached to vms | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Natalie Gavrielov <ngavrilo> |
Component: | RFEs | Assignee: | Allon Mureinik <amureini> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Natalie Gavrielov <ngavrilo> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 4.1.0.2 | CC: | amureini, bugs, ratamir, tnisan, ylavi |
Target Milestone: | ovirt-4.1.5 | Keywords: | FutureFeature |
Target Release: | 4.1.5 | Flags: | rule-engine:
ovirt-4.1+
ylavi: planning_ack+ amureini: devel_ack+ ratamir: testing_ack+ |
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Cause:
Uploading/downloading disks attached to VMs was blocked by a validation on the engine's side.
Consequence:
It's impossible to upload/download a disk that's part of a VM. In order to do so, you'd have to detach the disk, upload/download, and then attach it again.
Fix:
Remove the blocking in case the VM is down or the disk is unplugged.
Result:
It's no possible to upload/download any disk that isn't plugged to a non-down VM - i.e., floating disks, disks that are attached but unplugged to any VM, and disks that are plugged to DOWN vms.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2017-08-23 08:05:16 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 659847, 1477922 |
Description
Natalie Gavrielov
2017-01-18 16:26:58 UTC
Allowing upload/download of a disk attached to a non-down VM may require some delicate coordination/locking, but for a DOWN vm(s), this looks like an easy win. (In reply to Allon Mureinik from comment #1) > Allowing upload/download of a disk attached to a non-down VM may require > some delicate coordination/locking, but for a DOWN vm(s), this looks like an > easy win. Actually, unplugged disks for VMs in any state should also be an easy win. I'll add a patch for that too. Can you consider a backport to 4.1.z? (In reply to Yaniv Lavi from comment #3) > Can you consider a backport to 4.1.z? This implementation included some "cleanup" work to unify similar validations throughout the code, which I don't want to bother the z-stream with, but if we take just the minimal fix, it shouldn't be too much of a problem. I'm restoring the needinfo until I evaluate this properly, and either post patches to backport it or have a good explanation why this won't be as easy as I thought. (In reply to Allon Mureinik from comment #4) > (In reply to Yaniv Lavi from comment #3) > > Can you consider a backport to 4.1.z? > > This implementation included some "cleanup" work to unify similar > validations throughout the code, which I don't want to bother the z-stream > with, but if we take just the minimal fix, it shouldn't be too much of a > problem. > I'm restoring the needinfo until I evaluate this properly, and either post > patches to backport it or have a good explanation why this won't be as easy > as I thought. Patches backported. The series still needs some verifications and review, but there's no reason it shouldn't be in by 4.1.5. Verified using builds: ovirt-engine-4.1.5-0.1.el7.noarch ovirt-imageio-proxy-1.0.0-0.el7ev.noarch ovirt-imageio-common-1.0.0-0.el7ev.noarch vdsm-4.19.25-1.el7ev.x86_64 ovirt-imageio-daemon-1.0.0-0.el7ev.noarch |