[ovirt-users] Re: Thin Provisioned to Preallocated
On Mon, Aug 10, 2020 at 2:26 AM Nir Soffer wrote: > > On Thu, Aug 6, 2020 at 5:35 PM Jorge Visentini > wrote: > > > > Hi oVirt land. > > > > Can I convert the disks of Thin Provision to Preallocated? > > We don't have a way to convert the format for the same disk. > > We should have this in future version, since it is important for > incremental backup. See https://bugzilla.redhat.com/98 > > The most flexible way now is to download and upload the disk. During > upload you can > convert the disk format. > > Here is an example: > > Download qcow2 disks to raw-sparse format: > > $ ./download_disk.py \ > --engine-url https://engine3 \ > --username admin@internal \ > --password-file engine3-password \ > --cafile engine3.pem \ > --format raw \ > 58daea80-1229-4c6b-b33c-1a4e568c8ad7 \ > /var/tmp/download.raw > Connecting... > Creating image transfer... > Transfer ID: fe4c3409-7e82-4d68-a68b-8b61b9d70647 > Transfer host name: host4 > Downloading image... > Formatting '/var/tmp/download.raw', fmt=raw size=6442450944 > [ 100.00% ] 6.00 GiB, 9.45 seconds, 650.28 MiB/s > Finalizing image transfer... > > $ qemu-img info /var/tmp/download.raw > image: /var/tmp/download.raw > file format: raw > virtual size: 6 GiB (6442450944 bytes) > disk size: 2.18 GiB > > We could download also to qcow2 format, this was just an example how > you can convert the format during download. > > Now upload back to new disk in raw preallocated format. > > $ ./upload_disk.py \ > --engine-url https://engine3 \ > --username admin@internal \ > --password-file engine3-password \ > --cafile engine3.pem \ > --sd-name nfs1 \ > --disk-format raw \ > /var/tmp/download.raw > Checking image... > Image format: raw > Disk format: raw > Disk content type: data > Disk provisioned size: 6442450944 > Disk initial size: 6442450944 > Disk name: download.raw > Disk backup: False > Connecting... > Creating disk... > Disk ID: beb2435e-9607-4a09-b6a6-b5e5f4ae9fd8 > Creating image transfer... > Transfer ID: b9fd2ad9-be85-4db8-998b-c5f981f8103c > Transfer host name: host4 > Uploading image... > [ 100.00% ] 6.00 GiB, 5.30 seconds, 1.13 GiB/s > Finalizing image transfer... > Upload completed successfully > > You can replace now the old thin disk (58daea80-1229-4c6b-b33c-1a4e568c8ad7) > with the new preallocated disk (beb2435e-9607-4a09-b6a6-b5e5f4ae9fd8). > > Nir ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TUIMTUWKX3YOCGMKUCFFRSX57HCJCNJ2/
[ovirt-users] Re: Thin Provisioned to Preallocated
On Thu, Aug 6, 2020 at 5:35 PM Jorge Visentini wrote: > > Hi oVirt land. > > Can I convert the disks of Thin Provision to Preallocated? We don't have a way to convert the format for the same disk. We should have this in future version, since it is important for incremental backup. The most flexible way now is to download and upload the disk. During upload you can convert the disk format. Here is an example: Download qcow2 disks to raw-sparse format: $ ./download_disk.py \ --engine-url https://engine3 \ --username admin@internal \ --password-file engine3-password \ --cafile engine3.pem \ --format raw \ 58daea80-1229-4c6b-b33c-1a4e568c8ad7 \ /var/tmp/download.raw Connecting... Creating image transfer... Transfer ID: fe4c3409-7e82-4d68-a68b-8b61b9d70647 Transfer host name: host4 Downloading image... Formatting '/var/tmp/download.raw', fmt=raw size=6442450944 [ 100.00% ] 6.00 GiB, 9.45 seconds, 650.28 MiB/s Finalizing image transfer... $ qemu-img info /var/tmp/download.raw image: /var/tmp/download.raw file format: raw virtual size: 6 GiB (6442450944 bytes) disk size: 2.18 GiB We could download also to qcow2 format, this was just an example how you can convert the format during download. Now upload back to new disk in raw preallocated format. $ ./upload_disk.py \ --engine-url https://engine3 \ --username admin@internal \ --password-file engine3-password \ --cafile engine3.pem \ --sd-name nfs1 \ --disk-format raw \ /var/tmp/download.raw Checking image... Image format: raw Disk format: raw Disk content type: data Disk provisioned size: 6442450944 Disk initial size: 6442450944 Disk name: download.raw Disk backup: False Connecting... Creating disk... Disk ID: beb2435e-9607-4a09-b6a6-b5e5f4ae9fd8 Creating image transfer... Transfer ID: b9fd2ad9-be85-4db8-998b-c5f981f8103c Transfer host name: host4 Uploading image... [ 100.00% ] 6.00 GiB, 5.30 seconds, 1.13 GiB/s Finalizing image transfer... Upload completed successfully You can replace now the old thin disk (58daea80-1229-4c6b-b33c-1a4e568c8ad7) with the new preallocated disk (beb2435e-9607-4a09-b6a6-b5e5f4ae9fd8). Nir ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TKO5DVRPURQ66QVUQZBHEX73MOC6VPH7/
[ovirt-users] Re: Do distinct export domains share a name space? Can't export a VM, because it already exists in an unattached export domain...
On Mon, Aug 10, 2020 at 1:01 AM Strahil Nikolov wrote: > > Thanks Nir, flr the detailed explanation. > Can you tell me with export/import data domains, what happens to VMs with > snapshots. Snapshots are not affected by moving disks to different storage domains. It copies the entire chain from one domain to the other. If you want collapsed snapshots you need to use export VM (4.4+), clone VM, or make template. > Recently it was mentioned that snapahots are not visible after such migration. Can you point to the thread about this? > > Best Regards, > Strahil Nikolov > > На 10 август 2020 г. 0:00:36 GMT+03:00, Nir Soffer > написа: > >On Wed, Aug 5, 2020 at 7:00 PM wrote: > >> > >> After OVA export/import was a) recommended against b) not working > >with the current 4.3 on CentOS 7, I am trying to make sure I keep > >working copies of critical VMs before I test if the OVA export now > >works properly, with the Redhat fix from 4.4. applied to 4.3. > >> > >> Long story short, I have an export domain "export", primarily > >attached to a 3 node HCI gluster-cluster and another domain > >"exportMono", primarily attached to a single node HCI gluster-cluster. > >> > >> Yes I use an export domain for backup, because, ...well there is no > >easy and working alternative out of the box, or did I overlook > >something? > >> But of course, I also use an export domain for shipping between > >farms, so evidently I swap export domains like good old PDP-11 disk > >cartridges or at least I'd like to. > >> > >> > >> I started by exporting VM "tdc" from the 1nHCI to exportMono, > >reattached that to 3nHCI for am import. Import worked everything fine, > >transfer succeed. So I detach exportMono, which belongs to the 1nHCI > >cluster. > >> > >> Next I do the OVA export on 1nHCI, but I need to get the working and > >reconfigured VM "tdc" out of the way on 3nHCI, so I dump it into the > >"export" export domain belonging to 3nHCI, because I understand I can't > >run two copies of the same VM on a single cluster. > >> > >> Turns out I can' export it, because even if the export domain is now > >a different one and definitely doesn't contain "tdc" at all, oVirt > >complains that the volume ID that belongs to "tdc" already exists in > >the export domain > >> > >> So what's the theory here behind export domains? And what's the state > >of their support in oVirt 4.4? > > > >Export domains are deprecated for several releases, but they were not > >removed > >in 4.4, mainly to make it easier to upgrade to 4.4. > > > >They are deprecated because we have better solutions, mainly export > >import data > >domain (since 3.6), and also upload/download disks (since 4.0), and > >export/import > >OVA. > > > >To move a VM to another environment using a data domain in 4.3: > >- Create or attach a data storage domain of any type to use as an > >"export" domain > >- Move the VM disks to the data domain. This can be done while the VM > >is running. > >- Stop the exported VM. > >- Detach the data domain from the system > >- Attach the data domain to another system > >- Import the VM from the data domain > >- Start the imported VM > >- If you want to continue using this data domain as an export domain, > >move the VM disks to another domain. This can be done while the VM is > >running. > > > >This minimizes the downtime to the time it takes to detach the domain > >from one system > >and attach to another system. If you don't care about downtime, you > >can stop the VM > >before the export and start it after copying the imported VM disks. > >This is much simpler > >and more reliable. > > > >In the best case, when you have a data domain that you want to move to > >another system, > >no data copy is needed. In the worst case when you want to move VM > >from one storage > >on another storage on another system, you need to move the disks twice > >- just like export > >domain. > > > >If you want to move the VM to another hypervisor, OVA export is not > >helpful since OVA is > >not a real standard and hypervisors do not support other hypervisor > >OVAs without some > >conversion tool such as virt-v2v. oVirt uses virt-v2v to import VMWare > >OVA to oVirt. I don't > >know if this tool supports converting oVirt OVA to other hypervisors. > > > >To move VM disks out of the system in 4.3: > >- Stop the VM, or create a snapshot. > >- Create a template from the VM or the snapshot, selecting qcow2 format > >- Start the VM if needed, or delete the snapshot. > >- Download the template disks, from the UI or using the API/SDK if you > >want a faster > > download that can be scripted. > >- Delete the template if not needed > > > >Why create a template instead of cloning the VM? because cloning may > >create raw > >preallocated disks (depending on the storage type and the original VM) > >and downloading > >a preallocated disk is not efficient and creates fully preallocated > >images which are much > >larger than needed. > > > >To move the disk back to oVirt,
[ovirt-users] Re: Do distinct export domains share a name space? Can't export a VM, because it already exists in an unattached export domain...
Thanks Nir, flr the detailed explanation. Can you tell me with export/import data domains, what happens to VMs with snapshots. Recently it was mentioned that snapahots are not visible after such migration. Best Regards, Strahil Nikolov На 10 август 2020 г. 0:00:36 GMT+03:00, Nir Soffer написа: >On Wed, Aug 5, 2020 at 7:00 PM wrote: >> >> After OVA export/import was a) recommended against b) not working >with the current 4.3 on CentOS 7, I am trying to make sure I keep >working copies of critical VMs before I test if the OVA export now >works properly, with the Redhat fix from 4.4. applied to 4.3. >> >> Long story short, I have an export domain "export", primarily >attached to a 3 node HCI gluster-cluster and another domain >"exportMono", primarily attached to a single node HCI gluster-cluster. >> >> Yes I use an export domain for backup, because, ...well there is no >easy and working alternative out of the box, or did I overlook >something? >> But of course, I also use an export domain for shipping between >farms, so evidently I swap export domains like good old PDP-11 disk >cartridges or at least I'd like to. >> >> >> I started by exporting VM "tdc" from the 1nHCI to exportMono, >reattached that to 3nHCI for am import. Import worked everything fine, >transfer succeed. So I detach exportMono, which belongs to the 1nHCI >cluster. >> >> Next I do the OVA export on 1nHCI, but I need to get the working and >reconfigured VM "tdc" out of the way on 3nHCI, so I dump it into the >"export" export domain belonging to 3nHCI, because I understand I can't >run two copies of the same VM on a single cluster. >> >> Turns out I can' export it, because even if the export domain is now >a different one and definitely doesn't contain "tdc" at all, oVirt >complains that the volume ID that belongs to "tdc" already exists in >the export domain >> >> So what's the theory here behind export domains? And what's the state >of their support in oVirt 4.4? > >Export domains are deprecated for several releases, but they were not >removed >in 4.4, mainly to make it easier to upgrade to 4.4. > >They are deprecated because we have better solutions, mainly export >import data >domain (since 3.6), and also upload/download disks (since 4.0), and >export/import >OVA. > >To move a VM to another environment using a data domain in 4.3: >- Create or attach a data storage domain of any type to use as an >"export" domain >- Move the VM disks to the data domain. This can be done while the VM >is running. >- Stop the exported VM. >- Detach the data domain from the system >- Attach the data domain to another system >- Import the VM from the data domain >- Start the imported VM >- If you want to continue using this data domain as an export domain, >move the VM disks to another domain. This can be done while the VM is >running. > >This minimizes the downtime to the time it takes to detach the domain >from one system >and attach to another system. If you don't care about downtime, you >can stop the VM >before the export and start it after copying the imported VM disks. >This is much simpler >and more reliable. > >In the best case, when you have a data domain that you want to move to >another system, >no data copy is needed. In the worst case when you want to move VM >from one storage >on another storage on another system, you need to move the disks twice >- just like export >domain. > >If you want to move the VM to another hypervisor, OVA export is not >helpful since OVA is >not a real standard and hypervisors do not support other hypervisor >OVAs without some >conversion tool such as virt-v2v. oVirt uses virt-v2v to import VMWare >OVA to oVirt. I don't >know if this tool supports converting oVirt OVA to other hypervisors. > >To move VM disks out of the system in 4.3: >- Stop the VM, or create a snapshot. >- Create a template from the VM or the snapshot, selecting qcow2 format >- Start the VM if needed, or delete the snapshot. >- Download the template disks, from the UI or using the API/SDK if you >want a faster > download that can be scripted. >- Delete the template if not needed > >Why create a template instead of cloning the VM? because cloning may >create raw >preallocated disks (depending on the storage type and the original VM) >and downloading >a preallocated disk is not efficient and creates fully preallocated >images which are much >larger than needed. > >To move the disk back to oVirt, upload the disk to oVirt and create a >new VM. >This can be done from the UI or using the API/SDK. > >The entire process can be scripted. In 4.4 backup_vm.py example does >all this without >creating snapshot or templates (see my previous mail about backup). > >> I understand that distinct farms can't share an export domain, >because they have no way of coordinating properly. Of course I tried to >use one single NFS mount for both farms but the second farm properly >detected the presense of another and required a distinct path. >> >> But from the
[ovirt-users] Re: Fail to upload image file after Replace oVirt Engine SSL/TLS Certificate
On Mon, Aug 3, 2020 at 8:55 AM zhou...@vip.friendtimes.net
wrote:
>
> I replaced my Certificate follow
> https://myhomelab.gr/linux/2020/01/20/replacing_ovirt_ssl.html
> Then I cant upload image files
We need basic detail on this issue like oVirt version used, but this
smells like this bug:
https://bugzilla.redhat.com/1862107
Note that this issue is only about the proxy, you can upload images
directly the host using
the SDK:
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py
Here is example upload on my test environment:
$ ./upload_disk.py --engine-url https://engine3 \
--username admin@internal \
--password-file engine3-password \
--cafile engine3.pem \
--sd-name nfs1 \
--disk-format raw \
--disk-sparse \
/var/tmp/fedora-32.raw
Checking image...
Image format: raw
Disk format: raw
Disk content type: data
Disk provisioned size: 6442450944
Disk initial size: 6442450944
Disk name: fedora-32.raw
Disk backup: False
Connecting...
Creating disk...
Disk ID: 139c29a3-b9a8-4501-836d-92417c3d2eaf
Creating image transfer...
Transfer ID: d50a1b50-5bd8-417e-a950-d3a19a262daa
Transfer host name: host4
Uploading image...
[ 100.00% ] 6.00 GiB, 3.01 seconds, 1.99 GiB/s
Finalizing image transfer...
Upload completed successfully
Nir
> THE LOGS BELOW
>
> 2020-08-03 13:37:42,276+08 INFO
> [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand]
> (default task-28) [272b83fa-1d1a-473e-b72a-19886433801e] Running command:
> TransferImageStatusCommand internal: false. Entities affected : ID:
> aaa0----123456789aaa Type: SystemAction group CREATE_DISK
> with role type USER
> 2020-08-03 13:37:43,679+08 INFO
> [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-27) []
> User yuanq...@ft.com successfully logged in with scopes: ovirt-app-admin
> ovirt-app-api ovirt-app-portal ovirt-ext=auth:sequence-priority=~
> ovirt-ext=revoke:revoke-all ovirt-ext=token-info:authz-search
> ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate
> ovirt-ext=token:password-access
> 2020-08-03 13:37:43,773+08 INFO
> [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-27)
> [1e6c5da4] Running command: CreateUserSessionCommand internal: false.
> 2020-08-03 13:37:43,814+08 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-27) [1e6c5da4] EVENT_ID: USER_VDC_LOGIN(30), User
> yuanq...@ft.com@ft.com connecting from '192.168.16.199' using session
> 'AkdaHSmXHYlF3v53VoJRWVCIp0VYjFJPcR/vbRs0tfT20Qq9zylnacmSQKJJ8kwkWmj392Lq8j6EFcz22BKdTg=='
> logged in.
> 2020-08-03 13:37:44,428+08 INFO
> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback]
> (EE-ManagedThreadFactory-engineScheduled-Thread-35)
> [2a5567e7-25bc-4d58-ab31-8f88f5a4a5fa] Command 'AddDisk' id:
> '0f22fdf1-6016-40f3-9768-b436b5c83972' child commands
> '[abaa6f3d-82a1-4317-857e-0c32e3ffeca1]' executions were completed, status
> 'SUCCEEDED'
> 2020-08-03 13:37:44,428+08 INFO
> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback]
> (EE-ManagedThreadFactory-engineScheduled-Thread-35)
> [2a5567e7-25bc-4d58-ab31-8f88f5a4a5fa] Command 'AddDisk' id:
> '0f22fdf1-6016-40f3-9768-b436b5c83972' Updating status to 'SUCCEEDED', The
> command end method logic will be executed by one of its parent commands.
> 2020-08-03 13:37:44,488+08 INFO
> [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-35)
> [2a5567e7-25bc-4d58-ab31-8f88f5a4a5fa] Successfully added Upload disk
> 'vyos-1.1.8-amd64.iso' (disk id: '2720658b-c1cb-4021-810c-8333e80858eb',
> image id: '6a61dee5-fc07-4afb-af81-3672b9077a3a') for image transfer command
> '900b725e-d409-4192-bb52-c52cb29b37ee'
> 2020-08-03 13:37:44,524+08 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PrepareImageVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-35)
> [2a5567e7-25bc-4d58-ab31-8f88f5a4a5fa] START, PrepareImageVDSCommand(HostName
> = 192.168.4.23,
> PrepareImageVDSCommandParameters:{hostId='b6142941-cc9e-4da3-b66d-5132f359edb5'}),
> log id: 4bfe1a2c
> 2020-08-03 13:37:44,640+08 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PrepareImageVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-35)
> [2a5567e7-25bc-4d58-ab31-8f88f5a4a5fa] FINISH, PrepareImageVDSCommand,
> return: PrepareImageReturn:{status='Status [code=0, message=Done]'}, log id:
> 4bfe1a2c
> 2020-08-03 13:37:44,641+08 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.SetVolumeLegalityVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-35)
> [2a5567e7-25bc-4d58-ab31-8f88f5a4a5fa] START, SetVolumeLegalityVDSCommand(
> SetVolumeLegalityVDSCommandParameters:{storagePoolId='17fae97b-4a94-4de5-88c0-0743ab2b9ab8',
> ignoreFailoverLimit='false',
> storageDomainId='0d707e2b-42ed-48d4-9675-2021a3840f40',
>
[ovirt-users] Re: OVA export creates empty and unusable images
On Tue, Aug 4, 2020 at 7:37 PM wrote: > > Nir, first of all, thanks a lot for the detailed description and the quick > fix in 4.4! > > I guess I'll be able to paste that single line fix into the 4.3. variant > myself, but I'd rather see that included in the next 4.3 release, too: How > would that work? > > --- > "OVA is not a backup solution": > > From time to time, try to put youself into a user's shoes. > > The fist thing you read about Export Domains, is that they are deprecated: > That doesn't give you the warm fuzzy feeling that you are learning something > useful when you start using them, especially in the context of a migration to > the next release. This is good, you should not use export domain at this point. We have better replacement (see my other mail). > OVA on the other hand, stands for a maximum of interoperability and when > given a choice between something proprietary and deprecated and a file format > that will port pretty much everywhere, any normal user (who doesn't have the > code behind the scene in his mind), will jump for OVA export/import. I think you already found that OVA are not what you think they are. They work for exporting VMs from the same hypervisor and back, unless you have a tool that know how to convert OVA from one hypervisor to another like virt-v2v. > Also it's just two buttons, no hassle, while it took me a while to get an > Export domain defined, filled, detached, re-attached, and tested. True, ease of use is important. But if you are going to do this a lost, scripting the operation is important, and oVirt has a very powerful API/SDK. > Again from a user's perspective: HCI gluster storage in oVirt is black magic, > especially since disk images are all chunked up. For a user it will probably > take many years of continous oVirt operation until he's confident that he'l > recover VM storage in the case of a serious hickup and that whatever might > have gone wrong or bitrot might have occured, won't carry over to an export > domain. OVA files seem like a nice bet to recover your VM on whatever > platform you can get back running in a minor disaster. What you say is basically that having a backup is useful :-) > In many cases, it doesn't even matter you have to shut down the machine to do > the export, because the machines are application level redundant or simply > it's ok to have them down for a couple of minutes, if you know you can get > them back up no matter what in a comparable time frame, oVirt farm dead or > alive, e.g. on a bare metal machine. How are you going to use the OVA on a bare metal machine? > And then my case, many of the images are just meant to move between an oVirt > farm and a desktop hypervisor. Why do you need the desktop hypervisor? I would like to hear more about this use case. And if you need one, why not use something based on KVM (like virt-manager) so disks from oVirt can work without any change? This will make it easy to move from oVit to desktop hypervisor and back with relatively little effort. > tl;dr > > (working) OVA export and import IMHO are elemental and crucial functionality, > without which oVirt can't be labelled a product. > > I completely appreciate the new backup API, especially with the consistency > enabled for running VMs; perhaps a little less that I'd have to purchase an > extra product to do a fundamental operation with a similar ease as the OVA > export/import buttons, but at least it's there. > > That doesn't mean OVA in/ex isn't important or that in fact a shared > import/export domain would be nice, too. > > Thanks for your time! Thanks Thomas, this is very useful feedback! Nir ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/4RQBNMRDMDEBLVLVVBVPTOSIHCYSEO5I/
[ovirt-users] Re: Do distinct export domains share a name space? Can't export a VM, because it already exists in an unattached export domain...
On Wed, Aug 5, 2020 at 7:00 PM wrote: > > After OVA export/import was a) recommended against b) not working with the > current 4.3 on CentOS 7, I am trying to make sure I keep working copies of > critical VMs before I test if the OVA export now works properly, with the > Redhat fix from 4.4. applied to 4.3. > > Long story short, I have an export domain "export", primarily attached to a 3 > node HCI gluster-cluster and another domain "exportMono", primarily attached > to a single node HCI gluster-cluster. > > Yes I use an export domain for backup, because, ...well there is no easy and > working alternative out of the box, or did I overlook something? > But of course, I also use an export domain for shipping between farms, so > evidently I swap export domains like good old PDP-11 disk cartridges or > at least I'd like to. > > > I started by exporting VM "tdc" from the 1nHCI to exportMono, reattached that > to 3nHCI for am import. Import worked everything fine, transfer succeed. So I > detach exportMono, which belongs to the 1nHCI cluster. > > Next I do the OVA export on 1nHCI, but I need to get the working and > reconfigured VM "tdc" out of the way on 3nHCI, so I dump it into the "export" > export domain belonging to 3nHCI, because I understand I can't run two copies > of the same VM on a single cluster. > > Turns out I can' export it, because even if the export domain is now a > different one and definitely doesn't contain "tdc" at all, oVirt complains > that the volume ID that belongs to "tdc" already exists in the export > domain > > So what's the theory here behind export domains? And what's the state of > their support in oVirt 4.4? Export domains are deprecated for several releases, but they were not removed in 4.4, mainly to make it easier to upgrade to 4.4. They are deprecated because we have better solutions, mainly export import data domain (since 3.6), and also upload/download disks (since 4.0), and export/import OVA. To move a VM to another environment using a data domain in 4.3: - Create or attach a data storage domain of any type to use as an "export" domain - Move the VM disks to the data domain. This can be done while the VM is running. - Stop the exported VM. - Detach the data domain from the system - Attach the data domain to another system - Import the VM from the data domain - Start the imported VM - If you want to continue using this data domain as an export domain, move the VM disks to another domain. This can be done while the VM is running. This minimizes the downtime to the time it takes to detach the domain from one system and attach to another system. If you don't care about downtime, you can stop the VM before the export and start it after copying the imported VM disks. This is much simpler and more reliable. In the best case, when you have a data domain that you want to move to another system, no data copy is needed. In the worst case when you want to move VM from one storage on another storage on another system, you need to move the disks twice - just like export domain. If you want to move the VM to another hypervisor, OVA export is not helpful since OVA is not a real standard and hypervisors do not support other hypervisor OVAs without some conversion tool such as virt-v2v. oVirt uses virt-v2v to import VMWare OVA to oVirt. I don't know if this tool supports converting oVirt OVA to other hypervisors. To move VM disks out of the system in 4.3: - Stop the VM, or create a snapshot. - Create a template from the VM or the snapshot, selecting qcow2 format - Start the VM if needed, or delete the snapshot. - Download the template disks, from the UI or using the API/SDK if you want a faster download that can be scripted. - Delete the template if not needed Why create a template instead of cloning the VM? because cloning may create raw preallocated disks (depending on the storage type and the original VM) and downloading a preallocated disk is not efficient and creates fully preallocated images which are much larger than needed. To move the disk back to oVirt, upload the disk to oVirt and create a new VM. This can be done from the UI or using the API/SDK. The entire process can be scripted. In 4.4 backup_vm.py example does all this without creating snapshot or templates (see my previous mail about backup). > I understand that distinct farms can't share an export domain, because they > have no way of coordinating properly. Of course I tried to use one single NFS > mount for both farms but the second farm properly detected the presense of > another and required a distinct path. > > But from the evidence before me, oVirt doesn't support or like the existance > of more than one export domain, either: Something that deserves a note or > explanation. Yes, export domains have many limitations. > I understand they are deprecated in 4.3 already, but since they are also the > only way to manage valuable VM images moving around, that currently
[ovirt-users] Re: Support for Shared SAS storage
On Sat, Aug 8, 2020 at 6:56 AM Jeff Bailey wrote: > > I haven't tried with 4.4 but shared SAS works just fine with 4.3 (and has for > many, many years). You simply treat it as Fibre Channel. If your LUNs > aren't showing up I'd make sure they're being claimed as multipath devices. > You want them to be. After that, just make sure they're sufficiently wiped > so they don't look like they're in use. Correct. FC in oVirt means actually not "iSCSI". Any device - including local devices - that multipath expose, and is not iSCSI is considered as FC. This is not officially supported and not documented anywhere. I learned about it only we tried to deploy strict multipath blacklist allowing only "iscsi" or "fc" transport, and found that it broke users' setups with sas other esoteric storage. Since 4.4 is the last feature release, this will never change even if it is not documented. Nir > On 8/7/2020 10:49 PM, Lao Dh via Users wrote: > > Wow. That's sound bad. Then what storage type you choose at last (with your > SAS connected storage)? VMware vSphere support DAS. Red Hat should do > something. > > 2020年8月8日土曜日 4:06:34 GMT+8、Vinícius Ferrão via Users が書いたメール: > > > No, there’s no support for direct attached shared SAS storage on oVirt/RHV. > > Fibre Channel is a different thing that oVirt/RHV supports. > > > On 7 Aug 2020, at 08:52, hkexdong--- via Users wrote: > > > > Hello Vinícius, > > Do you able to connect the SAS external storage? > > Now I've the problem during host engine setup. Select Fibre Channel and end > > up show "No LUNS found". > > ___ > > Users mailing list -- users@ovirt.org > > To unsubscribe send an email to users-le...@ovirt.org > > Privacy Statement: https://www.ovirt.org/privacy-policy.html > > oVirt Code of Conduct: > > https://www.ovirt.org/community/about/community-guidelines/ > > List Archives: > > https://lists.ovirt.org/archives/list/users@ovirt.org/message/RDPLKGIRN5ZGIEPWGOKMGNFZNMCEN5RC/ > > > ___ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/2CLI3YSYU7BPI62YANJXZV7RIQFOXXED/ > > > ___ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/WOBHQDCBZZK5WKRAUNHP5CGFYY3HQYYU/ > > ___ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/UY52JRY5EMQJTMKG3POE2YXSFGL7P55S/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/JYWUVULGUNLTU6QOY6WOUKBCA5IAO5QR/
[ovirt-users] Re: Thin Provisioned to Preallocated
In regular KVM thin disks can be made fully preallocated when you 'expand' them to the predefined maximum size. Usually I create a large file and then I delete it. Something like this: 'dd if=/dev/zero of=/path/to/mounted/qcow2/disk/largefile bs=4M status=progress ; rm -f /path/to/mounted/qcow2/disk/largefile I doubt it's different in oVirt as backend is the same (KVM/qemu/raw or qcow2). Best Regards, Strahil Nikolov На 9 август 2020 г. 10:15:26 GMT+03:00, Eyal Shenitzky написа: >Hi Jorge, > >Currently, there is no mechanism for doing this operation on the disk, >but >there is workaround such as: > >- Export the VM as OVA or to an export domain and import it back with >the >needed allocation method. > >On Thu, 6 Aug 2020 at 17:36, Jorge Visentini >wrote: > >> Hi oVirt land. >> >> Can I convert the disks of Thin Provision to Preallocated? >> >> Best Regards. >> -- >> Att, >> Jorge Visentini >> +55 55 98432-9868 >> ___ >> Users mailing list -- users@ovirt.org >> To unsubscribe send an email to users-le...@ovirt.org >> Privacy Statement: https://www.ovirt.org/privacy-policy.html >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> >https://lists.ovirt.org/archives/list/users@ovirt.org/message/M5DGZFUB5KVW6LWQKRC5NFDUMOUN7RKD/ >> ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/56AYNQOQ245BT3GRTE3NWIIT3XADLCHN/
[ovirt-users] Re: Thin Provisioned to Preallocated
Hi Jorge, Currently, there is no mechanism for doing this operation on the disk, but there is workaround such as: - Export the VM as OVA or to an export domain and import it back with the needed allocation method. On Thu, 6 Aug 2020 at 17:36, Jorge Visentini wrote: > Hi oVirt land. > > Can I convert the disks of Thin Provision to Preallocated? > > Best Regards. > -- > Att, > Jorge Visentini > +55 55 98432-9868 > ___ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/M5DGZFUB5KVW6LWQKRC5NFDUMOUN7RKD/ > -- Regards, Eyal Shenitzky ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/M3REFS7XBDXIP5WFVFPQ74BMXIVPRFZR/
