Am I able to use our current NFS architecture, which we currently use for our vSphere environment, with PVE? From what I read, in order to get snapshots, data replication and other advanced features, we need ZFS. If this is the case, does this mean we would need to transition over to block?
NFS and Advanced Storage Features
- Thread starter esnmb
- Start date
Hi @esnmb , welcome to the forum.
NFS is shared storage type. When you use NFS you are able to initiate snapshots if you store your VM images (disks) in QCOW format. 99% of people do so.
You are correct that replication is only available with ZFS backend storage. However, given that NFS is shared storage you don't need to replicate for standard HA functionality. The data is already available to all hosts in the cluster in a standard setup.
If you specify what other Advanced features you are looking for, forum members can advise on their availability.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Thanks!
That's great news. I guess I misunderstood the replication portion. My understanding was that it was for a disaster recovery feature to replicate VM's to another site/datacenter.
Looks like we don't have to completely rethink how we do things today with our NetApp.
That's great news. I guess I misunderstood the replication portion. My understanding was that it was for a disaster recovery feature to replicate VM's to another site/datacenter.
Looks like we don't have to completely rethink how we do things today with our NetApp.
The confusion is from using same technology for different purposes. In general, you are correct that Replication is used for DR across sites/buildings/racks.
However, in Proxmox ZFS replication requires the two nodes to be in the same cluster. This introduces a dependency between the sites that complicates DR scenarios. My guess is that it was originally created to address a specific market segment: users who have local storage and are unable to implement Ceph for data protection.
If you have Netapp, you may be able to implement backend replication (snapmirror) and build policies on top of that to facilitate PVE DR.
Good luck
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Last edited:
If you are already using NFS with vSphere, you can also give the NFS shares to a PVE host and attach the .vmdk files directly to new PVE VMs. Then just shut down the old VM on vSphere and start the new one on PVE. There is no faster migration 
If you are already using NFS with vSphere, you can also give the NFS shares to a PVE host and attach the .vmdk files directly to new PVE VMs. Then just shut down the old VM on vSphere and start the new one on PVE. There is no faster migration
There is, actually, not that it would be exclusive, but there is
EDIT (link to thread head as opposed to live migrate post): https://forum.proxmox.com/threads/new-import-wizard-available-for-migrating-vmware-esxi-based-virtual-machines.144023/
Last edited:
Interesting. If we used the VMDK's, we wouldn't have snapshots, though since we need QCOW format?If you are already using NFS with vSphere, you can also give the NFS shares to a PVE host and attach the .vmdk files directly to new PVE VMs. Then just shut down the old VM on vSphere and start the new one on PVE. There is no faster migration
But the Live Import is very slow.There is, actually, not that it would be exclusive, but there is
https://forum.proxmox.com/threads/n...xi-based-virtual-machines.144023/#post-647707
If the VM is on PVE, you can migrate the disks live to other datastores or to other formats.
So afterwards, simply migrate the disks from vmdk to qcow2 and the whole thing has almost no impact and goes completely online.
I was mostly referring to how long it takes an operator to spend time with, eliminating manual efforts. The speed of the copying does not bother one, necessarily, on a migration in this fashion.
Yes, creating a VM hull and mounting the VMDK takes a few minutes, but the live import always generates significantly more downtime than the method with NFS (many hundreds of VMs already migrated this way).
During the live import, the VM starts slowly to extremely slowly and can then only be used in a makeshift manner. In any case, you cannot use a database server during this time. The VMware VDDK simply does not offer more and is actually not designed for migrations but for backups.
Minimal downtime also means 3 minutes more preparatory work.
During the live import, the VM starts slowly to extremely slowly and can then only be used in a makeshift manner. In any case, you cannot use a database server during this time. The VMware VDDK simply does not offer more and is actually not designed for migrations but for backups.
Minimal downtime also means 3 minutes more preparatory work.
Generally, I would discount this because "downtime" can be zero on certain services, you could redirect the traffic when both VMs actually run, then take the old one down.
I believe this with a DB it's better to manually "migrate" indeed.
My bad, I wanted to share the thread as a whole, not the specific post about live-migrate. I got it now.