Although this is an old question, I have just figured this one out myself.
First.. what DOES NOT WORK (All tested on XenServer 6.5):
xe-import filename=/dev/stdin
does not work.. at all. It does not matter whether you do:
# simple local import on xenhost
xe vm-import filename=/dev/stdin < myexport.xva
# try it the other way, with cat, still won't work:
cat myexport.xva | xe vm-import filename=/dev/stdin
# and no, dd instead of cat in the above does not make it better
# nor can you pull the file from elsewhere via ssh:
ssh user@backupserver "cat myexport.xva" | xe vm-import filename=/dev/stdin
# nor the other way, pushing from elsewhere to your xenserver
ssh root@xenhost "xe vm-import filename=/dev/stdin" < myexport.xva
# named pipes don't work either, even locally:
mkfifo mypipe
cat myexport.xva > ./mypipe &
xe vm-import filename=./mypipe
So, what I have found is that there is no way to import from a stream, it has to be a real filesystem of some sort. Apparently this used to work, but it doesn't now. My guess is that xenserver wants to seek.
(If anyone can spot a flaw in my attempts and prove me wrong, I'd be very grateful).
So, yes, my conclusion is that you must use a remote filesystem, and we know that NFS works for this, because we've used it.. but decided on sshfs for simplicity. Here is how I installed sshfs on XenServer 6.5:
# fuse-fs and fuse-libs are in existing repos, so..
yum --enablerepo=base --disablerepo=citrix install fuse-fs
# for some reason yum wanted to install i386 fuse-libs which fails
# because of a dependency on i386 glibc.. nevermind all that, tell it
# directly that we want x86_64 and it will work:
yum --enablerepo=base --disablerepo=citrix install fuse-libs.x86_64
# fuse-sshfs is in the epel repo, which we need to add
yum --disablerepo=citrix --enablerepo=extras install epel-release
# now install fuse-sshfs
yum --disablerepo=citrix --enablerepo=extras install fuse-sshfs
# The above leaves epel-release enabled, which should be no problem but
# nevertheless I disabled it since I don't need it anymore:
# Use vim to edit /etc/yum.repos.d/epel.repo
# Where it says `enabled=1` change to `enabled=0`
vim /etc/yum.repos.d/epel.repo
Ok now to restore from an export on another machine:
# make mount point
mkdir backups
# mount location of your backups onto mount point
sshfs user@backupserver.mydomain.com:/path/to/backups backups
# import as usual
xe vm-import filename=backups/myexport.xva
# unmount the remote filesystem, if you don't need it anymore
umount backups
# IT WORKS
Oh, and I should add.. I tried installing the xenxerver tools on our backup server.. it does not work either. Sure, you can execute commands and it all looks great. But filename=/dev/stdin
still does not work, NOR DOES filename=/path/to/myexport.xva
. It just hangs or starts importing then fails in weird ways.
So that's importing.. but what about exporting? Using the xenserver tools remotely installed:
xe vm-export uuid=the-vm-uuid filename= -s xenhost.my.domain -u root -pwf password_file
This DOES export to stdout. But it's a bit unclear as to whether those exports will always import successfully. I experienced a couple of failures and some successes. SO decided against using remote tools at all.. but do it via ssh instead:
ssh root@xenhost.my.domain "vm-export uuid=the-vm-uuid filename=" > myexport.xva
IT WORKS!
The upshot of this is that, with our backup system (Bareos) it is possible to do a backup via ssh directly into the backup software, without having to do an export to a temporary file first. But to do the restore, it is necessary to restore the xva to a temporary storage first, then mount on the xenhost with sshfs, then vm-import. I am sad that we can't stream both ways.. hopefully this will be fixed in xe some time.
Hope this helps some people.. it took a good amount of trial and error to test all the possibilities :)