That's why you need to differentiate clearly a host and its guests. Guest OS (the content of the VM), will behave "like a physical" machine in your previous physical world.
Exporting a VM and importing it elsewhere, is "like" (roughly) put the hard drive from one physical server to another one. Your system will detect new interfaces with new MAC addresses.
The goal of virtualization is to provide a kind of "abstraction" layer: you won't have to install new drivers by importing a VM from a host to another (or migrating a VM in live).
But exporting something, then importing it is not "replacing", it's creating a new VM. It's not a restore operation, it adds new stuff.
You can import manually and tells to preserve stuff, but that's a bad idea. E.g, if you preserve the UUID of the exported VM without removing the previous one, it will be fun. And if by default the MAC will be restored, you'll also have a lot of fun if you forget to de activate it.
@BRRABill just to let you know I ran some tests on continuous delta backup with Dundee, got an export speed around 106 MB/s on my gigabit network. The bottleneck was probably my remote store disk.
I don't have the numbers for 6.5 nor made a proper benchmark on the exact same hardware, but I'll do it later.
Upgraded almost all my systems today 
We released a new version of xo-server earlier (~12h ago) to enhance Dundee support.
Also tested XO VM continuous replication every minute on Dundee Beta 3 last week, worked like a charm during all the tests (5 days). XenServer 6.5 failed after 15 min 
@xogurunoob I like constructive feedback: what do you mean by that?
Are you sure you need to go to some tabs each time you see a VM? I mean the "General" thing should be enough in 80% of the time.
Also, it was more a technical from scratch thing for now (as you can see in the recent perf tests here). We also built a lot of internal components, which will help to really modify the interface quickly after.
@BRRABill We just finished the new VM import stuff, which get:
We'll also include a progress bar for each file I think (sooner or later)
Added some stuff this week, should feel a bit more complete on feature side.
Next week will be about:
So enough to release a beta, let's say, Friday (17th).
VM creation is not yet ready, we made a massive change (less stuff in the web side and more in the server).
You could play with it on v5.x, knowing those limitations.
Planned for next week:
This will lead us to a large scale beta release (also in XOA), and probably shortly after to a "final" release itself. QA work will be important, especially on ACLs side, which is critical before an official release.
Then, we could work on the UI directly, for the 5.1 ie:
This would be a long process because the difference with a "rough" UI and a polished (details, transitions, animations) could cost a lot of work.
@aaronstuder That's a Safari issue. We opened an issue on GH.
Really, Safari is the new IE... https://nolanlawson.com/2015/06/30/safari-is-the-new-ie
That's a cross pool migration There is no such thing as a "standalone" server (despite XenCenter can say, the pool object is always here, from 1 to many hosts)
SMB "mount" is not done via the system but with a Javascript library (lib-smb2), contrary to NFS which is mounted via a "mount" command.
So for SMB it's not really mounted, we are streaming files via SMB protocol.
@BRRABill Everything should be reported there: https://github.com/vatesfr/xo-web/issues
Feel free to report!
@wirestyle22 said in What You Need to Know About XenServer:
@coliver said in What You Need to Know About XenServer:
@wirestyle22 said in What You Need to Know About XenServer:
@dafyre said in What You Need to Know About XenServer:
@wirestyle22 said in What You Need to Know About XenServer:
Extremely easy install. Everything up and running. Reading/Testing more tonight. How are you guys determining the need for virtual/physical cores per server etc?
I think the general consensus is to start with one core and add more if performance sucks.
Virtual?
Always! You should have a reason to be physical otherwise virtual.
Just for my own knowledge, what would be a good reason to go physical? Just for a point of reference.
Maybe NAS/SAN storage, where massive I/Os and scalability is needed (note that you can connect a massive SAN/NAS to a pool so...).
Also, even real-time operations could be done with an Hypervisor now (Xen is going at full speed in automotive industry, via XenRT and Xen ARM projects).
I'm currently writing a complete guide/blog post on Xen tools.
@BRRABill A lot of XS noobs seems lost with that, and the official doc is not very great.
VM metadata means: VM name, description, number of virtual interfaces, disks etc. Everything except the disk content.
So when we are doing VM backup, we are actually export both disk content and VM metadata.
Otherwise, it would be just a bunch of disks with their UUID, which is a bit useless when you need to restore (unless you can memorize every VM configuration and disk placement with their respective UUID. In this case, please answer the question on the meaning on life and everything).
That's related. But as we are using VM export for backup, that will have a huge impact (I hope)
@DustinB3403 said in A Mandate to Be Cheap:
@olivier Hey that's why we have a beta system.
So you have to maintain a beta system, find out when it breaks, migrate the data (if it happens) and check how to do that, and then update the production.
That's OK, but it starts to cost time...
Please put a screenshot here with how you filled those fields.