Solved Migrate VM from TrueNAS CORE to vm-bhyve

V

victort

Greetings.

I am trying to migrate a VM that has been on a TrueNAS CORE server for 5~ years, to just using vm-bhyve to manage it.

The VM is a simple Ubuntu VM with UISP running on it, with UEFI, and a zvol as the disk.

I have moved the zvol (sparse-zvol) to my vm-bhyve instance, but cannot get it to run with any template. Steps are below.

1. On the new server vm create uisp then delete the disk image that gets created, as we are moving another zvol into its place
2. zfs send pool/tank/VM/uisp-df567 | ssh@host zfs receive pool/tank/vm/uisp/disk0
3. Create the below template to use
Code: 
guest="linux"
loader="uefi"
cpu=1
memory=4096M
network0_type="virtio-net"
network0_switch="vm_bridge0"
disk0_dev="sparse-zvol"
disk0_type="virtio-blk"
disk0_name="disk0"
uuid="redacted"
network0_mac="redacted, but valid"
uefi_vars="yes"

I cannot get this to work at all, I'm getting the below lines, and it never goes past that screen.

Code: 
  * found guest in /mnt/tank/vm-bhyve/uisp
  * booting...
BdsDxe: loading Boot0005 "Ubuntu" from HD(1,GPT,A60D38CA-F598-4B0C-A1C6-0E0E4DD2A397,0x800,0x219800)/\EFI\ubuntu\shimx64.efi
BdsDxe: starting Boot0005 "Ubuntu" from HD(1,GPT,A60D38CA-F598-4B0C-A1C6-0E0E4DD2A397,0x800,0x219800)/\EFI\ubuntu\shimx64.efi
eerror: no suitable video mode found.
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path

Any ideas?
 
Code: 
eerror: no suitable video mode found.

Enable UEFI graphics. Add graphics="yes" to the config.

github.com

UEFI Graphics (VNC)

Shell based, minimal dependency bhyve manager. Contribute to churchers/vm-bhyve development by creating an account on GitHub.
github.com github.com
 
When I enter the VNC console initially on boot, I can see everything loading fine, and the login prompt comes up. But when I exit VNC and reenter it, I get a blue screen with the VM info instead of the regular console screen.
 
victort said:
I can see everything loading fine, and the login prompt comes up.
Click to expand...
Ok, that means it boots properly. Can you access it over the network? One thing might be /etc/udev/rules.d/70-persistent-net.rules on the Ubuntu VM. That may have recorded the MAC address. If network0_mac has a different MAC it may not pick up the network interface.

victort said:
But when I exit VNC and reenter it, I get a blue screen with the VM info instead of the regular console screen.
Click to expand...
That's odd. I know bhyve(8) can be quite picky with regards to the VNC client though. So far TigerVNC seems to work fine for me. But this is probably not much of a priority right now.
 
The interface isn’t coming up either. MAC isn’t recorded, and is the same in any case as the old VM.

VM seems to work fine, but no network or proper VNC connection. Or console for that matter.
 
victort said:
The interface isn’t coming up either.
Click to expand...
You've set it to virtio-net, was that the same as on TrueNAS? This could be a potential pitfall too.
victort said:
MAC isn’t recorded, and is the same in any case as the old VM.
Click to expand...
Alright, one less thing to worry about.
victort said:
Or console for that matter.
Click to expand...
Did you have serial console access when running it on TrueNAS? You have to jump through a bunch of hoops in order to enable it on Ubuntu. If that's been set up correctly, did you try vm console <vmname>? That should connect you to the serial console of the VM (assuming it's enabled in the VM itself too).
 
Hmmmm. Looks like vNC is working now through guacamole. I was using Real VNC Viewer on IOS when it wasn’t.

Now for the network part.
Yes TrueNAS had it set to Virtio. (The disk)
 
I think I finally did get it. I had to redo my network gateway, DNS, IP etc…

Didn’t all that want to stick?
 
Looks like my network interface was not set to the same name, that’s why it was acting up. All good now. There is no console in UEFI mode by default, so VNC is what I had to use.

Still, would be nice to have console access…
 
Strange behaviour encountered. I am running XigmaNAS on a Dell Poweredge R720, and have tried the built in virtualbox. It works great, but I kind of want to stick with vm-bhyve. But I’m running into a slight hiccup.

What is the ultimate payoff when using sparse zvols and just plain zvols?

I am noticing that if I use a sparse zvol, and trying to play around with bastille, it will start to hang at each zfs command bastille tries to execute. It takes at least 8-10 second for each one, even if it is just creating a simple jail dataset with nothing in it. Could this be an issue with the sparse zvol disk type?

My latest attempt was just setting one up with a full zvol, which in the first few minutes of playing with it seems to work great. Snappy and speedy just as it should be.
 
On my TrueNAS system I never had this issue at all. I was assuming up till now that it was a sparse zvol. But a quick check online here tell me to look for the "refreservation" field and if it is set to "none" then it is a sparse zvol.

I look on my TrueNAS VM and sure enough, it is NOT a sparse zvol (if the above info is accurate)

So I think I'm on the right track here. A sparse zvol does not appear to be what I want in this case.

Found this helpful post also.
SirDice

Solved Post in thread 'Thin or Thick Zvol'

Thin provisioned are sparse files. Meaning only the actual used data is stored, everything that's still empty is skipped. In order to write the system needs to make room for it. Normally this isn't much of an issue but it does require a bit more I/O because stuff needs to be moved around. With I/O intensive applications all these little bits of extra I/O add up costing you performance.

With "thick" provisioning the whole size of the disk is created. Even without any data in it it would be the exact size (filled with zeros). Now when you write to it it can do so immediately (the space is...
  • Thanks
 
As it turns out, the drives I was using in TrueNAS were CMR, and the new drives I was attempting to use were SMR. What a difference!

Back to CMR and everything works great again.
 
You must log in or register to reply here.
Back
Top