11:42 a.m.
Usually in oVirt you are want your VMs to be on a shared storage, so they can live migrate
between the hosts.
Such shared storages are: iSCSI, SAN, NFS & GlusterFS (CEPH is still
"experimental") or any other POSIX Filesystem.
If you wish to use local storage, previously (I'm not sure if this is possible any
more) the host must be in a separate cluster on a separate Datacenter and then you could
use that local storage.
One way to achive this setup and be able to expand in the future is to use a single-nide
oVirt with single brick (term for server+mountpoint combo) GlusterFS.Adding more servers
in the future will be seamless and without downtime , yet oVirt supports only single
server and 3-server setups (3,6,9,12...n*3).
Of course creating an iSCSI/NFS server from the Hypervisor is possible , but I would not
recommend it as the node becomes single point of failure.
Best Regards,Strahil Nikolov
On Sun, Nov 28, 2021 at 16:23, Nir Soffer<nsoffer(a)redhat.com> wrote: On Sun, Nov
28, 2021 at 2:06 PM <th3penguinwhisperer(a)gmail.com> wrote:
Thanks for your reply. Greatly appreciated.
> The oVirt way is to create a block storage domain, and create a raw
> preallocated disk.
> This will attach a logical volume to the VM.
Problem is that I already have an existing LV that was used before.
But I guess if I mount that LV on the host I could copy all the data over through scp or
similar to the VM with the newly created LV (which requires me to have double the disk
space).
Do I understand correctly that a designated VG is used and LVs are created in it and
those are exposed as iSCSI volumes and mounted as such in the guest OS?
No. It works like this:
1. You configure iSCSI server (e.g. using targetcli), and export one
or more LUNs.
2. You create a iSCSI storage domain in oVirt, connecting to your iSCSI target
3. You select the LUN(s) that should be part of this storage domain
4. oVirt creates a VG with the specified LUN(s)
5. oVirt creates special logical volumes for management (~5G)
6. You create a new disk in oVirt on this storage domain
to use the same raw lv as you used before, use "allocation policy:
preallocated"
7. oVirt creates a logical volume in the VG
So if you want to use existing LV content, you need to create the disk
in oVirt, and then
you can copy the logical volume from the original LV to the new disk:
You need to find the logical volume created for the VM disk, can be done using:
lvs -o lv_name,tags storage-domain-id | grep disk-id
Then you need to active both lvs, and copy the image:
lvchange -ay old-vg/old-lv
lvchange -ay storage-domain-id/lv-name
qemu-img convert -p -f raw -O raw -t none -T none -n -W
/dev/old-vg/olv-lv dev/storage-domain-id/lv-name
lvchange -an old-vg/old-lv
lvchange -an storage-domain-id/lv-name
The disk space is already allocated to VolumeGroups so I'd have
to fiddle to be able to get an extra VG for that storage domain unless I add a disk.
Note that the iSCSI storage domain must be accessible to all hosts in
the data center.
If not you will not be able to activate all the hosts.
Keeping the storage on one of the hypervisors is possible but not recommended.
I prefer to keep it simple. Perhaps I should create an NFS share and
mount that in the guest but then again I'm not that fond of putting it on an NFS
share.
>
> The difference is that the logical volume is served by iSCSI or FC
> storage server,
> and you can migrate the VM between hosts.
>
> If you really want to use local host storage, the best way is to
> create a local DC
> that will include only this host, and use raw preallocated file on the
> local storage
> domain.
That would kind of defeat the purpose for me. With the setup I had I could directly mount
the LV on the host.
Perhaps I misunderstand what you're saying here.
oVirt does not support attaching LVs or a local file directly to VMs.
You can also continue to use libvirt and qemu to manage this VM. oVirt
will see it as
external VM running on the host, and it should not try to manage it.
The feature you need, attach logical volume to a VM does not exist, so you
need to either use what the system provides, or manage the VM outside
of the system.
Nir
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/VZGX6VBATSB...