BRRABill's Field Report With XenServer

BRRABill

@BRRABill said:

@scottalanmiller said:

Am I clear... the issue is that XO only refreshes the data as to drive sizes on a page refresh?

No you have to click the "rescan" button or it never does it. At least that is what I am seeing.

Ah okay, my guess is because they don't want to incur a storage penalty without everyone being clear that they are about to query the storage. In a small lab with local storage this seems silly, but if this was a massive environment with tons of heavily used remote storage, might be something that you want to carefully control. What if you had a hundred admins with XO open all of the time and a thousand nodes on it with gobs of shared storage all updating automatically... suddenly what seems like a trivial hit becomes crippling.

And, again, in a larger environment, seeing storage space in the GUI here is not really the proper way to manage it, correct?

scottalanmiller

@BRRABill said:

And, again, in a larger environment, seeing storage space in the GUI here is not really the proper way to manage it, correct?

Oh I don't know about that, no matter how big the environment is, the virtualization platform administrators are going to need a view into what is going on, at least from their perspective. In a really, REALLY large environment you would be on fully independent shared storage in 99% of cases (think EMC VMAX) with a totally independent storage management team and they would deal with performance, capacity, growth, monitoring, etc. But even then the platform team would need some visibility into what they were using of that storage. So I would expect that XO having that view would remain important, but for slightly curtailed reasons.

Dashrender

How does vSphere manage this without the need to do continuous refreshes?

Aren't both XO and vSphere are both centralized server systems that they themselves could maintain an updated status, and the users who are accessing the web server would be stressing the web centralized system, not the storage itself.

scottalanmiller

@Dashrender said:

Aren't both XO and vSphere are both centralized server systems that they themselves could maintain an updated status, and the users who are accessing the web server would be stressing the web centralized system, not the storage itself.

vSphere varies.

XO might be triggering it via the interface which doesn't make that undoable, just less obvious.

Dashrender

@scottalanmiller said:

@Dashrender said:

Aren't both XO and vSphere are both centralized server systems that they themselves could maintain an updated status, and the users who are accessing the web server would be stressing the web centralized system, not the storage itself.

vSphere varies.

XO might be triggering it via the interface which doesn't make that undoable, just less obvious.

varies how?

scottalanmiller

@Dashrender said:

@scottalanmiller said:

@Dashrender said:

Aren't both XO and vSphere are both centralized server systems that they themselves could maintain an updated status, and the users who are accessing the web server would be stressing the web centralized system, not the storage itself.

vSphere varies.

XO might be triggering it via the interface which doesn't make that undoable, just less obvious.

varies how?

The web client does one thing but the local client has to do another.

Dashrender

@scottalanmiller said:

@Dashrender said:

@scottalanmiller said:

@Dashrender said:

Aren't both XO and vSphere are both centralized server systems that they themselves could maintain an updated status, and the users who are accessing the web server would be stressing the web centralized system, not the storage itself.

vSphere varies.

XO might be triggering it via the interface which doesn't make that undoable, just less obvious.

varies how?

The web client does one thing but the local client has to do another.

OK just so we are all on the same page, the vSphere setup I'm talking about is the centralized one that is accessed via web browser, just like XO.

BRRABill

@olivier said:

But you need to define a default SR on any pool you got. Eg: xe pool-param-set uuid=<pool-uuid> default-SR=<sr-uuid> (with the SR UUID of the local storage if you don't have a shared storage).

You can also do it with XenCenter or XO (see https://xen-orchestra.com/blog/set-the-xenserver-default-sr/ )

I tried through that link. There is no :default disk" option that pops up on any of my SRs. Do I perhaps have to do it manually first?

BRRABill

@BRRABill said:

I tried through that link. There is no :default disk" option that pops up on any of my SRs. Do I perhaps have to do it manually first?

I was able to just right click in XC and it worked.

Now, let's see if this migration will work!

olivier

If it don't, check the xo-server output. This won't lie and tell us what's going on.

BRRABill

@olivier said:

If it don't, check the xo-server output. This won't lie and tell us what's going on.

OK.

One thing I noticed that when I tried it in the XC wizard, it says:
"the vm is incompatible with the cpu features of this host"

But I see from my friend Google that XO should overcome this.

I will try it and let you know.

I have to migrate all these VMs off my new server so hopefully it will work!

olivier

XO will try to force migrate, but from a recent to an older CPU, the result is half of the time a kernel panic (older to recent CPU is less problematic, you'll keep using existing instruction from the old CPU without exploding in flight, contrary to trying a recent CPU instruction which doesn't exist on an older CPU)

BRRABill

@olivier said:

XO will try to force migration, but from a recent to an older CPU, the result is half of the time a kernel panic (older to recent CPU is less problematic, you'll keep using existing instruction from the old CPU without exploding in flight, contrary to trying to use a recent instruction which doesn't exist on an older CPU)

So in this scenario, are you thinking it would be best to shut it down, and do an export/import?

I wish there was a way to copy from one XS to another. Instead of having to export it to my machine and then import it. As you have mentioned in other threads, it's a pain with larger VMs.

olivier

Our "special" VM copy is doing this:

Check the "Copy" button in the VM view, select a destination SR, and you are done.

edit: original blog post: https://xen-orchestra.com/blog/vm-streaming-export-in-xenserver/

BRRABill

@olivier said:

Our "special" VM copy is doing this:

Ooooh, that's what I am looking for!

Can you copy a live VM, or does it have to be shut down? (I ask because the option is there when it is running.) I tried that last night. It looked like it copied but threw up an error.

olivier

If it's up, we are taking a snapshot AND copy it. So it doesn't matter.

BRRABill

@olivier said:

If it's up, we are taking a snapshot AND copy it. So it doesn't matter.

Gotcha. So for stuff with a lot of transaction, not ideal.

But if I shut my VM down first, that would be perfect!

olivier

It's always a trade off. At least, it will be a quiesce snapshot if your Windows VM support it.

But ideally, to avoid any risk, shutdown THEN copy is the safest solution.

Depends of risk level (and downtime!) you can accept (eg live migration is still possible, but you could possibly reboot at destination if CPU instructions are not correct)

BRRABill

@olivier said:

Depends of risk level (and downtime!) you can accept (eg live migration is still possible, but you could possibly reboot at destination if CPU instructions are not correct)

I think I'll just do the shutdown route, but out of curiosity what kind of things would happen with mismatched CPU instructions? In the scope of a migration.

olivier

Roughly, migration without storage is like this in XenServer:

a snapshot is created on the origin host
every new write is now streamed on both hosts (origin and destination)
disks are copied

When this is done, it's a classical live migration:

RAM is transfered
VM is suspended a fraction of time on the origin host
last RAM transactions are copie on the destination host
VM is "resumed" (un-suspended) on destination

So your VM will continue its life without knowledge of the new hardware. Let's imagine you have a recent CPU on the origin host, with the "FOOBAR" instruction. Let's also imagine this "FOOBAR" instruction is not on the destination host CPU.

Your VM booted with this "FOOBAR" capable CPU, so for it, that's OK to call it. Imagine what happened when the call happen on the destination host (kernel is crash \o/).

More fun? Migrate a VM from two CPUs vendors (Intel/AMD), while running a Java program inside the VM. If you love fireworks, worth the shot.