Yes, whatever how you name it, but a physical appliance/machine which will serve a large bunch of files.

I'll improve the doc to be sure there no confusion possible

@DustinB3403 Forget about manual seeding. Just don't read this paragraph and apply the "normal" procedure.

This is only relevant situation is for people having multiple datacenters with very bad interconnection, when copying VM on a disk and then take your car to the other datacenter has a better bandwidth (sneaker net).

To recap:

1. For XenServer SR (aka VM disks): local storage or remote storage, doesn't really matters, because we always have the ability to migrate the VDIs when needed
2. Having large VDIs will reduce this flexibility. So it's better to use small VDIs and use NAS/SAN for mounting large space filled with a lot or big files.

@DustinB3403 Do you need or not, to transfer the VM content manually with a hard drive disk or by any mean that is not a network copy?

If not, don't even read the manual seed procedure.

@DustinB3403 Manual seed is for people who can't afford to do the first replication over the network due to very low bandwidth. Otherwise, don't do it.

@Dashrender said in Someone doesn't like local storage for large amounts of data:

Hmm... this flies in the face of hundreds if not thousands of posts on this forum.

That's my opinion, I don't care if it's shared or not. That's what I can see on the field. I won't create VMs with disks of hundreds of GBs. Or without knowing the pain it will cause if there is any operation to do on this VM (migration, backup, restore, whatever)

@DustinB3403 I don't see the connection here. Can you explain further? You can't afford to do the initial replication over the network, so you need to export the VM on a disk that you can move over the destination?

My point is to split different those problems into 2 different things: compute and storage. They are not the same thing and in general, and it's not a bad idea to split those stuff.

@Dashrender as I said, your poor backup perfs are not the perfs for everyone. Your case is not global, don't forget that

Why I would put the filer in the VM? I would avoid it ^^

@Dashrender Naah. Just a physical NAS/SAN, exposed in SMB/NFS. Let's name it the filer.

This filer is mounted in any VMs you like, that's it. You can even having a VM to rsync those files to another filer for you backup, just simple as that.

A filer will have sense for large collection of files (like a company shared folder).

The alternative would be to have a cluster FS on every XenServer to act as a local SR "shared" on all hosts. That would be doable with SMAPIv3, but for now, it's overcomplicated and not really secure/consistent/powerful.

edit: I don't know if I'm a clear. I don't speak about SR in XenServer terms. That's another thing. I only speaking about a dedicated network share for files. Period

@DustinB3403 said in Xen Orchestra and Continuous Replication:

So @olivier just reading this here.

It says

1.Create a CR Job
2. Manually run the first job
3. When completed export the backup Why do we need to export the backup?
4. Import it to the destination
5. Remove the local copy.

I'm planning on performing identical host to host replication. Is that wrong?

This is the doc about seeding. Do you need to make an initial seed, really?

edit: read the doc carefully, seeding is only a specific case if you need it. I think you read too fast.

@FATeknollogee I'm not especially vulnerable to trends. I prefer solutions that works and in the same time which are not over complicated.

In this case, VMs with larger disks are always more complicated to handle in the end. That's my experience, in the XenServer world.

I don't say to never do this or that, that's just in general, you are less exposed by splitting problems into smaller pieces.

edit: that's also due to the storage architecture in XenServer. Maybe if it was far better/faster, my advice would be probably different. Having a lot of hope for SMAPIv3

@DustinB3403 I mean latency of a NAS/SAN for serving files in a "normal" network isn't an issue in general (except for bad designed networks or undersized). For a DB or webserver, latency matters far more (with some order of magnitude)

@DustinB3403 You have to put this into context. A fast local SSD disk for a database or webserver is not a bad idea. But that won't need hundreds of GBs.

For a "datastore", there isn't any perf problem to serve larger files on a remote location (when latency isn't an issue)

@FATeknollogee SR type doesn't matter in this case. I said to NOT attach large disks to VMs but to prefer, inside the VM, to mount a remote data store from a NAS/SAN/whatever.

This way your VM keeps a system disks (let's say 20 or 50GB) and that's all to backup/restore.

Hundreds of GBs starts to be harder/less flexible to play with in general. Anyway, the limit is 2TB due to VHD format.

I would prefer to use a filer and NFS/SMB to it from VMs. This way you separate your VM issues to your data/file issues.

@DustinB3403 This is kind of similar than delta backup, but the merge is done inside XenServer directly. After the first replication (full), it will only send the delta's.

To take your example, your 700GB backup should take 4 or 5 hours max, and then delta would be almost done instantly.

@Dashrender It's not slow for everyone: I'm maxing a GBit link without any problem and we have some users having larger connections used for backup. Otherwise, we won't have clients.

Also, everyone knows (in XS world at least) that having large VMs -in terms of disk space- is not a good idea*, so it's not a common practice (and that's good).

• : for a lot of reasons, time to backup, snapshot space, Xen storage motion time, restore time and a LOT of things.