| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] qemu and xl semantics
On Wednesday 22 December 2010 17:08:38 Ian Campbell wrote:
> On Wed, 2010-12-22 at 15:42 +0000, Christoph Egger wrote:
> > On Monday 20 December 2010 11:23:59 Ian Campbell wrote:
> > > On Fri, 2010-12-17 at 17:21 +0000, Christoph Egger wrote:
> > > > On Friday 17 December 2010 11:32:41 Ian Campbell wrote:
> > > > > On Fri, 2010-12-17 at 09:49 +0000, Christoph Egger wrote:
> > > > > > On Friday 17 December 2010 10:15:14 Ian Campbell wrote:
> > > > > > > On Fri, 2010-12-17 at 09:00 +0000, Christoph Egger wrote:
> > >
> > > The only recent qemu change which I am aware of in this area is the
> > > backport of the blkback functionality from upstream Qemu. However this
> > > should only be enabled in cases where blkback or blktap are not
> > > available and furthermore is tied to libxl/xl so shouldn't have done
> > > anything on xend (although shouldn't != doesn't).
> >
> > Is this supposed to interact with the Dom0 PV disk backend driver ?
>
> The qemu disk backend is intended to be used when there is no dom0 PV
> disk backend driver in the kernel, if there is a driver in the kernel
> then it is intended that the kernel driver should be used.
>
> The background to this is that we have just gotten the basic dom0
> support into the upstream Linux kernel and are about to start on
> upstreaming the backend drivers. However we observed that there may not
> be any need to upstream a block backend since a userspace implementation
> may well suffice. It's not a done decision but the early signs are good,
> especially compared with blktap which hits userspace anyway.
>
> Even if we do eventually decide to upstream the Linux blkback using the
> disk backend in qemu tides us over for the time being.
NetBSD has a kernel backend driver since Xen 1.x days ... upstream.
The last major change happened to it when it got updated to fit for Xen 2
and still fits well for Xen 3/4, too.
> > > > xbdback backend/vbd/1/832: can't VOP_OPEN device 0xe13: 16
> > > > 16 means EBUSY.
> > >
> > > But it works other than this message?
> >
> > Well, that means that there are now two processes which want to open the
> > vbd simultaneously. The first one wins. And on guest shutdown the
> > VOP_CLOSE fails.
>
> Right. This suggests that the qemu disk backend is being erroneously
> activated on NetBSD when what you actually want is to use the xbdback
> process. I think you likely need to patch libxl to do the right thing
> for NetBSD, currently the decision is based on the presence or absence
> of blktap, I guess it needs extending to detect NetBSD's backend too.
xbdback is actually the kernel backend driver. The conflicting processes
are qemu-dm and the script that assigns the disk through the loopback device.
It seems to work in either way depending on which process wins...
> Alternatively perhaps NetBSD also wants to transition to using the qemu
> based block backend, I suppose there is benefit to be had from sharing
> this code between Linux and NetBSD dom0.
Yes, I think so as long as it doesn't start requiring a kernel driver
other than xbdback.
> > I did some more debugging and figured out xenbackendd runs the vif-bridge
> > script so network with a PV driver works.
>
> > The scripts not running is the one associated with 'vbd' and qemu-ifup.
> > AFAIK qemu-dm always run qemu-ifup which is no longer the case.
> >
> > qemu-ifup adds tap interface to the bridge.
>
> This changed (on Linux) quite a while ago so I didn't think of it.
> qemu-ifup is not used there any more and instead the vif-bridge script
> is called for both PV and TAP devices. See xen-unstable.hg
> 21944:0232bc7c9544, I guess either some equivalent change is needed to
> tools/hotplug/NetBSD or the libxl bit needs to be conditional on NetBSD.
>
hmm... so when I start the guest with 'xm' then qemu runs qemu-ifup.
when I start the guest with 'xl' then qemu does not.
So when I adjust the script then I fix one and break the other.
So to have it working on both the best way is to have the libxl bit
conditional on NetBSD.
BTW: Using the hardcoded path of the libxl bit prior to c/s 21944
doesn't work for me since I install into /usr/local
----------------------------------------------------------------------------------------------
> > local = ""
> > domain = ""
> > 0 = ""
> > backend = ""
> > qdisk = ""
>
> You probably don't want this on NetBSD as described above.
>
> However AFAIK only libxl will cause these to be created, so if you are
> using xend then I am confused.
Sorry, I confused myself. This snippet counts for using xl w/o xend.
-----------------------------------------------------------------------------------------
Again: The 'xenstore-ls' output with 'xm/xend':
tool = ""
xenstored = ""
local = ""
pool = ""
0 = ""
other_config = ""
description = "Pool-0"
uuid = "ea0f9675-726e-e493-8b79-2149f486cb00"
name = "Pool-0"
domain = ""
0 = ""
vm = "/vm/00000000-0000-0000-0000-000000000000"
device = ""
control = ""
platform-feature-multiprocessor-suspend = "1"
error = ""
memory = ""
target = "524288"
guest = ""
hvmpv = ""
data = ""
description = ""
console = ""
limit = "1048576"
type = "xenconsoled"
domid = "0"
cpu = ""
0 = ""
availability = "online"
name = "Domain-0"
device-model = ""
1 = ""
disable_pf = "0"
state = "running"
backend = ""
vfb = ""
1 = ""
0 = ""
vncunused = "1"
domain = "HVM64-NetBSD"
vnc = "1"
uuid = "154d563d-7482-11ff-e49c-fd15dc25959c"
vnclisten = "0.0.0.0"
frontend = "/local/domain/1/device/vfb/0"
state = "1"
online = "1"
frontend-id = "1"
location = "0.0.0.0:5900"
vbd = ""
1 = ""
768 = ""
domain = "HVM64-NetBSD"
frontend = "/local/domain/1/device/vbd/768"
uuid = "62bfd8c9-ca3e-a427-2890-adbf23bbfc17"
bootable = "1"
dev = "hda"
state = "4"
params = "/hvm-guest/netbsd_64b.img"
mode = "w"
online = "1"
frontend-id = "1"
type = "file"
vnd = "/dev/vnd0d"
physical-device = "3587"
hotplug-status = "connected"
sectors = "2048000"
info = "0"
sector-size = "512"
feature-flush-cache = "1"
832 = ""
domain = "HVM64-NetBSD"
frontend = "/local/domain/1/device/vbd/832"
uuid = "57629777-1611-18c7-66a1-5b7b5e4a3024"
bootable = "0"
dev = "hdb"
state = "4"
params = "/hvm-guest/netbsd_disk2.img"
mode = "w"
online = "1"
frontend-id = "1"
type = "file"
vnd = "/dev/vnd1d"
physical-device = "3603"
hotplug-status = "connected"
sectors = "204800000"
info = "0"
sector-size = "512"
feature-flush-cache = "1"
vif = ""
1 = ""
0 = ""
bridge = "bridge0"
domain = "HVM64-NetBSD"
handle = "0"
uuid = "683d226b-6b3c-1e1a-16c1-cd9c866aec91"
script = "/usr/local.22573.netbsd/etc/xen/scripts/vif-bridge"
state = "2"
frontend = "/local/domain/1/device/vif/0"
mac = "00:16:3e:11:14:8c"
online = "1"
frontend-id = "1"
model = "ne2k_pci"
type = "ioemu"
feature-rx-copy = "1"
feature-rx-flip = "1"
hotplug-status = "connected"
console = ""
1 = ""
0 = ""
domain = "HVM64-NetBSD"
protocol = "vt100"
uuid = "e5c50c5f-de58-36ca-afbe-ec6a6751ef4a"
frontend = "/local/domain/1/device/console/0"
state = "1"
location = "6"
online = "1"
frontend-id = "1"
1 = ""
vm = "/vm/2085991b-e8f7-8cbf-4fe0-72ce3de73abe"
device = ""
vfb = ""
0 = ""
state = "1"
backend-id = "0"
backend = "/local/domain/0/backend/vfb/1/0"
vbd = ""
768 = ""
backend-id = "0"
virtual-device = "768"
device-type = "disk"
state = "1"
backend = "/local/domain/0/backend/vbd/1/768"
832 = ""
backend-id = "0"
virtual-device = "832"
device-type = "disk"
state = "1"
backend = "/local/domain/0/backend/vbd/1/832"
vif = ""
0 = ""
state = "1"
backend-id = "0"
backend = "/local/domain/0/backend/vif/1/0"
console = ""
0 = ""
state = "1"
backend-id = "0"
backend = "/local/domain/0/backend/console/1/0"
control = ""
platform-feature-multiprocessor-suspend = "1"
error = ""
memory = ""
target = "3145728"
guest = ""
hvmpv = ""
data = ""
device-misc = ""
vif = ""
nextDeviceID = "1"
console = ""
nextDeviceID = "1"
image = ""
device-model-fifo = "/var/run/xend/dm-1-1293031772.fifo"
device-model-pid = "784"
suspend-cancel = "1"
console = ""
vnc-port = "5900"
port = "6"
limit = "1048576"
type = "ioemu"
serial = ""
0 = ""
tty = "/dev/pts/1"
description = ""
cpu = ""
2 = ""
availability = "online"
0 = ""
availability = "online"
3 = ""
availability = "online"
1 = ""
availability = "online"
domid = "1"
store = ""
ring-ref = "1044476"
port = "5"
name = "HVM64-NetBSD"
vm = ""
00000000-0000-0000-0000-000000000000 = ""
on_xend_stop = "ignore"
pool_name = "Pool-0"
shadow_memory = "0"
uuid = "00000000-0000-0000-0000-000000000000"
on_reboot = "restart"
image = "(linux (kernel '') (superpages 0) (tsc_mode 0) (nomigrate 0))"
ostype = "linux"
kernel = ""
cmdline = ""
ramdisk = ""
on_poweroff = "destroy"
bootloader_args = ""
on_xend_start = "ignore"
on_crash = "restart"
xend = ""
restart_count = "0"
vcpus = "1"
vcpu_avail = "1"
bootloader = ""
name = "Domain-0"
2085991b-e8f7-8cbf-4fe0-72ce3de73abe = ""
image = "(hvm (kernel '') (superpages 0) (tsc_mode 0) (videoram 4) (hpet 0)
(bo\..."
ostype = "hvm"
kernel = ""
cmdline = ""
ramdisk = ""
dmargs = "-domain-name HVM64-NetBSD -videoram 4 -vnc
0.0.0.0:0 -vncunused -vcp\..."
device-model = "/usr/local.22573.netbsd/libexec/qemu-dm"
display = ""
rtc = ""
timeoffset = "0"
device = ""
vfb = ""
0 = ""
frontend = "/local/domain/1/device/vfb/0"
frontend-id = "1"
backend-id = "0"
backend = "/local/domain/0/backend/vfb/1/0"
vbd = ""
768 = ""
frontend = "/local/domain/1/device/vbd/768"
frontend-id = "1"
backend-id = "0"
backend = "/local/domain/0/backend/vbd/1/768"
832 = ""
frontend = "/local/domain/1/device/vbd/832"
frontend-id = "1"
backend-id = "0"
backend = "/local/domain/0/backend/vbd/1/832"
vif = ""
0 = ""
frontend = "/local/domain/1/device/vif/0"
frontend-id = "1"
backend-id = "0"
backend = "/local/domain/0/backend/vif/1/0"
console = ""
0 = ""
frontend = "/local/domain/1/device/console/0"
frontend-id = "1"
backend-id = "0"
backend = "/local/domain/0/backend/console/1/0"
on_xend_stop = "ignore"
pool_name = "Pool-0"
shadow_memory = "28"
uuid = "2085991b-e8f7-8cbf-4fe0-72ce3de73abe"
on_reboot = "restart"
start_time = "1293031772.55"
on_poweroff = "destroy"
bootloader_args = ""
on_xend_start = "ignore"
on_crash = "destroy"
xend = ""
restart_count = "0"
vcpus = "4"
vcpu_avail = "15"
bootloader = ""
name = "HVM64-NetBSD"
Christoph
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home