Oh, I see. That makes sense. I think I picked Linux (32 bit).
On Fri, Oct 25, 2013 at 11:18 PM, Marcus Sorensen <shadow...@gmail.com>wrote:
> Do 'virsh dumpxml (vmname)'
>
> The image doesn't matter. What matters is the OS you chose when you
> registered. If you take my image and register it as Windows, it will
> emulate IDE.
> On Oct 25, 2013 11:16 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
> wrote:
>
>> Yeah, I'm using the CentOS 6.3 image you gave me a while back.
>>
>> Is the DiskDef XML output to agent.log or should I explicitly put in a
>> log statement for it.
>>
>> Thanks!
>>
>>
>> On Fri, Oct 25, 2013 at 11:02 PM, Marcus Sorensen <shadow...@gmail.com>wrote:
>>
>>> Sounds like your disk definition is not using virtio-block. In this case
>>> you wouldnt be able to hot attach either though. Can you paste the diskdef
>>> XML? This would normally only happen if you used a template defined with an
>>> older OS, like the default centos 5.5 or "other Linux" instead of "other
>>> Linux PV". In those cases I think it emulates IDE, which can't be
>>> hotswapped.
>>> On Oct 25, 2013 10:05 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
>>> wrote:
>>>
>>>> Hey Marcus,
>>>>
>>>> I've been running all sorts of tests today and just noticed one issue.
>>>>
>>>> When I have a disk attached and reset (not reboot) the VM, the VM comes
>>>> up just fine.
>>>>
>>>> If I then try to detach the disk, I get the following error:
>>>>
>>>> com.cloud.utils.exception.CloudRuntimeException: Failed to detach
>>>> volume: Vol-6 from VM: VM-KVM-1; org.libvirt.LibvirtException: unsupported
>>>> configuration: This type of disk cannot be hot unplugged
>>>>
>>>> Normally I have no problem detaching a disk. Once I get into this
>>>> state; however, I seem to be stuck with an attached disk.
>>>>
>>>> Any thoughts on this?
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Fri, Oct 25, 2013 at 12:58 AM, Mike Tutkowski <
>>>> mike.tutkow...@solidfire.com> wrote:
>>>>
>>>>> Excellent - thanks!
>>>>>
>>>>>
>>>>> On Fri, Oct 25, 2013 at 12:10 AM, Marcus Sorensen <shadow...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> tests passed with latest commit hash you sent.
>>>>>>
>>>>>> On Thu, Oct 24, 2013 at 10:10 PM, Mike Tutkowski
>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> > Just playing around with this on XenServer now.
>>>>>> >
>>>>>> > When I stop a VM, XenCenter no longer shows the VM (i.e. it behaves
>>>>>> like VMM
>>>>>> > does when a VM is stopped).
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Oct 24, 2013 at 9:53 PM, Marcus Sorensen <
>>>>>> shadow...@gmail.com>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >> On Oct 24, 2013 7:39 PM, "Mike Tutkowski" <
>>>>>> mike.tutkow...@solidfire.com>
>>>>>> >> wrote:
>>>>>> >> >
>>>>>> >> > But what happens when, say, XenServer crashes and knows about
>>>>>> VMs it had
>>>>>> >> > running before it crashed?
>>>>>> >>
>>>>>> >> Not sure what XenCenter does but I thought it would/could start
>>>>>> them on
>>>>>> >> other nodes.
>>>>>> >> >
>>>>>> >> > I guess I was thinking you meant that CS purposefully creates
>>>>>> VMs on KVM
>>>>>> >> > in such a fashion that KVM will not remember them in the event
>>>>>> of a crash.
>>>>>> >>
>>>>>> >> You're right about that, you get what I mean. Its done since
>>>>>> there's no
>>>>>> >> central manager and it causes problems for each host to keep a
>>>>>> local config.
>>>>>> >> I meant that CS doesn't necessarily tell the other hypervisors to
>>>>>> remember,
>>>>>> >> per se. They just do because its working through a cluster manager
>>>>>> and
>>>>>> >> that's what they do.
>>>>>> >>
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Thu, Oct 24, 2013 at 7:25 PM, Marcus Sorensen <
>>>>>> shadow...@gmail.com>
>>>>>> >> > wrote:
>>>>>> >> >>
>>>>>> >> >> I just mean that they're still visible on those platforms
>>>>>> because
>>>>>> >> >> they're being tracked by some central source outside of
>>>>>> cloudstack.
>>>>>> >> >> Cloudstack itself I don't think cares, it just manages the
>>>>>> resources as it
>>>>>> >> >> sees in ITs database. I don't really see it as cloudstack
>>>>>> treating KVM
>>>>>> >> >> differently, rather just KVM lacking a central authority or
>>>>>> cluster manager.
>>>>>> >> >>
>>>>>> >> >> On Oct 24, 2013 7:19 PM, "Mike Tutkowski"
>>>>>> >> >> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>
>>>>>> >> >>> So, I guess the moral is CloudStack has KVM treat VMs
>>>>>> ephemerally, but
>>>>>> >> >>> we (you and I) don't know how CS has XenServer and VMware
>>>>>> treat VMs.
>>>>>> >> >>>
>>>>>> >> >>> I plan to do some testing with XenServer and VMware in a bit,
>>>>>> so I can
>>>>>> >> >>> stop a VM and see if it remains visible in their GUIs.
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> On Thu, Oct 24, 2013 at 7:17 PM, Mike Tutkowski
>>>>>> >> >>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>
>>>>>> >> >>>> My guess is XenCenter gets info about stopped VMs from the
>>>>>> XenServer
>>>>>> >> >>>> hosts it logs in to. I don't think it maintains a DB like
>>>>>> vCenter does.
>>>>>> >> >>>>
>>>>>> >> >>>>
>>>>>> >> >>>> On Thu, Oct 24, 2013 at 7:15 PM, Mike Tutkowski
>>>>>> >> >>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>
>>>>>> >> >>>>> Actually, I don't know if XenCenter remembers the VMs per se
>>>>>> or if
>>>>>> >> >>>>> it gets that information from querying the XenServer hosts
>>>>>> it has access to.
>>>>>> >> >>>>>
>>>>>> >> >>>>>
>>>>>> >> >>>>> On Thu, Oct 24, 2013 at 7:14 PM, Mike Tutkowski
>>>>>> >> >>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>
>>>>>> >> >>>>>> No, it does allow you to do that. I wasn't sure what you
>>>>>> meant by
>>>>>> >> >>>>>> your comparison, but XenCenter does remember VMs as far as
>>>>>> I know.
>>>>>> >> >>>>>>
>>>>>> >> >>>>>>
>>>>>> >> >>>>>> On Thu, Oct 24, 2013 at 7:08 PM, Marcus Sorensen
>>>>>> >> >>>>>> <shadow...@gmail.com> wrote:
>>>>>> >> >>>>>>>
>>>>>> >> >>>>>>> Oh, xencenter doesn't remember VMS and allow you to start
>>>>>> one if
>>>>>> >> >>>>>>> the host it was on is down? I haven't played with it in a
>>>>>> year but I thought
>>>>>> >> >>>>>>> it synced with each xen server.
>>>>>> >> >>>>>>>
>>>>>> >> >>>>>>> On Oct 24, 2013 7:06 PM, "Mike Tutkowski"
>>>>>> >> >>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>
>>>>>> >> >>>>>>>> Well...XenCenter is "just" the GUI (like VI Client is for
>>>>>> >> >>>>>>>> vSphere). As far as I know, XenServer has no equivalent
>>>>>> to vCenter Server.
>>>>>> >> >>>>>>>>
>>>>>> >> >>>>>>>>
>>>>>> >> >>>>>>>> On Thu, Oct 24, 2013 at 6:52 PM, Marcus Sorensen
>>>>>> >> >>>>>>>> <shadow...@gmail.com> wrote:
>>>>>> >> >>>>>>>>>
>>>>>> >> >>>>>>>>> That is probably true, but there is no xencenter or
>>>>>> vsphere
>>>>>> >> >>>>>>>>> equivalent for KVM, no central authority. Its cloudstack.
>>>>>> >> >>>>>>>>>
>>>>>> >> >>>>>>>>> On Oct 24, 2013 6:22 PM, "Mike Tutkowski"
>>>>>> >> >>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>
>>>>>> >> >>>>>>>>>> OK, thanks for that info, Marcus...I was not aware that
>>>>>> >> >>>>>>>>>> CloudStack treated VMs ephemerally with KVM.
>>>>>> >> >>>>>>>>>>
>>>>>> >> >>>>>>>>>> I guess I should try to stop a VM on XenServer and ESX
>>>>>> and see
>>>>>> >> >>>>>>>>>> what happens. I was under the impression they remained
>>>>>> accessible using
>>>>>> >> >>>>>>>>>> XenCenter or VI Client, but perhaps I am wrong about
>>>>>> that.
>>>>>> >> >>>>>>>>>>
>>>>>> >> >>>>>>>>>> Since my KVM VM's root disk was on local storage, I
>>>>>> expected it
>>>>>> >> >>>>>>>>>> to remain accessible in VMM after I had stopped it via
>>>>>> CS.
>>>>>> >> >>>>>>>>>>
>>>>>> >> >>>>>>>>>>
>>>>>> >> >>>>>>>>>> On Thu, Oct 24, 2013 at 6:16 PM, Marcus Sorensen
>>>>>> >> >>>>>>>>>> <shadow...@gmail.com> wrote:
>>>>>> >> >>>>>>>>>>>
>>>>>> >> >>>>>>>>>>> Are you talking cloudstack VMS or your own? If a vm is
>>>>>> >> >>>>>>>>>>> 'created' it is ephemeral, the definition will
>>>>>> disappear when stopped. This
>>>>>> >> >>>>>>>>>>> is what cloudstack does so that a KVM host that
>>>>>> crashes or loses power won't
>>>>>> >> >>>>>>>>>>> remember and try to start VMS that were previously on
>>>>>> it (they are likely
>>>>>> >> >>>>>>>>>>> running elsewhere now). However, for your desktop and
>>>>>> your own VMS you
>>>>>> >> >>>>>>>>>>> usually 'define' VMS, which saves the XML to a file
>>>>>> and leaves them
>>>>>> >> >>>>>>>>>>> persistent. I use vmm occasionally, but usually virsh,
>>>>>> the CLI version. Both
>>>>>> >> >>>>>>>>>>> just talk to libvirt.
>>>>>> >> >>>>>>>>>>>
>>>>>> >> >>>>>>>>>>> On Oct 24, 2013 6:08 PM, "Mike Tutkowski"
>>>>>> >> >>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>> Hey Marcus,
>>>>>> >> >>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>> I assume you use Virtual Machine Manager with KVM?
>>>>>> >> >>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>> I was wondering, is there a way when you stop a VM to
>>>>>> have it
>>>>>> >> >>>>>>>>>>>> not disappear from the GUI?
>>>>>> >> >>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>> In XenCenter and VI Client, stopped VMs just show up
>>>>>> with a
>>>>>> >> >>>>>>>>>>>> different icon, but are still easy to interact with.
>>>>>> >> >>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>> Thanks!
>>>>>> >> >>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:46 PM, Mike Tutkowski
>>>>>> >> >>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>> Also, the way I determined if the attach/detach
>>>>>> worked was
>>>>>> >> >>>>>>>>>>>>> to use fdisk -l and see if the device was present or
>>>>>> not in the hypervisor
>>>>>> >> >>>>>>>>>>>>> and VM instance.
>>>>>> >> >>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:42 PM, Mike Tutkowski
>>>>>> >> >>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>> Here are some of the tests I ran on this code:
>>>>>> >> >>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>> attach/detach/attach volume while VM is running:
>>>>>> works
>>>>>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reboot:
>>>>>> works
>>>>>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reset:
>>>>>> works
>>>>>> >> >>>>>>>>>>>>>> volume detached while VM is stopped, then start:
>>>>>> works
>>>>>> >> >>>>>>>>>>>>>> volume attached while VM is stopped, then start:
>>>>>> works
>>>>>> >> >>>>>>>>>>>>>> deleted VM with attached volume: works (volume goes
>>>>>> into
>>>>>> >> >>>>>>>>>>>>>> the attachable state after VM is expunged)
>>>>>> >> >>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:40 PM, Mike Tutkowski
>>>>>> >> >>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>> By the way, in case you're looking at the diff and
>>>>>> >> >>>>>>>>>>>>>>> wondering why I took out a StopCommand check and
>>>>>> call to execute in
>>>>>> >> >>>>>>>>>>>>>>> LibvirtComputingResource, there were two of them.
>>>>>> >> >>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>> - } else if (cmd instanceof
>>>>>> StopCommand) {
>>>>>> >> >>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>> - return execute((StopCommand) cmd);
>>>>>> >> >>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:26 PM, Mike Tutkowski
>>>>>> >> >>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>> This is a newer link, Marcus:
>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/e84de7577ad38fea88d1492d4949672d1989889b
>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>> I just rebased on top of master today.
>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 3:46 PM, Mike Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>> Hey Marcus,
>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>> If you're interested in running the simulator
>>>>>> against
>>>>>> >> >>>>>>>>>>>>>>>>> your code + my code, I have it on GitHub here:
>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/776f3eb9dda45745f43e6765b026d34fbc6be072
>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>> Thanks!
>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 11:06 PM, Mike Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>> I'm trying to attach my diff to
>>>>>> >> >>>>>>>>>>>>>>>>>> https://reviews.apache.org/r/13865/, but I
>>>>>> don't see the necessary buttons.
>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>> I wonder if I need to get edit access back
>>>>>> again? We
>>>>>> >> >>>>>>>>>>>>>>>>>> had trouble with the Wiki. Was this also
>>>>>> impacted?
>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:47 PM, Mike Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>> Sure, I can create a diff file and attach it
>>>>>> to Review
>>>>>> >> >>>>>>>>>>>>>>>>>>> Board.
>>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:40 PM, Marcus
>>>>>> Sorensen
>>>>>> >> >>>>>>>>>>>>>>>>>>> <shadow...@gmail.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> Sure. The majority of it only affects people
>>>>>> who are
>>>>>> >> >>>>>>>>>>>>>>>>>>>> on your storage
>>>>>> >> >>>>>>>>>>>>>>>>>>>> anyway. Perhaps you can post a patch and I
>>>>>> can run it
>>>>>> >> >>>>>>>>>>>>>>>>>>>> through the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> simulator to verify that the minor change to
>>>>>> the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> existing code hasn't
>>>>>> >> >>>>>>>>>>>>>>>>>>>> broken the standard storages. I don't think
>>>>>> it is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> since I've
>>>>>> >> >>>>>>>>>>>>>>>>>>>> thoroughly tested the code I posted, but I
>>>>>> know there
>>>>>> >> >>>>>>>>>>>>>>>>>>>> were some
>>>>>> >> >>>>>>>>>>>>>>>>>>>> additional changes.
>>>>>> >> >>>>>>>>>>>>>>>>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:35 PM, Mike
>>>>>> Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> > OK, Marcus, I made the change to detect my
>>>>>> volumes
>>>>>> >> >>>>>>>>>>>>>>>>>>>> > and it seems to work just
>>>>>> >> >>>>>>>>>>>>>>>>>>>> > fine.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> > Perhaps another day of testing and we can
>>>>>> check
>>>>>> >> >>>>>>>>>>>>>>>>>>>> > this code in. What do you
>>>>>> >> >>>>>>>>>>>>>>>>>>>> > think?
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> > On Wed, Oct 23, 2013 at 9:14 PM, Mike
>>>>>> Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> > <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Thanks, Marcus...I hadn't read that note,
>>>>>> but that
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> makes sense.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Yes, that must be the root disk for the
>>>>>> VM. I can
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> put in code, as you
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> recommend, to handle only my volumes.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> On Wed, Oct 23, 2013 at 5:37 PM, Marcus
>>>>>> Sorensen
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> <shadow...@gmail.com>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> It should be sending the path info for
>>>>>> each disk
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> per the XML of the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> VM... so it will send all disks
>>>>>> regardless of
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> whether or not your
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor manages that disk, and it's up to
>>>>>> your
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor to ignore any
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> that aren't managed by it. There should
>>>>>> be notes
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> to that effect in the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> code near the disconnectPhysicalDisk
>>>>>> interface in
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> StorageAdaptor:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> // given local path to file/device
>>>>>> (per
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> Libvirt XML), 1) check
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> that device is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> // handled by your adaptor, return
>>>>>> false if
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> not. 2) clean up
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> device, return true
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> public boolean
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDiskByPath(String
>>>>>> localPath);
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> Since we only have XML disk definitions
>>>>>> when we
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> stop or migrate a VM,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> we have to try all adaptors against all
>>>>>> defined
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disks. So in your
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk you might do
>>>>>> something
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> like check that the path
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> starts with '/dev/disk/by-path' and
>>>>>> contains
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> 'iscs-iqn' (maybe there's
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> some way that's more robust like checking
>>>>>> the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> full path against a lun
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> listing or something). If it doesn't
>>>>>> match, then
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> your
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk just does nothing.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> I assume this is a root disk or some
>>>>>> other local
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> storage disk. If it's
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> not, then your VM XML is messed up
>>>>>> somehow.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> On Wed, Oct 23, 2013 at 5:01 PM, Mike
>>>>>> Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > I found the problem.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > disconnectPhysicalDiskByPath is being
>>>>>> passed in
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > (in my situation) the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> /var/lib/libvirt/images/9887d511-8dc7-4cb4-96f9-01230fe4bbb6
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > Due to the name of the method, my code
>>>>>> was
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > expecting data such as the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> /dev/disk/by-path/ip-192.168.233.10:3260-iscsi-iqn.2012-03.com.solidfire:volume1-lun-0
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > Was it intentional to send the data
>>>>>> into this
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > method in the current
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > way?
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > On Wed, Oct 23, 2013 at 1:57 PM, Mike
>>>>>> Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > <mike.tutkow...@solidfire.com> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> You know, I forgot we supposed to be
>>>>>> doing
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> that! :) Multi-tasking too
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> much
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> today, I guess.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Anyways, it must not be working
>>>>>> because I
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> still had a hypervisor
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> connection after I shut down the VM.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Let me investigate.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> On Wed, Oct 23, 2013 at 1:48 PM, Marcus
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Sorensen <shadow...@gmail.com>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> Are we not disconnecting when we stop
>>>>>> the vm?
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> There's a method for
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> it, we
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> should be.
>>>>>> disconnectPhysicalDiskViaVmSpec
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> On Oct 23, 2013 1:28 PM, "Mike
>>>>>> Tutkowski"
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> <mike.tutkow...@solidfire.com>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> I see one problem for us now, Marcus.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You have a running VM that you
>>>>>> attach a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume to.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You stop the VM.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You detach the volume.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You start up the VM.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> The VM will not be connected to the
>>>>>> volume
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> (which is good), but the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> hypervisor will still be connected
>>>>>> to the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> It would be great if we actually
>>>>>> sent a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> command to the last host ID
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> of
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> the stopped VM when detaching a
>>>>>> volume (to
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> have the hypervisor
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> disconnect
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> from the volume).
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> What do you think about that?
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> On Wed, Oct 23, 2013 at 1:15 PM, Mike
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> <mike.tutkow...@solidfire.com>
>>>>>> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> OK, whatever way you prefer then,
>>>>>> Marcus
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> (createVdb first or
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> second).
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> If I leave createVdb first and
>>>>>> return 0, it
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> does seem to work.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> On Wed, Oct 23, 2013 at 11:13 AM,
>>>>>> Marcus
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> Sorensen
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> <shadow...@gmail.com>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I think we could flip-flop these
>>>>>> two lines
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> if necessary:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> createVbd(conn, vmSpec,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> vmName, vm);
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>> _storagePoolMgr.connectPhysicalDisksViaVmSpec(vmSpec);
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I haven't actually tried it
>>>>>> though. But in
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> general I don't see the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Libvirt DiskDef using size at all,
>>>>>> which
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> is what createVbd does
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> (creates XML definitions for disks
>>>>>> to
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> attach to the VM
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> definition). It
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> just takes the device at it's
>>>>>> native
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> advertised size when it
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> actually
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> goes to use it.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> On Wed, Oct 23, 2013 at 10:52 AM,
>>>>>> Mike
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> <mike.tutkow...@solidfire.com>
>>>>>> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Little problem that I wanted to
>>>>>> get your
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > take on, Marcus.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When a VM is being started, we
>>>>>> call
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > createVdb before calling
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > The problem is that createVdb
>>>>>> calls
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > getPhysicalDisk and my
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > volume
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > has not
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet been connected because
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec
>>>>>> has not
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > been
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > called.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When I try to read up the size
>>>>>> of the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > disk to populate a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > PhysicalDisk, I get
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > an error, of course, because the
>>>>>> path
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > does not yet exist.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > I could populate a 0 for the
>>>>>> size of the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > physical disk and then
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > next
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > time getPhysicalDisk is called,
>>>>>> it
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > should be filled in with a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > proper
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > size.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Do you see a problem with that
>>>>>> approach?
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > On Tue, Oct 22, 2013 at 6:40 PM,
>>>>>> Marcus
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Sorensen
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > <shadow...@gmail.com>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> That's right. All should be
>>>>>> well.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> On Oct 22, 2013 6:03 PM, "Mike
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> Tutkowski"
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> <mike.tutkow...@solidfire.com>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Looks like we disconnect
>>>>>> physical
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disks when the VM is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I didn't see that before.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I suppose that means the disks
>>>>>> are
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> physically disconnected
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> when
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the VM is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped, but the CloudStack DB
>>>>>> still
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> has the VM associated
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> with
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the disks
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> for the next time the VM may be
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> started up (unless someone
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> does a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disconnect
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> while the VM is in the Stopped
>>>>>> State).
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> On Tue, Oct 22, 2013 at 4:19
>>>>>> PM, Mike
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> <mike.tutkow...@solidfire.com>
>>>>>> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Hey Marcus,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Quick question for you
>>>>>> related to
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> attaching/detaching volumes
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> when the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is in the Stopped State.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If I detach a volume from a
>>>>>> VM that
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> is in the Stopped State,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> DB
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> seems to get updated, but I
>>>>>> don't see
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> a command going to the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> KVM
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> hypervisor
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that leads to the removal of
>>>>>> the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> iSCSI target.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> It seems the iSCSI target is
>>>>>> only
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> removed the next time the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> started.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Do you know if this is true?
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If it is, I'm concerned that
>>>>>> the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume could be attached to
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> another VM
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> before the Stopped VM is
>>>>>> re-started
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> and when the Stopped VM
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> gets
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> restarted
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that it would disconnect the
>>>>>> iSCSI
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume from underneath the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that now
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> has the volume attached.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> I still want to perform some
>>>>>> tests on
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> this, but am first
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> trying
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> to get a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM to start after I've
>>>>>> attached a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume to it when it was in
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Stopped
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> State.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Thanks,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> On Mon, Oct 21, 2013 at 10:57
>>>>>> PM,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> <mike.tutkow...@solidfire.com>
>>>>>> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks for that info, Marcus.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> By the way, I wanted to see
>>>>>> if I
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> could attach my volume to a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> VM
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> in the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Stopped State.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The attach logic didn't
>>>>>> trigger any
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> exceptions; however,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> when I
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> started
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the VM, I received an
>>>>>> Insufficient
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Capacity exception.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> If I detach the volume and
>>>>>> then
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> start the VM, the VM starts
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> just
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> fine.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I noticed a problem here (in
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> StoragePoolHostDaoImpl):
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> @Override
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> public StoragePoolHostVO
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> findByPoolHost(long poolId,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> long
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId) {
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> SearchCriteria<StoragePoolHostVO> sc =
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> PoolHostSearch.create();
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> sc.setParameters("pool_id",
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId);
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> sc.setParameters("host_id",
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId);
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> return
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> findOneIncludingRemovedBy(sc);
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> }
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The
>>>>>> findOneIncludingRemovedBy method
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> returns null (the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> my
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage pool's ID and the
>>>>>> hostId is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the expected host ID).
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I'm not sure what this
>>>>>> method is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I looked in the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage_pool_host_ref table
>>>>>> (is that the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> correct
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> table?) and it only has one
>>>>>> row,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> which maps the local
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> pool of the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> KVM host to the KVM host
>>>>>> (which
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> explains why no match is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> found
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> for my
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> situation).
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Do you understand what this
>>>>>> logic is
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do?
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks!
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> On Mon, Oct 21, 2013 at 8:08
>>>>>> PM,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Marcus Sorensen
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> <shadow...@gmail.com>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Do you have the capability
>>>>>> to clone
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the root disk? Normally
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template is installed to
>>>>>> primary,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and then cloned for each
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> disk.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In some cases (such as
>>>>>> CLVM), this
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> isn't efficient and so
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> is copied fresh to populate
>>>>>> each
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root disk.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm actually not 100% sure
>>>>>> how this
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> works in the new code.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> used to
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be handled by
>>>>>> copyPhysicalDisk in
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the storage adaptor,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> called
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> by
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>> copyTemplateToPrimaryStorage, which
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> runs on the agent. It
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> pass
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template/secondary storage
>>>>>> info,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and the destination
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> volume/primary
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> storage info, and
>>>>>> copyPhysicalDisk
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would do the work of
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> installing the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> image to the destination.
>>>>>> Then
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> subsequent root disks would
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> cloned
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in CreateCommand by calling
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> createDiskFromTemplate.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In master it looks like
>>>>>> this was
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> moved to
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> KVMStorageProcessor
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>> 'cloneVolumeFromBaseTemplate',
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> although I think this just
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> takes
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> over
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> as default, and there's
>>>>>> something
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in your storage driver
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> that
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> should
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be capable of cloning
>>>>>> templates on
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the mgmt server side.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> less sure
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> about how the template gets
>>>>>> to
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> primary storage in the first
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> place, I
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> assume
>>>>>> copyTemplateToPrimaryStorage
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in KVMStorageProcessor
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> calling
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> copyPhysicalDisk in your
>>>>>> adaptor.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It's a bit tough for me
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> to
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> tell
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> since our earlier storage
>>>>>> adaptor
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> did everything on the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> host it
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> mostly
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> just worked with the
>>>>>> default stuff.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> On Mon, Oct 21, 2013 at
>>>>>> 4:49 PM,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Mike Tutkowski
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> <
>>>>>> mike.tutkow...@solidfire.com>
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> wrote:
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Hey Marcus,
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > So...now that this works
>>>>>> well for
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > data disks, I was
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > wondering
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > what
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > might be
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > involved in getting this
>>>>>> process
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > to work for root disks.
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Can you point me in the
>>>>>> right
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > direction as far as what
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > gets
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > invoked
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > when a
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > VM is being created on
>>>>>> KVM (so
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > that its root disk can be
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > created and
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > the
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > necessary template laid
>>>>>> down or
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > ISO installed)?
>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>>
>>>>> ...
>
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
