XS 7 or HyperV 2016
-
@Dashrender said in XS 7 or HyperV 2016:
@scottalanmiller said in XS 7 or HyperV 2016:
@JaredBusch said in XS 7 or HyperV 2016:
Remember that "in production" means up and running in a tiny SMB that I am rarely at in person. XO is making things better, but then that turns into more expense with XOA or my time from source.
My thing about XO for MSPs, is that in a case where you can manage multiple clients, you can use XO as a central management console. Maybe you have a tool for that for Hyper-V or maybe you can't use that use case, but that's something I like a lot about XS and XO from an MSP perspective.
Wouldn't that mean exposing your XS to the internet? I suppose not if you lock the inbound ports to the IP of the XO, where ever it's hosted. So from a management point of view, that's great, but I don't think most would end up using the backup portion in that situation, soooo...
No different than Meraki or Unifi. What's wrong with that?
-
@FATeknollogee said in XS 7 or HyperV 2016:
@Dashrender said in XS 7 or HyperV 2016:
Wouldn't that mean exposing your XS to the internet? I suppose not if you lock the inbound ports to the IP of the XO, where ever it's hosted. So from a management point of view, that's great, but I don't think most would end up using the backup portion in that situation, soooo...
How is this different from using (as an example) the built-in replication tool in Hyper-V? Either way you still need the 'net?
I've never tested this, so I am working from an assumption. But upon the assumption here is my explanation.
You have a XS host in your office in Dallas, 100 Mb internet connection.
The MSP has a XO VM running in a hosted DC in Cali that's used to manage the XS host. How does the data flow to the backup target? Does it flow through the XO system then to the target? I know that Veeam works this way. Assuming it does flow through the XO box, the data would flow out the 100 Mb connection to the XO, and then to where ever the backup target is. Assuming that's at the customer site, that would also be on that single 100 Mb connection.
Again - I admit to an assumption here - if my assumption is wrong, please don't be an ass about it, just inform me, and the rest here.
So with that assumption, assuming you want your first backup target to be onsite, then you'd either need a separate backup solution, or another copy of XS locally that runs backups inside the network.
-
@FATeknollogee said in XS 7 or HyperV 2016:
@Dashrender said in XS 7 or HyperV 2016:
And he responded to that saying that it would bankrupt his company. They would spend so much time supporting those SMBs on that low price that they would lose money.
He told you that or you just making stuff up?
He wrote it in a thread on ML. It was less than 2 months ago.
-
@scottalanmiller said in XS 7 or HyperV 2016:
@Dashrender said in XS 7 or HyperV 2016:
@scottalanmiller said in XS 7 or HyperV 2016:
@JaredBusch said in XS 7 or HyperV 2016:
Remember that "in production" means up and running in a tiny SMB that I am rarely at in person. XO is making things better, but then that turns into more expense with XOA or my time from source.
My thing about XO for MSPs, is that in a case where you can manage multiple clients, you can use XO as a central management console. Maybe you have a tool for that for Hyper-V or maybe you can't use that use case, but that's something I like a lot about XS and XO from an MSP perspective.
Wouldn't that mean exposing your XS to the internet? I suppose not if you lock the inbound ports to the IP of the XO, where ever it's hosted. So from a management point of view, that's great, but I don't think most would end up using the backup portion in that situation, soooo...
No different than Meraki or Unifi. What's wrong with that?
management wise, nothing at all - backup wise, see my previous post.
-
@Dashrender said in XS 7 or HyperV 2016:
@FATeknollogee said in XS 7 or HyperV 2016:
@Dashrender said in XS 7 or HyperV 2016:
Wouldn't that mean exposing your XS to the internet? I suppose not if you lock the inbound ports to the IP of the XO, where ever it's hosted. So from a management point of view, that's great, but I don't think most would end up using the backup portion in that situation, soooo...
How is this different from using (as an example) the built-in replication tool in Hyper-V? Either way you still need the 'net?
I've never tested this, so I am working from an assumption. But upon the assumption here is my explanation.
You have a XS host in your office in Dallas, 100 Mb internet connection.
The MSP has a XO VM running in a hosted DC in Cali that's used to manage the XS host. How does the data flow to the backup target? Does it flow through the XO system then to the target? I know that Veeam works this way. Assuming it does flow through the XO box, the data would flow out the 100 Mb connection to the XO, and then to where ever the backup target is. Assuming that's at the customer site, that would also be on that single 100 Mb connection.
Again - I admit to an assumption here - if my assumption is wrong, please don't be an ass about it, just inform me, and the rest here.
So with that assumption, assuming you want your first backup target to be onsite, then you'd either need a separate backup solution, or another copy of XS locally that runs backups inside the network.
YOu are assuming XO as a backup product, not a management one. Backup is a new feature, and not why we normally discuss it.
-
@Dashrender said in XS 7 or HyperV 2016:
@FATeknollogee said in XS 7 or HyperV 2016:
@Dashrender said in XS 7 or HyperV 2016:
And he responded to that saying that it would bankrupt his company. They would spend so much time supporting those SMBs on that low price that they would lose money.
He told you that or you just making stuff up?
He wrote it in a thread on ML. It was less than 2 months ago.
He definitely said it
-
@Dashrender said in XS 7 or HyperV 2016:
@FATeknollogee said in XS 7 or HyperV 2016:
@Dashrender said in XS 7 or HyperV 2016:
Wouldn't that mean exposing your XS to the internet? I suppose not if you lock the inbound ports to the IP of the XO, where ever it's hosted. So from a management point of view, that's great, but I don't think most would end up using the backup portion in that situation, soooo...
How is this different from using (as an example) the built-in replication tool in Hyper-V? Either way you still need the 'net?
I've never tested this, so I am working from an assumption. But upon the assumption here is my explanation.
You have a XS host in your office in Dallas, 100 Mb internet connection.
The MSP has a XO VM running in a hosted DC in Cali that's used to manage the XS host. How does the data flow to the backup target? Does it flow through the XO system then to the target? I know that Veeam works this way. Assuming it does flow through the XO box, the data would flow out the 100 Mb connection to the XO, and then to where ever the backup target is. Assuming that's at the customer site, that would also be on that single 100 Mb connection.
Again - I admit to an assumption here - if my assumption is wrong, please don't be an ass about it, just inform me, and the rest here.
So with that assumption, assuming you want your first backup target to be onsite, then you'd either need a separate backup solution, or another copy of XS locally that runs backups inside the network.
If the goal is to use XO as a backup tool, then I would assume you'd have bandwidth problems in most cases. If you just want to use it to manage a large pool of resources, a la Meraki, it should be exactly like it.
-
@scottalanmiller said in XS 7 or HyperV 2016:
If the goal is to use XO as a backup tool, then I would assume you'd have bandwidth problems in most cases. If you just want to use it to manage a large pool of resources, a la Meraki, it should be exactly like it.
Sure - but you want a GUI to manage that stuff? why not use a jumpbox and CLI?
-
@Dashrender said in XS 7 or HyperV 2016:
@scottalanmiller said in XS 7 or HyperV 2016:
If the goal is to use XO as a backup tool, then I would assume you'd have bandwidth problems in most cases. If you just want to use it to manage a large pool of resources, a la Meraki, it should be exactly like it.
Sure - but you want a GUI to manage that stuff? why not use a jumpbox and CLI?
Because the systems tend to be stateful and it is stateful, not stateless management. This is platform application management, not systems administration.
-
@Dashrender said in XS 7 or HyperV 2016:
@FATeknollogee said in XS 7 or HyperV 2016:
@Dashrender said in XS 7 or HyperV 2016:
Wouldn't that mean exposing your XS to the internet? I suppose not if you lock the inbound ports to the IP of the XO, where ever it's hosted. So from a management point of view, that's great, but I don't think most would end up using the backup portion in that situation, soooo...
How is this different from using (as an example) the built-in replication tool in Hyper-V? Either way you still need the 'net?
I've never tested this, so I am working from an assumption. But upon the assumption here is my explanation.
You have a XS host in your office in Dallas, 100 Mb internet connection.
The MSP has a XO VM running in a hosted DC in Cali that's used to manage the XS host. How does the data flow to the backup target? Does it flow through the XO system then to the target? I know that Veeam works this way. Assuming it does flow through the XO box, the data would flow out the 100 Mb connection to the XO, and then to where ever the backup target is. Assuming that's at the customer site, that would also be on that single 100 Mb connection.
Again - I admit to an assumption here - if my assumption is wrong, please don't be an ass about it, just inform me, and the rest here.
So with that assumption, assuming you want your first backup target to be onsite, then you'd either need a separate backup solution, or another copy of XS locally that runs backups inside the network.
Actually, no, Veeam does not work that way.
By default, the paid version of Veeam installs proxy stuff on each host as well as the box that Veeam is installed on. When a backup job runs, it chooses the best place to run through each time unless you specify a specific option in the backup job.
