@stuartjordan said in Convert Between Popular VM Formats for Free with StarWind:

Looks good though if it does all. I assume it's a windows based product though?

IIRC, yes you have to install it on a Windows system and then connect to the hypervisor in question to create / export the VM you're wanting to convert.

It's been a while since I've last had to convert anything.

@black3dynamite said in Converting VMware VMs to KVM:

I haven't been keeping up with Windows Admin Center for awhile. Was that an option to manage Hyper-V?

It will be, but I'm not sure that it is yet. We've tried and not been able to get it working even internally anywhere, let alone externally. Once they figure out stability and authentication, I assume that it will be great for that. Being that this is 2016, it's going to suck hard. And if there is a Hyper-V issue, WAC would be down which is a problem in a small environment like this.

Hey @JaredBusch if you Google about converting Hyper-V to KVM, this is Google's built in process now! They link this article as the "official" Google chosen reference document for this process!

@BRRABill said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@scottalanmiller said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@Dashrender said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@scottalanmiller said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@Dashrender said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@scottalanmiller said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@Dashrender said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@scottalanmiller said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@Dashrender said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@scottalanmiller said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@Dashrender said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@scottalanmiller said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@Dashrender said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@scottalanmiller said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@JaredBusch said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

@scottalanmiller said in StarWind V2V Converter: Now with Physical to Virtual (P2V) conversion option!:

Think of the alternative... how much hardware and man hours are going into working around extracting the data?

No where near as much as reverse engineering the database to create the output needed.

This is something I have done more than one time. It is not that easy.

Depends on the database. But it's something we do from time to time and often is pretty basic. I mean days of work, yes. But maintaining all that stuff is also days of work, plus the cost of hardware, isolation, risk, etc. On top of maintaining all that old stuff, we assume that there is no support should something break, either.

The system is basically in a static state. So if it breaks - restore to a known good working state and move on.

The problem I see running into over time is hardware and hypervisor tech that can support this until the kill date of 2036.

we can manually use the built system to do what is called a CCD export of the children's files - while this will be extremely manual in nature, it will likely be less expensive than hiring NTG or whomever to learn the DB layouts and extract the desired data.

Maybe, personally I think this seems very unlikely given 2036. That's 18 more years of dealing with stuff already in a ridiculous state today. Remember that you are going to be dealing with people that are not you and have no memory or knowledge of this system decades from now, a system already insanely old, trying to do restores or run systems 30 years old.

I doubt that that stuff will be cheap at that point, or anytime between now and then. A one time conversion to text files or PDF is over and done. Yeah, it's a bigger up front cost, but it is a single cost that never comes back to haunt you.

Oh believe me - I completely agree with you. Personally, we need to run a report to find all patients who were under 13 years old, export those. Then we can kill this system off in 2023 for all patients, and we'll have the children who have a longer hold requirement already exported.

Once you can export one, export all of them. The cost of one is the same as the cost of all.

With a script, you're right - I'm not looking to hire someone to make said script at this time.

You mean doing it manually? That'll likely take a really long time.

Well - the report will tell us how many patients we have, then management can make the determination if they want to hire someone to script it all - or just do it manually.

Any idea how long manually takes? Is that like just taking a screen shot of the current output?

No, the manual for children will likely be 1-4 mins, likely more on the 1 min side. But that's only a guess, I haven't done the process in years.

Oh, that's really fast. If it is that simple, let's say you have 10,000 customers. That's 10,000 - 40,000 minutes. I bet that it gets faster with someone doing one after another. That's a maximum of 33 weeks of full time work for 10,000 customers to be transferred.

And that is a lot of customers. And that is assuming four minutes per customer. And assuming that you realistically get four productive hours of doing a task like that per day.

wow - you really do build in the 'a person wastes half their work day away' don't you?

LOL, you have to, especially with a tedious task. You can't do that eight hours a day without bleeding from your ears.

Try it sometime. Time a task like that once. Then try to keep it up for an hour. Then realistically think about eight times that in a day. Then think about how hard it would be to do in an isolation chamber versus the real world with interruptions and other tasks that happen. Four hours in an eight hour day is actually quite hard.

I couldn't even read this post without checking my phone and buying something on Amazon.

Exactly!

This is timely.
THanks

qemu-img is actually what HyperCore OS uses internally when it is doing both import and export of VM's to/from HC3. As a result, if you use the "foreign VM import" process referenced above, it leverages the fact that if you simply rename a vmdk for example to a qcow2 file extension (that HC3 expects) and then import it, qemu-img will actually detect that the disk contained in file is really a VMDK and do that conversion automatically for you saving a step!

One other benefit of letting HC3 do the conversion is that it will convert to the right qcow2 format for that HC3 version automatically. if you are doing the pre-conversion using qemu-img on windows (or linux for that matter), you may want to run the qemu-img info on an empty HC3 exported qcow to see what flags it has and try to match them. depending on the version of HC3 and version of qemu for windows you are using I have seen cases mostly with older versions of HC3 where you need to specify the compat version to match something like this:

qemu-img convert -p -O qcow2 -o preallocation=metadata,compat=0.10 source-image.qcow2 output-image.qcow2

(this was an older version of HC3)

On a very new version of HC3 as of this post it looks like compat: 1.1. I got tired messing with stuff like that and the extra step so now I always start with renaming the virtual disk files to .qcow2 extension and try letting HC3 figure it out first at least which generally works. (VHDX may be the exception ... and of course you have to get into the "right" vmdk format in some cases as there are lots of different vmdk formats)

Another tip / FAQ - if you ever have a .OVA file, generally a virtual appliance, that is just a tar archive that you can expand and inside there will be a virtual disk file, usually .vmdk but sometimes .img format that you can convert/import into HC3 using the above processes.

Of course ALL of this is just getting HC3 to see the virtual disk. The OS on that virtual disk has to have the right drivers_ active_ to be able to boot on HC3 which either means that it has virtio drivers pre-installed and set to boot (if "performance" drivers are selected when creating the VM) or IDE drivers (if "compatible" drivers are selected ... and for windows mergeide.reg was run before migration.) Linux is generally just automatic but Windows will result in a 7B BSOD if a driver for the boot disk isn't active on the imported virtual disk.

@Kelly yeah the HC3 Move (powered by Double-Take) is certainly easier and more direct...

if the xenserver export virtual disk file is a VHD file, you can probably skip converting it to qcow2 but simply renaming the file to match the guid of the exported empty qcow2 file (so it will still be named <guid>.qcow2 even though it's actually your VHD file.) Our import is actually using the qemu-img convert tool which will automagically detect that it's really a VHD format and do the conversion at the same time it imports it to save that extra step. (and also you can use that same "import shell" over and over... just keep replacing the guid.qcow2 file with the one you want to import)

Darn. I got it over to Hyper-V but it just goes to automatic repair and won't boot to windows. I guess I should have removed VMware Tools first I forgot. Hopefully that's the only issue.