Bug 1469077
| Summary: | [RFE] Import from kvm source when guest's disk type is volume | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Tomáš Golembiovský <tgolembi> | ||||||
| Component: | RFEs | Assignee: | Tomáš Golembiovský <tgolembi> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Nisim Simsolo <nsimsolo> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 4.19.20 | CC: | bugs, eheftman, juzhou, kuwei, mavital, michal.skrivanek, mxie, mzhan, nsimsolo, ptoscano, rjones, tgolembi, tzheng, virt-bugs, xiaodwan, xuzhang | ||||||
| Target Milestone: | ovirt-4.2.0 | Keywords: | FutureFeature | ||||||
| Target Release: | --- | Flags: | michal.skrivanek:
ovirt-4.2?
gklein: testing_plan_complete+ rule-engine: planning_ack? michal.skrivanek: devel_ack+ rule-engine: testing_ack+ |
||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: |
Previously, it was not possible to import virtual machines containing disks that were of type 'volume'. In this release, it is now possible to import this type of virtual machine.
|
Story Points: | --- | ||||||
| Clone Of: | 1468509 | Environment: | |||||||
| Last Closed: | 2017-12-20 10:51:32 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Comment 1
Tomáš Golembiovský
2017-07-10 11:07:32 UTC
*** Bug 1468944 has been marked as a duplicate of this bug. *** For the context: type='volume' allows user to use disks from storage pool without caring about details how the pool was defined.
For example with the pool 'pool1' deined like:
<pool type="dir">
<name>pool1</name>
<target>
<path>/var/vm_pool/</path>
</target>
</pool>
The following disk definitions are equivalent:
<disk type='file' device='disk'>
<source file='/var/vm_pool/machine1.qcow2'/>
...
</disk>
and
<disk type='volume' device='disk'>
<source pool='pool1' volume='machine1.qcow2'/>
...
</disk>
Created attachment 1333230 [details]
vdsm.log (starts at 2017-10-02 15:59:42)
Created attachment 1333231 [details]
engine.log
The disk definition is wrong:
<disk type='volume' device='disk'>
<driver name='qemu' type='raw'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
There is no <source> element here. You need to add something like:
<source pool='some_pool' volume='some_volume.qcow2' />
Hi Tomas I'm reviewing the doc text and it is not clear to me what you mean by "In this case the disk is described as a storage pool/volume pair." Also, is there any impact on documentation? i.e. is there something that must be manually configure in order for this to work? Thanks Emma (In reply to Emma Heftman from comment #10) > Hi Tomas > I'm reviewing the doc text and it is not clear to me what you mean by "In > this case the disk is described as a storage pool/volume pair." This tells how the disk is defined in libvirt XML of the VM on the source KVM machine. > Also, is there any impact on documentation? i.e. is there something that > must be manually configure in order for this to work? No. (In reply to Tomáš Golembiovský from comment #11) > (In reply to Emma Heftman from comment #10) > > Hi Tomas > > I'm reviewing the doc text and it is not clear to me what you mean by "In > > this case the disk is described as a storage pool/volume pair." > > This tells how the disk is defined in libvirt XML of the VM on the source > KVM machine. > Thanks Tomas. I believe this is too detailed for the Release Notes which describes what the fix/enhancement does, and not how that was achieved. > > Also, is there any impact on documentation? i.e. is there something that > > must be manually configure in order for this to work? > > No. Verification builds: ovirt-engine-4.2.0-0.0.master.20171029154613.git19686f3.el7.centos vdsm-4.20.4-12.git11d6d3d.el7.centos.x86_64 libvirt-client-3.2.0-14.el7_4.3.x86_64 qemu-kvm-common-ev-2.9.0-16.el7_4.8.1.x86_64 Polarion verification test case added to external trackers. This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |