Hi Andrea,
Well, the machine starts ok but when the "child" FreeBSD starts
installation something strange happens. When I get to the partitioning
screen I can see the device avaiable as /dev/vtdb0 with the correct size
and such. I choose autopartitioning, the installer writes the partition
table but when it start to write /dev/vtdb0p2 a very cryptic error appears
about being unable to write - sorry, did not write it down.
The installer then stops.
If I do a fdisk /dev/vtdb0 in the VM I can see the GPT partition being
there. If I do a fdisk /dev/da2 on the host machine, I can see the GPT
partition as well, but the VM just doesn't want to write on it.
I even tried changing kern.geom.debugflags=16 as I thought the host machine
could be locking somehow the drive, but that didn't seem to make any
difference. I know it was a lame check but I was out of ideas.
So I just wanted to understand if such a scenario is supposed to be
supported....
It is. Been a while since I've done this but will try a repro. Other
folk have supported success using zvols so I'd assumed it was working.
What I was thinking of, for example, was of having an external iSCSI device
connected on the hostmachine mapped as a virtual disk for a specific VM, in
order to speed the VM disk performances.
Yes, that's one of the scenarios in mind.
Just another quick question... I have seen some improvements by having the
VM's virtual disk on ZFS against UFS. Is it just me or is there any real
improvement by using ZFS?
Difficult question to answer - probably workload-dependent.
later,
Peter.
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
