Re: [et-mgmt-tools] Virtinst and blktap
Chris Lalancette wrote: Michael DeHaan wrote: I had a user question about how they can specify blktap for Xen in Cobbler instead of the file driver (for performance reasons) ... well, it turns out they can't (yet). Under what conditions can we use blktap, and is that advisable? (I had thought this might work like virtio, in which case, passing in the os version uses a table, but it seems this may only actually depend on the host and has no guest limitations?) That's exactly right. It's a property of how the host OS accesses the disk on behalf of the domain, not of how the disk is presented to the domain. In fact, for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct file: access can corrupt your guest domains on host crash. The situation with FV domains is more complicated, but there, you can use file:, since it properly does flushing. It looks like from the virtinst code I could just call utils.is_blktap_capable() from my libvirt-using application and if so, then pass the driver=DRIVER_TAP options to virstinst. Good idea? Bad idea? The only reasonable default for Xen PV domains, in my opinion. Thanks. FWIW the default behavior of python-virtinst seems to be to /not/ use blktap, and should probably be fixed then if there's a potential corruption problem. I haven't tested command line virt-install to see what it does. ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] Virtinst and blktap
Michael DeHaan wrote: Chris Lalancette wrote: Michael DeHaan wrote: I had a user question about how they can specify blktap for Xen in Cobbler instead of the file driver (for performance reasons) ... well, it turns out they can't (yet). Under what conditions can we use blktap, and is that advisable? (I had thought this might work like virtio, in which case, passing in the os version uses a table, but it seems this may only actually depend on the host and has no guest limitations?) That's exactly right. It's a property of how the host OS accesses the disk on behalf of the domain, not of how the disk is presented to the domain. In fact, for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct file: access can corrupt your guest domains on host crash. The situation with FV domains is more complicated, but there, you can use file:, since it properly does flushing. It looks like from the virtinst code I could just call utils.is_blktap_capable() from my libvirt-using application and if so, then pass the driver=DRIVER_TAP options to virstinst. Good idea? Bad idea? The only reasonable default for Xen PV domains, in my opinion. Thanks. FWIW the default behavior of python-virtinst seems to be to /not/ use blktap, and should probably be fixed then if there's a potential corruption problem. I haven't tested command line virt-install to see what it does. That default is actually set in virt-install and virt-manager, but probably should have been moved into the virtinst library a long time ago. - COle ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] Virtinst and blktap
Cole Robinson wrote: Michael DeHaan wrote: Chris Lalancette wrote: Michael DeHaan wrote: I had a user question about how they can specify blktap for Xen in Cobbler instead of the file driver (for performance reasons) ... well, it turns out they can't (yet). Under what conditions can we use blktap, and is that advisable? (I had thought this might work like virtio, in which case, passing in the os version uses a table, but it seems this may only actually depend on the host and has no guest limitations?) That's exactly right. It's a property of how the host OS accesses the disk on behalf of the domain, not of how the disk is presented to the domain. In fact, for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct file: access can corrupt your guest domains on host crash. The situation with FV domains is more complicated, but there, you can use file:, since it properly does flushing. It looks like from the virtinst code I could just call utils.is_blktap_capable() from my libvirt-using application and if so, then pass the driver=DRIVER_TAP options to virstinst. Good idea? Bad idea? The only reasonable default for Xen PV domains, in my opinion. Thanks. FWIW the default behavior of python-virtinst seems to be to /not/ use blktap, and should probably be fixed then if there's a potential corruption problem. I haven't tested command line virt-install to see what it does. That default is actually set in virt-install and virt-manager, but probably should have been moved into the virtinst library a long time ago. - COle Yeah, I can't keep up very well when stuff doesn't happen there :) Should I make the fix in koan also or do you want to move it? --Michael ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] Virtinst and blktap
Michael DeHaan wrote: Cole Robinson wrote: Michael DeHaan wrote: Chris Lalancette wrote: Michael DeHaan wrote: I had a user question about how they can specify blktap for Xen in Cobbler instead of the file driver (for performance reasons) ... well, it turns out they can't (yet). Under what conditions can we use blktap, and is that advisable? (I had thought this might work like virtio, in which case, passing in the os version uses a table, but it seems this may only actually depend on the host and has no guest limitations?) That's exactly right. It's a property of how the host OS accesses the disk on behalf of the domain, not of how the disk is presented to the domain. In fact, for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct file: access can corrupt your guest domains on host crash. The situation with FV domains is more complicated, but there, you can use file:, since it properly does flushing. It looks like from the virtinst code I could just call utils.is_blktap_capable() from my libvirt-using application and if so, then pass the driver=DRIVER_TAP options to virstinst. Good idea? Bad idea? The only reasonable default for Xen PV domains, in my opinion. Thanks. FWIW the default behavior of python-virtinst seems to be to /not/ use blktap, and should probably be fixed then if there's a potential corruption problem. I haven't tested command line virt-install to see what it does. That default is actually set in virt-install and virt-manager, but probably should have been moved into the virtinst library a long time ago. - COle Yeah, I can't keep up very well when stuff doesn't happen there :) Should I make the fix in koan also or do you want to move it? --Michael I'll take a look at moving it into the library, but for back compat it wouldn't hurt to set the default in koan. The virt-install code is: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/file/5d6dc8af58b5/virt-install#l209 - Cole ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] Virtinst and blktap
Cole Robinson wrote: Michael DeHaan wrote: Cole Robinson wrote: Michael DeHaan wrote: Chris Lalancette wrote: Michael DeHaan wrote: I had a user question about how they can specify blktap for Xen in Cobbler instead of the file driver (for performance reasons) ... well, it turns out they can't (yet). Under what conditions can we use blktap, and is that advisable? (I had thought this might work like virtio, in which case, passing in the os version uses a table, but it seems this may only actually depend on the host and has no guest limitations?) That's exactly right. It's a property of how the host OS accesses the disk on behalf of the domain, not of how the disk is presented to the domain. In fact, for Xen PV domains, you should *only* ever use blktap (i.e. tap:aio:); direct file: access can corrupt your guest domains on host crash. The situation with FV domains is more complicated, but there, you can use file:, since it properly does flushing. It looks like from the virtinst code I could just call utils.is_blktap_capable() from my libvirt-using application and if so, then pass the driver=DRIVER_TAP options to virstinst. Good idea? Bad idea? The only reasonable default for Xen PV domains, in my opinion. Thanks. FWIW the default behavior of python-virtinst seems to be to /not/ use blktap, and should probably be fixed then if there's a potential corruption problem. I haven't tested command line virt-install to see what it does. That default is actually set in virt-install and virt-manager, but probably should have been moved into the virtinst library a long time ago. - COle Yeah, I can't keep up very well when stuff doesn't happen there :) Should I make the fix in koan also or do you want to move it? --Michael I'll take a look at moving it into the library, but for back compat it wouldn't hurt to set the default in koan. The virt-install code is: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/file/5d6dc8af58b5/virt-install#l209 - Cole Excellent, will do. ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] Virtinst and blktap
On Thu, May 28, 2009 at 9:03 AM, Cole Robinson crobi...@redhat.com wrote: Mark Johnson wrote: For Solaris dom0, I have a patch that allows driver and subdriver in virt-install. If interested, I'm happy to submit it..Note, our blktap is different (vdisk). We have an additional format selection too. virt-install -p -n nevada -l /export/snv108.iso --nographics \ --noautoconsole -r 1024 \ --disk path=/export/nevada/disk0,size=10,driver=tap,subdriver=vdisk,format=vdi MRJ Sounds like a reasonable addition to me. I'd be interested in a patch. Driver/subdriver and format should probably be two different patches though. OK. For now, I've attached our current patch for reference.. Not meant for submission. I'm not sure how far behind virt-install we are these days. FYI, It has more than just the tap stuff. We also support iscsi, etc.. e.g. we support the following iscsi paths... phy:iscsi:/alias/iscsi-alias phy:iscsi:/static/server IP/lun/target id phy:iscsi:/discover/lun/alias or target id virt-install -p -n nevada -l /export/snv108.iso --nographics \ --noautoconsole -r 1024 \ --disk path=/alias/tank/iscsi/nevada/disk0,driver=phy,subdriver=iscsi diff --git a/virt-install b/virt-install --- a/virt-install +++ b/virt-install @@ -81,6 +81,9 @@ sparse = True bus = None cache = None +driver = None +subdriver = None +format = None # Strip media type if path.startswith(path=): @@ -133,6 +136,12 @@ fail(_(Unknown '%s' value '%s') % (opt_type, opt_val)) elif opt_type == cache: cache = opt_val +elif opt_type == driver: +driver = opt_val +elif opt_type == subdriver: +subdriver = opt_val +elif opt_type == format: +format = opt_val else: fail(_(Unknown --disk option '%s'.) % (opt,)) @@ -169,7 +178,7 @@ if not devtype: devtype = virtinst.VirtualDisk.DEVICE_DISK ret = (abspath, voltuple, volinst, devtype, bus, ro, shared, size, sparse, - cache) + cache, driver, subdriver, format) logging.debug(parse_disk: returning %s % str(ret)) return ret @@ -179,13 +188,14 @@ # Get disk parameters if is_file_path: (path, voltuple, volinst, device, bus, readOnly, shared, size, - sparse, cache) = \ + sparse, cache, driver, subdriver, format) = \ (disk, None, None, virtinst.VirtualDisk.DEVICE_DISK, None, False, - False, size, sparse, None) + False, size, sparse, None, None, None, None) else: (path, voltuple, volinst, device, bus, readOnly, shared, - size, sparse, cache) = parse_disk_option(guest, disk, size) + size, sparse, cache, driver, subdriver, format) = \ +parse_disk_option(guest, disk, size) if not sparse and volinst: volinst.allocation = volinst.capacity @@ -193,7 +203,8 @@ volInstall=volinst, volName=voltuple, readOnly=readOnly, shareable=shared, device=device, bus=bus, conn=guest.conn, - driverCache=cache) + driverCache=cache, driverName=driver, + driverType=subdriver, format=format) # Default file backed PV guests to tap driver if d.type == virtinst.VirtualDisk.TYPE_FILE \ and not(hvm) and virtinst.util.is_blktap_capable(): diff --git a/virtinst/CloneManager.py b/virtinst/CloneManager.py --- a/virtinst/CloneManager.py +++ b/virtinst/CloneManager.py @@ -531,10 +531,10 @@ clone_type = IS_UNKNOWN -if (_util.is_vdisk(src_path) or -(os.path.exists(dst_path) and _util.is_vdisk(dst_path))): +if (_util.is_vdisk(src_path, None) or +(os.path.exists(dst_path) and _util.is_vdisk(dst_path, None))): -if (not _util.is_vdisk(src_path) or +if (not _util.is_vdisk(src_path, None) or os.path.exists(dst_path)): raise RuntimeError, _(copying to an existing vdisk is not supported) diff --git a/virtinst/Installer.py b/virtinst/Installer.py --- a/virtinst/Installer.py +++ b/virtinst/Installer.py @@ -293,7 +293,7 @@ or guest.disks[0].device != VirtualDisk.DEVICE_DISK: return True -if _util.is_vdisk(guest.disks[0].path): +if _util.is_vdisk(guest.disks[0].path, None): return True # Check for the 0xaa55 signature at the end of the MBR diff --git a/virtinst/VirtualDisk.py b/virtinst/VirtualDisk.py --- a/virtinst/VirtualDisk.py +++ b/virtinst/VirtualDisk.py @@ -28,6 +28,15 @@ import Storage from VirtualDevice import VirtualDevice from virtinst import _virtinst
[et-mgmt-tools] Virtinst and blktap
I had a user question about how they can specify blktap for Xen in Cobbler instead of the file driver (for performance reasons) ... well, it turns out they can't (yet). Under what conditions can we use blktap, and is that advisable? (I had thought this might work like virtio, in which case, passing in the os version uses a table, but it seems this may only actually depend on the host and has no guest limitations?) It looks like from the virtinst code I could just call utils.is_blktap_capable() from my libvirt-using application and if so, then pass the driver=DRIVER_TAP options to virstinst. Good idea? Bad idea? --Michael ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Re: [et-mgmt-tools] Virtinst and blktap
On Wed, May 27, 2009 at 6:12 PM, Michael DeHaan mdeh...@redhat.com wrote: I had a user question about how they can specify blktap for Xen in Cobbler instead of the file driver (for performance reasons) ... well, it turns out they can't (yet). Under what conditions can we use blktap, and is that advisable? (I had thought this might work like virtio, in which case, passing in the os version uses a table, but it seems this may only actually depend on the host and has no guest limitations?) It looks like from the virtinst code I could just call utils.is_blktap_capable() from my libvirt-using application and if so, then pass the driver=DRIVER_TAP options to virstinst. Good idea? Bad idea? For Solaris dom0, I have a patch that allows driver and subdriver in virt-install. If interested, I'm happy to submit it..Note, our blktap is different (vdisk). We have an additional format selection too. virt-install -p -n nevada -l /export/snv108.iso --nographics \ --noautoconsole -r 1024 \ --disk path=/export/nevada/disk0,size=10,driver=tap,subdriver=vdisk,format=vdi MRJ ___ et-mgmt-tools mailing list et-mgmt-tools@redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools
